HTML-верстка — путь к идеалу

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

Главными качествами, которыми, на наш взгляд, должен обладать верстальщик, и которые в результате и приблизят его работу к совершенству, являются: внимательность, тщательность и скрупулезность. И именно этих качеств, а не профессиональных навыков, зачастую так не хватает верстальщикам. В чем же проявляются эти качества и как помогают в процессе html-верстки?

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

К примеру, в ТехЗадании прописана «резиновая» ширина сайта, то есть сайт занимает по ширине все окно браузера и растягивается или сужается в зависимости от его величины автоматически. А в макете изображено строго фиксированное по ширине фоновое изображение, или отсутствуют детали оформления, позволяющие «клонировать» их для растягивания сайта. Или, к примеру, в макете текст одного из блоков обтекает элемент оформления по плавной дуге. А средствами html-верстки сделать такой текст можно только в виде картинки, что исключает возможность его легкого изменения обычной печатью через клавиатуру. В другом случае, например, дизайнер может представить макет с широким фоновым изображением, являющимся «подложкой» сайта, но не предусмотреть, как это изображение будет смотреться на больших мониторах с разрешением экрана в 1600х1200 пикселей.

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

Безусловно, опытный и грамотный дизайнер и сам в состоянии подготовить такой дизайн, который не будет возвращен ему верстальщиком для изменений, но это вовсе не отменяет необходимость внимательной, тщательной и скрупулезной проверки верстальщиком полученного макета.

В процессе просмотра и оценки дизайна осуществляется еще один процесс, который нами рекомендуется проводить перед началом верстки. А именно: продумывание и построение основного каркаса html-верстки будущего сайта, то есть распределение содержимого сайта по основным блокам («шапка», «подвал», левая колонка, основная часть и т.п.), и прикидка, каким именно способом эти блоки будут верстаться и взаимодействовать друг с другом. Зачастую верстальщики кидаются в работу с размаха, как ныряльщик – в холодное море, и начинают проявлять в html-коде какую-либо одну часть сайта, например, так называемую шапку сайта. А потом, когда часть работы уже сделана, наталкиваются на «подводные камни»: к примеру, «подвал», который по идее должен быть всегда привязан к нижнему краю окна браузера, оказывается при выбранном способе верстки совершенно в другом месте. Или интерактивные окна, всплывающие согласно макету за пределами основных блоков, отрезаются версткой по границам этих блоков. И чтобы исправить ситуацию, горе-верстальщикам приходится менять изначальную раскладку, а это означает – потерянное время и испорченное настроение.

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

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

Далее следует основной этап работы – непосредственно html-верстка. Нами рекомендуется сначала сверстать «голый скелет» сайта, состоящий из основных блоков без содержимого, чтобы убедиться в их правильном поведении. А потом уже приступать к детальной проработке каждой части «каркаса». Похоже это на то, как строят дом: сначала делают грубую коробку этажей, панели, перекрытия, а уж косметическую отделку каждой квартиры оставляют на второй этап. Так и в верстке – сначала доводим до ума раскладку основных блоков, добиваясь того, чтобы они идеально взаимодействовали друг с другом: в разных браузерах, при разных размерах окон браузеров, при разном объеме содержимого (подставляя для этого в блоки пробную текстовую информацию из большого количества знаков).

После того, как сверстана раскладка сайта, приступаем к детальной проработке содержимого каждого блока, тщательно и планомерно перенося в код каждую деталь дизайна. И здесь, так же как и при верстке раскладки, рекомендуется соблюдать следующие правила:

Все стили переносим из кода страницы в специально предназначенную для них таблицу стилей. Это приводит, во-первых, к облегчению кода и к более быстрой его загрузке, во-вторых, к облегчению работы по внесению изменений на сайт в будущем. Когда все стили по максимуму находятся в таблице стилей, то достаточно изменить в ней нужные строки, и исчезает необходимость «шариться» по php-шаблонам, разыскивая кусок кода, который требуется изменить. Нами неоднократно замечено отсутствие соблюдения этого правила при работе с версткой других верстальщиков, что достаточно усложняет работу.
Html-верстку проверяем во всех общеупотребительных браузерах, как то: Интернет Эксплорер 6, 7 и 8, Firefox, Opera, Google Chrome, Safari. В результате получаем действительно кроссбраузерную верстку, то есть код сайта, правильно отображающийся независимо от того, какой браузер установлен у пользователя на компьютере. Казалось бы, это правило – основа основ верстки, но, к сожалению, опять же на чужой верстке сайтов, с которыми приходилось сталкиваться, убеждаешься, что некоторые верстальщики напрочь игнорируют либо некоторые виды браузеров, либо некоторые версии определенных браузеров.
Каждый вносимый в код структурный элемент верстки проверяем в каждом из браузеров. То есть прописали блок с логотипом – смотрим этот блок во всех открытых браузерах, прописали блок текстового описания рядом с логотипом – и опять же смотрим везде, где можно, проверяем, тестируем. И так далее – с каждым кусочком пишущегося кода. Педантично, внимательно, аккуратно. Возможно, это несколько замедляет работу, зато позволяет четко отслеживать взаимодействие частей кода. Нами не раз была замечена ситуация, когда верстальщики тестируют весь сайт в процессе работы только в одном или нескольких браузерах, а начинают проверять код в остальных браузерах только после окончания работы. В таком случае, если сайт «поплыл», достаточно сложно понять, из-за какого именного участка кода он отображается не корректно. В случае же поэтапной частой проверки такой проблемы не возникает.
Соблюдаем структурную четкость кода: обязательные одинарные пробелы между каждыми элементами стилей; обязательные закрывающие точки с запятой у свойств стилей; обязательное отделение пробелами вложенных элементов, создающих визуальную наглядность «дерева» кода; обязательные условные комментарии, указывающие начало и конец важных структурных блоков; обязательное начало каждого тега html с новой строки. Кому-то эти требования могут показаться излишними, но именно такое четкое и скрупулезное внимание к каждому знаку кода позволяет свести ошибки к минимуму, максимально упростить код и сделать его чистым, красивым и легко читаемым. А в случае возникновения ошибок – а полностью их избежать не удастся, ведь людям свойственно ошибаться – такое отношение помогает легко их находить и быстро исправлять, тратя на это минимум времени и сил.
В заключение можно сказать, что когда в арсенале верстальщика имеются внимательность, тщательность и скрупулезность, то гораздо эффективнее идет профессиональный рост. Быстро осуществляетсся обучение тем специальным навыкам, которые остались за рамками данной статьи, а именно: владение блочной и многоколоночной версткой, знание особенностей верстки png-изображений, отображения прозрачности, списков, выпадающих меню и прочих других «изюминок», из которых состоит насыщенная и интересная жизнь html-верстальщика.

Добавить комментарий