Что под капотом? Советы Сергея Чикуенка о верстке и оптимизации графики

1 сентября прошла конференция на которой Сергей Чикуенок (технический консультант Студии Артемия Лебедева) отвечал на вопросы.

Сергей занимается вебом с 13 лет. 4 года проработал в Студии Лебедева, 2 из которых в должности технического директора.

Сейчас работает над своими проектами, но остается техническим консультантом Студии. Написал несколько статей в техногрете и у себя в блоге, самые любимые из которых: «Производительность браузеров в зависимости от верстки», «Про PNG/JPEG». Автор уникальных техник оптимизации PNG, которые собраны на Smashing Magazine .

Самые любимые работы: Imperia Private Banking, Башня Федерация, Паритет 98.

В основном Сергей занимается клиентским программированием: HTML, CSS, JS. Особую любовь питает к JS-анимации (благодаря этому увлечению в Студии начали делать анимированные сайты). Любит оптимизировать изображения, производительность, рабочее время. Проводит мастер-классы.

«Обычно „плыву против течения“: не занимаюсь оптимизацией сайтов под валидатор, могу верстать сайты таблицами, в первую очередь забочусь об удобстве пользователя, а не о том, что „под капотом“ сайтa».

Организатор конференции Александр Фитискин в своей работе очень часто использует методики Сергея, описанные в техногрете и в его блоге, которые отличаются изяществом решений.

Вопросы и ответы о верстке, JS-анимациях, оптимизации графики Сергея которые помогут кому-нибудь в работе.

— Скажите, при js-программировании вы используете eclipse? Если да, то какие плагины вы можете посоветовать?

— Да, для JS я использую Eclipse. В качестве основного плагина использую Spket (//spket.com/), о достоинствах которого я рассказывал в скринкасте техногрета.

— Расскажите про самый интересный проект, в котором вы участвовали.

— Мой самый интересный и любимый проект — Паритет 98. Мне он запомнился не столько обилием различных анимаций для одной страницы (часть из которых, к сожалению, не появилась на сайте), сколько своей концепцией: сайт одной строкой. В этом и была основная сложность — нужно было внутрь текстовой строки вставить блоки, да еще и плавно раздвигать их. Вариант «запихнуть куски строк в таблицу с кучей ячеек» не устраивал своей громоздкостью и неправильной стыковкой строк, у которых разный размер шрифта; вариант с использованием float-блоков вместо ячеек таблицы страдал теми же проблемами, но добавлял новую: как их удержать на одной строке, если пользователь увеличит размер шрифта.

Поэтому была придумана хитрая система оберток, которая позволяла вставить внутрь строки полноценный блок с уникальным оформлением и набором данных, да еще так, чтобы этот блок раздвигал слова, между которыми находится. Больше всго проблем с такой конструкцией было в Firefox и Opera (она вообще страдала от проблем с перерисовкой страницы, из-за чего на странице оставались рваные куски какого-нибудь блока), а меньше всего — в IE, так что приходилось оптимизировать верстку в «обратном» направлении: сначала все нормально работает в IE и Safari, а затем делается тюнинг для Firefox и Opera.

Кстати, по этому проекту оптимизировалась производительность IE8. На конференцию РИТ-2008 приезжал Алекс Могилевский — архитектор IE. Ему очень понравились мои работы и, в частности, сайт Паритет98, который шустро работал на IE6, но жутко тормозил на тогда еще бете IE8. Он очень просил меня ничего не делать с этим проектом, чтобы он смог оптимизировать IE8 до нормальной скорости работы с этим сайтом :). Впоследствии выяснилось, что наличие CSS-свойства white-space:nowrap раз в 10 снижало скорость работы в IE8.

Сейчас я делаю проект под айфон, где используются веб-технологии для вывода информации (HTML, CSS, JS). Для меня это новый вызов, так как скрипты, которые работают со скоростью 2 мс в настольном браузере отрабатываются со скоростью 130—160 мс в айфоне. Приходится искать совершенно новые способы обработки и отображения информации, чтобы хоть как-то добиться нормальной производительности.

— Сергей, с удовольствием читаю Ваш блог. Спасибо, нахожу для себя много интересного. Особенно было полезно прочитать статьи про создание WebWeb и верстку двух одинаковых по высоте float-колонок. Какие фреймворки (кроме Explorercanvas) вы используете в работе и какие из них считаете лучшими?

— В работе в основном использую jQuery, его же считаю самым лучшим. Если же речь идет об использовании каких-то готовых решений, то я использую их редко (кроме случаев, когда я их сам написал). Все дело в том, что большинство решений, которые я видел, не устраивали меня по некоторым параметрам (все-таки у дизайнеров Студии Лебедева очень специфические требования, на которые многие не обращают внимания). Часто бывает намного быстрее и проще сделать какое-то частное решение задачи, чем допиливать готовый продукт до нужного состояния. Иногда такие частных решения превращаются в полноценные библиотеки, которые используются на многих студийных сайтах, например, ictinus (//code.google.com/p/ictinus/) и jTweener (//code.google.com/p/jtweener/) .

— Сергей, будут ли у Вас еще статьи про оптимизацию графики? И как Вы думаете, стоит ли слишком ужимать изображения, в ущерб качеству? Тем более, сейчас, когда интернет стоит очень дешево.

— Грамотная оптимизация графики — это поиск компромисса между качеством и весом изображения. Лично я против очень сильных потерь качества изображения, тогда лучше уж вообще картинку убрать.

А насчет дешевого (и быстрого, как я понимаю) интернета у меня как раз есть замечательная история, которая произошла со мной. Года 3 назад (а уже тогда говорили о повсеместном быстром интернете) хороший знакомый моей хорошей подруги попросил помочь ему с компьютером. Этот знакомый живет на Цветном бульваре (самый центр Москвы) в очень дорогом доме, где всего две квартиры на одном этаже, а в гостинной можно играть в футбол. В подземном гараже у него стоит несколько дорогих машин. В общем, человек очень и очень обеспеченный, так сказать, целевая аудитория для любой премиум-марки. Каково же было мое удивление, когда я узнал, что в интернет он выходит по диалапу. Как оказалось, в этом районе был какой-то другой телефонный оператор (не МГТС, то есть никакого Стрима) и ни одного провайдера с выделенкой. Диалап был единственным способом выйти в интернет — и это в самом центре Москвы в очень дорогом районе. И таких там как минимум целый дом, как максимум — целый район.

Где-то через полгода знакомому снова понадобилась моя помощь. К тому моменту там появился какой-то непонятный провайдер (подключение через VPN), который, пользуясь своим монопольным положением, устанавливал совсем уж драконовские расценки: у знакомого была линия на 256 Кбит, лимитированная 500 МБ за месяц, и за это удовольствие он платил порядка 100$ в месяц (для сравнения: я за 10 Мбит безлимитку платил 40$).

Эта история реально изменила мое отношение к работе (результат — статьи по оптимизации) и к людям, которые на вопрос «почему там много весит сайт?» отвечают что-то вроде «наша ЦА — обеспеченные люди, а у них всегда хороший интернет». С такими лентяями нет никакого желания работать.

Не забывайте, что обеспеченные люди часто в разъездах, и единственный способ выйти в интернет — это бесплатные Wi-Fi точки и GPRS, а скорости там далеко не мегабитные. А статьи по оптимизации графики обязательно будут.

— Сергей, когда напишите книгу по оптимизации графики, js и всему, что рядом? Второй вопрос: что нужно (или наоборот не нужно) делать дизайнеру, чтобы верстальщик смог качественно осуществить вёрстку? Какие файлы, описания нужно прикладывать?

— Почему меня все время просят написать книгу? Нет, писать не планирую (пока), так как это довольно затратное дело. Но сейчас пишется книга «Клиентская оптимизация», там есть раздел про оптимизацию изображений. Он частично состоит из моих статей (переработанных, конечно), я же выступаю консультантом.

Насчет макетов для веб-дизайнеров могу дать следующие советы:

1. Делайте макет шириной в 1000 пикселей, тогда будет легче считать проценты для растягивающихся сайтов.
2. Разбивайте весь макет на колонки равной ширины, по ним выравнивайте элементы страницы. Желательно, чтобы количество колонок делило 100 без остатка (например, 2, 4, 5, 10) — тогда можно будет легко выравнивать по сетке элементы в разных блоках (например, выровнять картинку в контенте по логотипу в шапке), но это уже больше зависит от навыков кодера. Я еще напишу статью на тему верстки многоколоночных сайтов.
3. Не делайте элементов в макете, которые накладываются в режиме, отличном от Normal. Типичная ошибка: тень от какого-нибудь объекта накладывается на неоднородный фон в режиме Multiply. Если эта тень должна ползать по фону на растягивающемся сайте, то ее придется перерисовывать.
4. Оставляйте гайды, по которым нужно выравнивать элементы. Большим плюсом будет отдельный слой, в котором расчерчены все колонки и важные направляющие линии, а также ширины колонок и отступов (в процентах или в пикселях).
5. Не собирайте в один PSD-файл 10 шаблонов — с таким файлом совершенно нереально работать на типичной кодерской машине. 1 макет — 1 PSD-файл.
6. Если нарисовали какой-нибудь элемент (например, кнопку), состоящий из нескольких слоев — не склеивайте их, лучше объедините в группу. Это связано с тем, что технологу может понадобится кое-что подрисовать, чтобы графика меньше весила/можно было поменять фон через CSS/вела себя нормально при изменении размеров шрифта.
7. Используйте Layer Comps чтобы показывать разные состояния сайта (например, навели курсор на логотип — появилась смешная надпись).
8. Группируйте логические блоки (шапка, меню, контент, футер) — тогда кодеру понадобится гораздо меньше времени на мышиную возню с поиском нужного слоя, который нужно включить/отключить.

— Когда я делаю баннер на Flash, мне часто приходится использовать png-изображения (допустим, скриншот карты Москвы). При этом вес баннера значительно увеличивается, если картинка достаточно велика. Еще одной проблемой является то, что в итоговом мувике некоторые цвета отображаются некорректно и появляются битые пиксели. Как уменьшить размер итогового swf и при этом добиться удовлетворительного качества картинки?Сергей Чикуенок:Я довольно мало работаю с флэшом. Знаю, что у него свой алгоритм оптимизации графики, в том числе PNG: из изображения извлекаются RGB-данные, сжимаются как JPEG, и на него накладывается альфа-канал (отсюда битые пиксели, особенно красные). Это можно отключить в настройках символа (галочка Optimize, по-моему).

А универсального рецепта «сделать все клёво» не существует. Нужно смотреть, что за изображение используется, каковы его особенности, подбирать соответствующую стратегию оптимизации. В конце концов, во флэше доступны инструменты для векторного рисования: можно закрасить что-то на картинке и нарисовать это векторами поверх нее.

— Сергей, как вы относитесь к CSS фрэймворкам (Blueprint и так далее)?Сергей Чикуенок: Никогда не пользовался и вряд ли буду. Все эти фреймворки в основном ориентированы на западные типографские «кирпичи» (то есть не тянущиеся сайты). Предел мечтаний — две растягивающиеся колонки. Я использую собственные шаблоны для верстки многоколоночных сайтов, фреймворки будут мне только мешать. И у меня рука не поднимается писать классы вроде span-7 или prepend-18.

— Как грамотно организовыать филигранную верстку с вкусными эффектами и обновление сайта (текстов, графики и тд)? Или это задача CMS?
Как грамотно организовать наполнение и обновление этой красоты и динамики? Это задача грамотно организованного процесса работы над сайтом или все можно решить технологически (через регламенты админки или как-то еще?). В какую вообще сторону копать? Сергей Чикуенок:Это зависит и от CMS, и от модульной сетки. Самое важное правило — соблюдать целостность логических элементов сайта (меню, контент, боковая колонка) и ни в коем случае не смешивать их. Например, если какой-то блок в центральной колонке (контенте) должен растягиваться на всю ширину сайта, то ни в коем случае нельзя делить верстку модульной сетки на сегменты: до блока, сам блок, после блока. И выделять для этого отдельные сущности в админке. Это многократно увеличит сложность поддержки со стороны пользователя и снизит гибкость шаблона (а если нужно будет 2 таких блока на странице?). Пример: //imperia.rs.ru/press-center/photo/ Несмотря на то, что галерея растягивается на 3 колонки, она целиком умещается внутри контентного блока и, благодаря специальной разметке модульной сетки, без проблем растягивается на 3 колонки. Причем таких галерей на странице может быть сколько угодно, между ними можно добавить любой контент и он будет правильно выравниваться по линии набора.

Насчет CMS: все очень сильно зависит от шаблонизатора, который выводит данные в HTML. Для меня лучшим в этом плане является XSL. Несмотря на некоторую сложность в изучении и использовании, он как нельзя лучше подходит сайтов, так как он сам оперирует с XHTML-данными. Например, можно легко выхватить из потока элемент с нужным классом/атрибутом, добавить туда нужные декоративные элементы и вывести это на страницу. Тем самым пользователю не нужно заботиться о том, чтобы в блоке с картинкой и подписью было несколько декоративных оберток и элементов, рисующих вские рюшечки — достаточно в любом редакторе типа TinyMCE поставить нужный класс элементу.

Еще один плюс такого подхода — слабая связь с бэкэндом. Ему достаточно сгенерировать XML, на который вешается XSL-шаблон, а на чем написан бэкэнд уже не важно. Можно сгенерировать любой HTML-документ из стандартной XML-структуры.

— Некоторые призывают помочь людям избавится от IE6 (обновившись до чего-то нового) показывая строчку с призывом и ссылками вверху страницы (например //ie6update.com/). Сергей, ваше отношения к таким инициативам? Стоит ли ставить на сайт, или это нонсенс ? Сергей Чикуенок:Против такой строчки ничего против не имею — способ хороший и правильный, только показывать эту полоску нужно не более 3-х раз за сессию, чтобы не надоедало. Главное, чтобы сайт нормально работал в IE6. Пусть без всяких наворотов и красот, но основной функционал и контент должны быть доступны.

Против чего я действительно против, так это желание отдельных личностей перестать тестировать под IE6 в принципе, выводя страницу с длинным текстом и ссылками на скачивание других браузеров. Причем эти личности трусливо прикрываются тем, что Digg и YouTube прекращают поддержку IE6. Digg сделал довольно неплохое исследование пользователей IE6, которые многие поленились прочитать: //blog.digg.com/?p=878 Как видно из графиков, примерно 80% процентов пользователей обновилось бы, да не могут из-за корпоративной политики компании, в которой работают. То есть сколько бы им ни показывали плашек с призывом обновиться, поделать они ничего не смогут. А если блокировать работу сайта (особенно корпоративного, к которым YouTube ну никак не относится), выдавая вместо контактной информации пространное объяснение, чем плох IE6, то закончится это потерей клиентов.

— Сергей, можете рассказать о том, как вы работали в студии? Как происходила командная работа над проектами? Насколько долго засиживались без перерыва? Были ли такие случаи, когда сроки приходилось увеличивать из-за сложности задачи, как выходили из положения? Что можете посоветовать по поводу организации командной работы?

— Да, собственно, как у всех: иногда затягивались сроки разработки из-за того, что приходилось экспериментировать с вещами, которые никто до этого не делал; иногда проект перед сдачей полностью переделывался из-за того, что кто-то неправильно начал делать и малейший багфикс занимает несколько часов и тянет за собой много других багов. В целом, это стандартная для софтового рынка ситуация, когда процесс нельзя измерить какой-то фиксированной величиной. Одно дело конвеерно штамповать сайтики из готовых шаблонов и CMS’ок, другое дело вносить какие-то инновации.

Вот, например, сайт Саугелла: //saugella.ru/ Юра Швецов придумал классную идею с сокрытием «пикантных» слов, о которых люди стесняются говорить. Соответственно, надо было придумать стиралку, с помощью которой пользователь будет избавляться смущения (то есть стирать закрашенные слова). На тот момент (а это был 2006 год) каких-то более-менее кроссбраузерных рисовалок кроме флэша не было. Но делать весь сайт на флэше только ради того, чтобы стереть пару слов — это уж совсем издевательство над пользователем. Я довольно быстро, в течение 10 минут, придумал идею, как это можно реализовать средствами браузера, однако потратил около двух недель, чтобы добиться более-менее приемлемой производительности.

Насчет работы без перерыва: когда только пришел в студию я делал один проект в течение полутора месяцев, работал по 16 часов в сутки без выходных — макеты рисовались и переделывались прямо во время сборки сайта. Через какое-то время перестал засиживаться на работе, работал не больше 8—9 часов (исключения составляют дни открытия проектов, тогда мог на ночь остаться), при этом не могу сказать, что моя эффективность снизилась в 2 раза — она осталась примерно на том же уровне. Считаю, что 16-часовой рабочий день — это не норма, как многие думают про студию, а исключение. Большинство людей сами себя накручивают: говорят себе «ну да, остаюсь сегодня на ночь, доделаю-то и то-то» и делают часа 4 какую-нибудь фигню вместо того, чтобы поднажать и сделать это за полчаса в рабочее время. Эффективность таких людей многократно снижается, через неделю они начинают делать глупейшие ошибки и тратят на их исправление несколько часов. В итоге человек сдается, подходит ко мне за помощью, и мы за 10 минут правим то, что он не смог исправить за 2 дня.

Насчет командной работы: я у себя использую IDE для разработки, SVN как хранилище проекта и svn-хуки для выкладки проекта на продакшн-сервер — так работает очень много команд. Как-нибудь у себя в блоге опишу подробнее.

— Сергей, интересно узнать ваше отношение к Silverlight. Стоит ли сейчас начинать изучать его, или может вообще не нужно обращать на него внимания? Планируете ли вы использовать его в своих проектах?Сергей Чикуенок:Все зависит от того, что вы хотите получить в итоге. Если вы планируете выполнять работы для Майкрософта, то флэш туда они точно не пустят :). Мне Сильверлайт, прежде всего, нравится тем, что там можно сделать открытое (не скомпилированное, как во флэше) приложение. Как раз сейчас друзья мучаются с флэшовым проектом, от которого утеряны исходники.

Использовать его я пока не планирую — еще не все мощности браузеров освоены Особенно последнего WebKit. Если вы собираетесь серьезно заниматься RIA, то изучайте обязательно, лишними эти знания точно не будут. Чем больше знаете и умеете, тем более квалифицированным специалистом становитесь.

— Сергей, расскажите пожалуйста про путь javascript-программиста. Ваши работы очень впечатляют. Хотелось бы узнать с чего начинать (я для себя решил учиться по книге Флегнана Javascript. Подробное руководство, т.е. из неё взять основы, а дальше на примерах постигать примудрости) и в каких направлениях можно продолжать. Я понимаю что вопрос неконкретен, просто возможно вы можете подсказать полезные и удобные для понимания источники. Спасибо и за блог тоже, с удовольствием всегда вас читаю.Сергей Чикуенок: За всю сою карьеру я прочитал только 2 книги по JS, и те в прошлом году Книги сами по себе не сделают из вас крутого специалиста. Нужно очень много трудиться и учиться. Подпишитесь на блоги известных специалистов, изучайте готовые решения до уровня «понимаю каждую строчку», читайте спецификации, не стесняйтесь задавать вопросы, не бойтесь экспериментировать.

— Сергей, оправдано ли сейчас создание сайтов на HTML5? Или стоит дождаться, когда старые браузеры будут вытеснены с рынка, и останутся только поддерживающие эту технологию?

— Пока не вижу ни одной причины, чтобы вместо <div id=»footer»> писать <footer>, особенно с учетом того, что все еще может 10 раз поменяться.

— Сергей, как вы оценивайте перспективы технологии RIA в целом? Silverlight, AIR… — наметится ли по-вашему лидер в этой области?

— Ничего не могу сказать, так как RIA практически не занимаюсь. Правда, есть большое желание сделать что-нибудь на AIR.

— Сергей, как вы относитесь к библиоте processing.js? Мне кажется это очень хороший инструмент для анимирования изображений на стороне клиента. Что вы можете о ней сказать? Используете ли ее в своих проектах?Сергей Чикуенок: Пока не доводилось использовать processing.js. Насколько я понимаю, он работает только с canvas (то есть в IE не работает). Предпочитаю работать на более низком уровне, чтобы не упираться в ограничения оберток и чтобы была возможность использовать готовые наработки для анимации.

— Сергей, какие книги перевернули ваше сознание?

— Реально перевернула мое сознание книга «Богатый папа, бедный папа» Р. Киосаки и Ш. Летчер. Мне повезло, что я прочитал ее в раннем детстве, поэтому вовремя сформировалось отношение к финансами, и, как результат, к работе. Следующие книги, которые дали мне нужное направление: «The Humane Interface» Джефа Раскина и «Tog on Interface» Брюса Тогнаццини (спасибо Теме, что заставил их прочитать).

— Вопрос от новичка. Допустим дизайнер вам дает макет 1000 x 1400 пикселей, а вы будете верстать этот макет на мониторе с разрешением 1440 х 900, как поступить чтобы правильно сохранить пропорции шрифта и макета в целом?Сергей Чикуенок:Хм, не уверен, что понял суть вопроса. Я делаю только растягивающиеся сайты, там ставлю размер шрифта, который использовал дизайнер в макете. Каких-то телодвижений в сторону динамического изменения размера шрифта в зависимости от ширины окна браузера не делаю — пользователь может сам увеличить или уменьшить его.

— Бывают, конечно, смешные дизайнеры, которые приходят в веб из полиграфии и начинают толкать свои идеи. Как правило, разговор заканчивается долгим объяснением, чем веб-страница отличается от листка бумаги

— Сергей, расскажите ещё пожалуйста как вы предпочитаете писать CSS. Какова структура и иерархия, разбиваете ли вы стили на н-надцать стилевых файлов, делаете ли разделение таким образом, что в одном правиле собраны цвета и фоны… в другом размеры и отступы и т.п. Если да, то почему, если нет то опять же почему? Дело в том что я плохо понимаю зачем это разбивание на нужно, потому что мне кажется что это затруднит чтение кода другим и займет некоторое время на разбор. Да и быстрее наверное просто загрузить один файл. Это конечно же личное ИМХО и интересно знать насколько оно верно. Интересно как делаете вы в процессе разработки. Спасибо.Сергей Чикуенок:Я делаю так. Например, есть основной файл, который отвечает за вывод страницы каталога. В этот файл через @import подключаются модули:

@import url(_product-list.css);
/* Стили для списка продуктов */
@import url(_buttons.css);
/* Стили для вывода красивых кнопочек */ 
@import url(_alphabet.css);
/* Стили для вывода алфавитного указателя */

и так далее.

То есть разбивку делаю по логическому принципу, а не визуальному (цвета, отступы и т.д.). Далее, перед выкладкой проекта на продакшн-сервер запускается Ant-сценарий, который проходится по всем CSS-файлам, сжимает их YUICompressor’ом и сохраняет в отдельную папку. Причем если от встретит импорт файла, имя которого начинается на подчеркивание, он заменяет этот импорт на содержимое файла. Тем самым на выходе я получаю один сжатый файл. Так как исходные CSS-файлы остаются, я могу в любой момент переключиться на них с помощью специального параметра строке запроса и заниматься отладкой стилей в исходных стилях даже на продакшн-сервере.А разбиение на файлы нужно для того, чтобы удобнее было редактировать файлы. Например, основной файл стилей моего проекта сейчас весит 44 КБ — и это в пожатом виде. В исходнике он весит порядка 100 КБ, разбит на 10 модулей + комментарии. Если бы все это было в одной куче — было бы очень сложно все это редактировать и поддерживать в порядке.

— Сергей в одном из скринкастов вы рассказывали про использование формы и контрформы для скругления углов. И говорилось про такую проблему в ИЕ6 когда при позиционировании правого блока с скруглением при нечетной ширине родителя этот блок отстоит на один пиксель от родителя. Решением для этого было отрицательное позиционирование и левый отступ. А что делать для нижних блоков со скруглениями? Я знаю что можно просто их после родителя в коде указать и в принципе проблемы нету, а можно ли опять таки внутри родительского элемента? Спасибо.Сергей Чикуенок: Решения этой проблемы так и не нашел. Просто ставлю элемент в конце контейнера и делаю относительное смещение.

— В чём преимущества и недостатки блочной вёрстки? Я считаю, что верстать таблицами гораздо удобнее, а блочная вёрстка нужна только в некоторых, не типичных случаях. Однако, сейчас модно верстать блоками. Скажите, на ваш взгляд, эта «мода» чем-нибудь оправдана?

— Я довольно подробно на эту тему ответил у себя в блоге: //chikuyonok.ru/2009/06/holywars/ Если кратко, то блочная верстка — это не просто мода, а способ достижения необходимого результата. Например, блочной версткой можно легко сделать три версии сайта — для экранов, для печати и для PDA, причем меняется только CSS. Но некоторые кодеры слишком фанатично относятся к верстке блоками. Реально видел сайты, где табличные данные были сверстаны блоками Людям настолько промыли мозги, что таблицы — это зло, что они в итоге боятся применять таблицы даже там, где они нужны, эмулируя табличное поведение с помощью громадных стилей и костылей для разных браузеров.

Лично я ничего плохого в таблицах не вижу. Да, они проще, да, некоторые вещи на дивах очень сложно сделать, особенно кроссбраузерно. Но сайты, в конце концов, делаются для посетителей, которые плевать хотели на HTML-внутренности. Я не знаю ни одного случая, когда посетитель ничего не купил в интернет-магазине только потому, что он сверстан таблицами, Ну, то есть цена продукта ниже, чем у других, магазин с хорошей репутацией и приятным дизайном, но вот чувак перед нажатием на кнопку «Оформить заказ» решил вдруг посмотреть, насколько семантично сверстана страничка или — о боги! — не покажет ли валидатор ошибок. И понимает, что с таким отношением к коду владельцы сего магазина не достойны его внимания, уходит на другой сайт — валидный и семантичный — где ему впаривают то же самое, но в 2 раза дороже, да еще и оператор по телефону обхамил.

У меня есть такое правило. Модульную сетку я всегда верстаю блоками, потому что мне нужна гибкость макета. На это я могу потратить несколько дней. А вот мелкие внутренние элементы, если без таблиц их не получается сделать за 20 минут, запросто могу сверстать таблицами. При этом не буду говорить, что сайт сделан плохо только потому, что он целиком сверстан таблицами.

— Сколько времени на студии Вам выделяли на верстку и Js программирование типового сайта?

— Все очень относительно. Смотря какой макет, какой сайт. Например, Паритет98 делал больше месяца, хотя сайт, по сути, состоит их одной страницы. Какие-то промо-сайты делал за неделю.

— Сергей, на что вы больше тратите время при выполнении проекта: на проектирование или тестирование? Как вы определяете, нужно ли идти простым (пусть и не идеальным), проторенным путем или стоит попробовать что-то свое, новое. Ведь существует риск в процессе работы понять, что выбранный вариант ошибочный (что особенно критично при сжатых сроках).

— Я довольно часто занимаюсь проектами, где без нового не обойтись Но даже в простых случаях пытаюсь привнести что-нибудь новое. Предпочитаю идти инновационным путем — не хочу раньше времени превратиться в старпера, который 5 лет назад нашел решение задачи и пользуется им до сих пор. С такими людьми не интересно и скучно работать.

Чтобы не срывать сроки (по крайней мере не очень сильно), я экспериментирую в нерабочее время. Конечно, я неоднократно ошибался с выбранным направлением, ошибки исправлял тоже в нерабочее время. В конце-концов, не ошибается тот, кто ничего не делает.

— Сергей, с чего начиналась разработка библиотек, типа rocon или jTwinner? Много ли ты времени уделил проектированию и описанию необходимого функционала, или начал реализацию постоянно наращивая функционал? Можешь дать несколько советов, с чего начать, каких подводных камней стоит избегать при проектировании и разработке независимых библиотек на JS?

— В первую очередь определяется набор проблем, которые должна решить библиотека. Затем терзается гугл в поисках уже существующих решений — зачем изобретать еще один велосипед? Если я понимаю, что ни одно из существующих решений не соответствует моим требованиям, только тогда приступаю к написанию своей. Так было с rocon.

Иногда бывает, что библиотека получается сама собой, из решения какой-то конкретной задачи. Например, когда-то очень давно для одного проекта я написал небольшой класс SimpleCanvas, задача которой — рисовать линии. Но с одной поправкой — линии должны растягиваться. На тот момент самым распространенным механизмом рисования был canvas, но у него есть особенность: если его размер поменяется, то все, что было там нарисовано, автоматически сотрется. Эта библиотека как раз запоминала все нарисованные линии и заново их отрисовывала при изменении размера окна браузера. Результат настолько понравился студийным дизайнерам, что они начали один за другим делать проекты с растягивающимися линиями, а мне ничего другого не оставалось, как оформить это отдельной библиотекой, которой пользуются в студии до сих пор: //www.felixzawojski.ru/rooms/

Сама библиотека начинается с реализации рабочего прототипа: просто описываю весь функционал, который должен там быть. Как правило, библиотека пишется для какого-нибудь проекта, то есть тестовая площадка уже есть. Во время разработки проекта тестируется удобство использования библиотеки и ее качество работы в «боевой» ситуации. С jTweener’ом я в какой-то момент понял, что мне не удобно постоянно писать jTweener.addTween(), особенно если нужно добавить несколько анимаций одному объекту. Поэтому я написал фасад $t, который по принципу похож на jQuery: вызовы методов можно объединять в цепочки, вроде $t().tween().tween(), можно задавать общие параметры анимации. То есть сама библиотека совершенствуется именно во время ее применения в проектах. После того, как понимаю, что результатом не стыдно поделиться с общественностью, пишу документацию и выкладываю на Google Code. Вообще, стоит взять за привычку документировать собственный код, особенно если хотите делиться им с публикой. Очень важно с самого начала определиться, на каком языке будете писать доки. Исходный код библиотеки Zen Coding я изначально документировал на русском, так как планировал ее сначала обкатать на небольшом количестве людей, а только потом ее пиарить. Но совершенно неожиданно ее начали активно использовать в других странах (даже маковский редактор Espresso уже распространяется вместе с ней), и я получил очень много просьб перевести ее на английский. Поэтому совет: документацию для библиотек лучше сразу писать на английском.

Еще могу посоветовать не привязываться к другим фреймворкам вроде jQuery без большой надобности. Много людей используют другие фреймворки (Prototype, Ext.js), а подключать еще один только ради одной библиотеки как-то слишком расточительно.

— Сергей, у нас тут спор возник, относительно :visited в ссылках, которые в навигации сайта. Например в меню сайта или хлебных крошках. Нужно ли в этих элементах выделять посещенные ссылки или нет? Почему?

— Я бы добавил в меню. Пользователь необязательно попадет непременно на главную страницу сайта и запомнит весь свой путь по нему. Он может попасть на внутреннюю страницу с поисковика, и уже оттуда начать свой путь по сайту. А :visited в меню будет для пользователя хорошим индикатором, где он уже был (это особенно актуально на больших банковских сайтах).

— Сергей – насколько актуальна у нас (на российском рынке) XHTML-вёрстка? Имеет ли она такую же популярность как на западе, и актуально ли это для текущих тенденций веб-разработки?

— Смотря что вы подразумеваете под XHTML. Если просто доктайп + синтаксис, то это дело вкуса. Мне, например, нравится писать писать <br />, а на высоконагруженных проектах скорее всего будут экономить на каждом байте и писать <br>. На самом деле вы в обоих случаях будете, по сути, работать с HTML.

Но если вы имеете в виду честный XHTML (с соответствующим Content-type заголовком), то он используется крайне редко из-за огромного количества возникающих проблем и высокой чувствительности к ошибкам (забудете закрыть тэг — пользователь увидит сообщение об ошибке вместо сайта). Я не знаю ни одного коммерческого проекта, который использовал бы честный XHTML.

— Вы придумываете достаточно интересные вещи на js, но как вы доносите эти идеи до дизайнера (Например сайт Паритет98)? Ведь обычно сначала дизайнер делает дизайн, а потом программист его верстает-программирует, а не наоборот. Вы занимаетесь «просвещением» дизайнеров, чтобы они могли и не боялись рисовать «странные » дизайны?

— Часто дизайнеры придумывают только идею: «хочу, чтобы меню красиво вылетало». А я уже реализую детали: как именно оно будет вылетать, с какой скоростью, с какими эффектами, после чего согласовываю это с дизайнером.

Бывает и так, что дизайнер просит придумать какой-нибудь спецэффект. В этом случае я показываю дизайнеру на пальцах, что будет происходить, иногда делаю рабочий прототип, и, если он дает добро, говорю ему, что от него нужно: нарисовать картинку большего размера, подвинуть немного блоки и т.д. Дизайнеры, как правило, доверяют моему вкусу Самое важное показать какой-нибудь промежуточный результат.

В случае с проектом Паритет98 было так. Арт-директор — Людвиг Быстроновский — придумал идею сайта из одной строки с разъезжающимися слайдами. Перед началом работы с проектом он мне показал, как будут выглядеть эти слайды, вот тут должны машинки крутиться во время скроллинга, а вот тут будет слон-нелегал, пытающийся пересечь таможню, но его не пускают и он врубает габариты и пятится назад. Все детали анимаций вроде скорости перемещения я прорабатывал сам, утверждая промежуточные результаты с арт-директором. Какие-то идеи придумывал и реализовывал сам.

— На чьей вы стороне: верстальщиков таблицами, или верстальщиков дивами?

— Я на стороне здравого смысла: не буду верстать ни тем, ни другим только из принципа. Предпочитаю верстать дивами, но если надо — могу и таблицами что-то сделать.

— Многие ругают JS-фреймворки за необоснованную пузатость, за кучу лишнего кода и т.п. Сергей, что и почему Вы чаще всего выбираете для JS-анимации — готовые «пузатые» фреймворки или самописные, но компактные, «велосипеды»?Сергей Чикуенок:Для простых анимаций мне воплне достаточно jQuery, для сложных использую самописный jTweener (который тоже стал «пузатым»).

Насчет этого у меня отдельный пунктик. Как-то спорил с коллегой, который начал делать сайт на самописном фреймворке вместо того, чтобы использовать jQuery. Причем сайт содержал довольно много интерактива. Да, он сэкономил 20—30 КБ (при том, что на одной странице графики было килобайт на 500), но что получилось в итоге? Я начал задавать ему наводящие вопросы.

— Вот ты сделал свой фреймфорк (даже не фреймворк, а набор функций), а документацию написал? После тебя проектом будет заниматься другой человек, что он будет делать, если ему нужно будет исправить баг или что-нибудь дописать? Придется потратить час на изучение нового велосипеда для того, чтобы за 5 минут решить задачу?

— Хорошие фреймворки автоматически исправляют многие кроссбраузерные баги, причем решения уже хорошо протестированы. У тебя этого не происходит. Соответственно, если технолог в дальнейшем столкнется с такой проблемой, он должен их исправить в существующих функциях, спровоцировав проблемы в уже работающих скриптах, или написать отдельную функцию, раздувая и загрязняя тем самым базовую библиотеку?

— Твой фреймворк весит в 3 раза меньше, чем jQuery, умеет в 100 раз меньше, чем jQuery, а решения на нем весят в 2—3 раза больше, чем на jQuery. Так на чем ты сэкономил?

— Как можно и можно ли соединить звук с анимацией в яваскрипте? Пример: взрыв.

— Можно. Для новых браузеров лучше использовать модный тэг audio, для старых можно поступить так:

var sound;

function playSound(){
	if (!sound) {
		sound = document.createElement('embed');
		sound.setAttribute('autostart', 'true');
		sound.setAttribute('loop', 'false');
		sound.setAttribute('src', 'test.mp3');
		document.body.appendChild(sound);
	}
}

function stopSound() {
	if (sound) {
		sound.parentNode.removeChild(sound);
		sound = null;
	}
}

Только вряд ли удастся точно синхронизировать анимацию взрыва и звук.

— В ваши обязанности как технического директора входила оценка реализуемости того что напридумывали арт-директора и понарисовали дизайнеры? Каков процент дизайнов, которые «невозможно» сделать в вебе? Часто ли дизайнеры понимают, как нарисовать так, чтобы и в вебе это работало?

— Да, мне необходимо было оценить реализуемость дизайнерских хотелок — как правило, такое согласование происходит на сложных проектах еще до того, как идею и дизайн презентуют клиенту. Процент «отказов» довольно небольшой (хотя зависит от техдиректора :), у меня это было где-то 5—10%. Дизайнеры, конечно, не всегда понимают, как что-то можно реализовать, но это касается только инновационных вещей, поэтому они сначала советуются, а потом рисуют.

— Какая продолжительность рабочего дня в студии и сколько времени сотруднику можно потратить на собственное обучение, совершенствование?

— Номинально — 8 часов + час на обед. Естественно, большинство сотрудников работают гораздо больше. Я считаю, что сотрудник должен тратить все свое доступное время на самосовершенствование, в том числе и во время работы. Понятно, что сроки постоянно поджимают и времени на все не хватает, но мозги не должны засыхать под напором рутины. Нужно постоянно искать способы сделать ту же самую работу, но быстрее и качественнее.

— Сергей, очень радуют ваши работы. Помимо интересных путей решения поставленных задач, особенно приятен стиль изложения статей — все детально расписано с иллюстрациями. Знаю что это занимает не мало времени и сил, поэтому выражаю вам уважение и благодарность. В списке ваших трудов и статей четко прослеживается линия работы над «простыми» сайтами визитками и информационно-развлекательными сайтами. Суть таких сайтов это стандартный переход от одной страницы к другой + немного анимации + иногда немного AJAX. Приходилось ли вам за вашу практику работать над проектированием и разработкой сложных одностраничных веб-приложений по типу //gmail.com? Если да, интересуют наиболее трудные для вас моменты, которые встречались при реализации подобных приложений. Возможно, во время разработки таких приложений были придуманы новые техники, методики или подходы к решению определенных задач? Если нет, интересно почему? не было таких заказов или работы такого плана не принимаются вами в разработку?

— Таких проектов пока не было, но надеюсь, что очень скоро появится. Были, конечно, большие страницы, которые прогибались под напором интерактивных элементов и анимаций. В таких случаях была хорошая почва для исследований (смотрите статью про производительность браузеров в Техногрете), но, например, пока не приходилось оптимизировать CSS-селекторы, как это сейчас делается в Яндексе.

Самое неприятное в таких моментах — это когда собираешь отлично работающие сами по себе компоненты в готовую страницу и все это начинает дико тормозить и глючить в каком-нибудь браузере. Приходится тратить уйму времени на дебаг и поиск проблемных мест и все переделывать заново. Сейчас делаю приложения для айфона, в котором используются веб-технологии — там тоже очень весело с производительностью. Буду исследовать и эту область.

— html-страницы сегодня становятся всё более и более динамичными, а их создание всё больше напоминает процесс программирования. Можно ли прогнозировать, что в будущем страницы ещё больше приблизятся к программам, а браузер — к виртуальной машине для их исполнения? Каким вы видите будущее веб?Сергей Чикуенок:В принципе, все так уже и есть — посмотрите на Adobe AIR, Titanium, PhoneGap. Уже можно писать полноценные кроссплатформенные приложения на одних только веб-технологиях.

Насчет будущего — я не люблю делать прогнозов. Сейчас слишком много проблем, которые не решаются уже много лет и которые сдерживают развитие веба. Например, нежелание админов обновить IE6 в крупных компаниях или медленный интернет в регионах.

— Как Вы относитесь к скрипту PngFix.js, который исправляет проблемы с прозрачностью для PNG в 6 IE? Является ли использование этого скрипта везде, где есть прозрачность PNG обоснованной?

— Очень положительно отношусь, использую его на каждом проекте.

— Скажите пожалуйста, можно при разработке сайта полностью отказаться от использования js и чему это грозит? Второй вопрос: каким вы видите интернет через пять лет, что отомрёт за ненадобностью, а что будет развиваться?

— Отказаться от JS можно, но зачем? Не думаю, что пользователь обрадуется, если для проверки правильности ввода электронного адреса ему придется заново загрузить страницу. JS уже давно стал отличным топливом для современных сайтов. Можно, конечно, не заправлять их, только толкать их в гору будет не очень весело.

Начет прогнозов на будущее ответил в предыдущем вопросе.

— Сергей, на чем ездите на работу? Так ли страшны московские пробки как говорят?

— Хожу пешком. Пробки, конечно, страшные в Москве, но я, к счастью, в них редко попадаю.

— В последнее время все чаще сталкиваюсь с canvas, и все больше проблем появляется с IE Что посоветуете избегать при работе с канвасом что-бы обойти основные грабли? P.S. И как Вам кажется насколько радужно будущее канваса без IE?

— В IE канваса нет, есть только VML, который принципиально от него отличается. Советую избегать удаления нарисованных фрагментов через clearRect() и масок — они просто не работают в VML (технически это можно сделать, но очень и очень сложно). Еще очень интересно работают маски в Опере — чтобы не было проблем при перересовке, их лучше все время удалять и рисовать заново.

А так canvas — очень интересная технология. Очень хочу, наконец, найти время и сделать что-нибудь полезно-интересное на нем, а то демки из разряда «смотрите, в браузерах можно делать вот так» уже порядком надоели.

— Как требовательна JS-анимация к ресурсам компьютера и требовательна ли вообще, как, скажем, Flash-анимация. Существуют ли способы оптимизации JS-анимации?Сергей Чикуенок:JS-анимация, как правило, гораздо требовательнее к ресурсам, чем Flash. Надо помнить, что HTML и Flash отличаются идеологически: в HTML есть поток, в котором находятся элементы и которые влияют друг на друга, во флэше все располагается на независимых слоях. В этом есть свои плюсы и минусы: что-то проще анимировать в HTML, что-то проще во флэше. Из-за наличия потока в HTML во время анимации может возникать такая вещь, как reflow (перераспределние блоков в потоке) — очень дорогая и медленная операция, которую нужно избегать. В некоторых браузерах даже обращение к атрибуту offsetHeight элемента вызывает reflow.

Железное правило оптимизаций анимации: свести обращения к свойствам анимируемого DOM-элемента к минимуму, так как это довольно дорогая операция. Лучше сделать все расчеты до запуска анимации, а во время анимации только записывать изменившиеся атрибуты. Избегайте reflow, по возможности. Я часто делаю такой трюк: перед запуском клонирую анимируемый элемент, ставлю ему position: absolute, скрываю оригинал, а дубликат анимирую. В некоторых ситуациях это дает ощутимый прирост скорости.

Еще на анимацию сильно влияет «окружающая среда» — макет сайта. Например, большое количество DOM-элементов сильно снижает производительность в FireFox, даже если эти элементы никак не вовлечены в процесс анимации. Подробности читайте в статье о производительности браузеров в Техногрете.

— Когда можно будет уже полностью не обращать внимание на IE при верстке?

— Когда любая статистика будет показывать, что пользователей IE 1–2% от общего количества.

— Как правильно оценить время, необходимое на верстку. Требовали ли от вас в студии точную оценку или просто ставили дедлайн?

— Требовать точное время на разработку программного продукта — идиотизм. Это у кузнеца Пименова есть норма выработки втулок за смену, а в чем измерять производительность программиста? В количестве строк кода, в килобайтах, в количестве созданных функций и классов? Технолог может посмотреть на макет и сказать: «Сделаю примерно за два дня». Через день работы он понимает, что сверстанная им модульная сетка жутко глючит в каком-нибудь браузере и тратит еще 2 дня на решение проблемы + 1 день доводку по комментариям дизайнера. Мог ли он знать, что возникнут такие проблемы, если он раньше сделал с десяток подобных макетов, а проблему вызвал новый нестандартный блок? Хороший менеджер должен это понимать и умножать приблизительные сроки, названные программистом, на 2—3.

— Вы активно используете Mac в своей работе. Он значительно удобнее для ваших задач, или «просто так получается»?

— Я считаю, что Мак — это самая лучшая платформа для веб-разработки. Потому и перешел на нее.