В этой статье - о наболевшем: казалось бы, отношения между верстальщиками и программистами давно установились, успокоились и только медленно сдвигаются в сторону последних по мере развития и применения всяческих активных включений в веб-документы.
В этом месте соприкосновения и кроется самый больной вопрос взаимоотношения: дело в том, что верстальщик, даже если он самостоятельно пишет активное содержимое, работающее на клиенте, не всегда представляет себе, что что вместо взятых им "идеальных" и одинаковой длины строчек, программист будет выводить то, что лежит в базе данных - как правило, введенное туда пользователем через систему администрирования. Соответственно, должно быть предусмотрено, чтобы даже слишком большой текст не испортил верстку. Можно согласовать максимальную и минимальную его длину (да, и минимальную тоже - бывает, что отсутствие текста также вызывает "локальный коллапс" в верстке).
Здесь я коснусь еще одной, к сожалению, распространенной ошибки верстальщиков: они забывают, что верстка не является конечным продуктом. Ее потом будут изменять, часто "на коленке". И бывает очень обидно, если из-за отсутствия какого-то тэга в цепочке (допустим, убрали параграф, потому что перевод на новую строку стал технически недопустим или удалили тэг <a>) - какой-либо из элементов верстки совершает вдруг "последний полет" в другой угол страницы, потому что именно через отсутствующий тэг задавалась цепочка css-атрибутов, устанавливающая его на свое место.
Рассуждая таким образом, приходим к банальному выводу: следует избегать крайностей. Цепочки наследования должны быть, большинство свойств нужно передавать css-контейнерам косвенно (не правда ли, потому таблицы стилей и назвали "каскадными"), однако в этом следует соблюдать меру. Указывайте объекты верхнего уровня как ориентиры, указывающие на конкретный контейнер. Указывайте только те контейнеры, которые действительно могут служить опорными точками и которые, заведомо не будут удалены или изменены при подгонке верстки к реальному содержимому. Конкретные классы указывайте в цепочке в том случае, если нужно конкретизировать цепочку.
Совершенно недопустима обратная ситуация - когда верстка указывает непосредственно на тип контейнера, допустим "<a>" или "<tr>". Как правило, кроме создаваемых страниц, существует еще и верстка модулей двигателя и области наполнения (content-area) - и вот она-то от таких указаний неминуемо придет в полное запустение. Можно - даже необходимо - указать самые общие характеристики тэгам <body> и <table> - цвет, размер, начертание шрифта. Нужно, чтобы при взгляде туда были видны основные цвета и шрифты документа (прочие базовые цвета полезно указать рядом в ремарках). Нежелательно даже глобальное ограничение (по типу тэга) отступов (padding), промежутков (margin), бордеров и тому подобного. Если это нужно для компактности, устанавливайте такие характеристики для конкретных контейнеров. Все характеристики, кроме самых глобальных (цвет, начертание и размер базового шрифта) должны передаваться или по цепочкам или прямым назначением класса (или ID) какому-либо контейнеру.
Даже такой безобидный аттрибут, как border может наделать немало бед при установке верстки. Полностью статическую таблицу создать легче легкого, а вот динамическую, с меняющимися размерами и числом колонок - несколько сложнее. Часто, программисты включают для отладки видимость линий таблицы, вписывая в тэг table аттрибут border="1". Очень неприятно, когда этот аттрибут не оказывает никакого действия из-за того, что где-то в таблице стилей бордеры запрещены. Конечно, нетрудно найти это место и отключить его - но еще проще не портить программистам жизнь и избегать глобальных аттрибутов.
Особый элемент верстки - формы. Приходилось иметь дело с вариантами, в которых не учитывалось, что форма - это нечто функционально целое, а вовсе не набор тэгов "<input>" - однако, тэги <form>, несмотря на то, что на внешний вид они не влияют, использовать все-таки следует - хотя бы из приведенных выше соображений.
Отдельно хочется сказать несколько слов о кнопках формы: я уже не говорю о том, что их не следует заменять тэгами <img>, потому что эти тэги имеют другие свойства и иначе форматируются. Нужно еще уточнить, используется для отправки формы конструкция <button> или тэг <input> - они также форматируются совершенно по-разному! Кстати, и с точки зрения программиста эти варианты несколько отличаются, между ними нет полной взаимозаменяемости (например, у конструкции <input> аттрибут value - это и надпись на кнопке и возвращаемое кнопкой значение и отделить их друг от друга нельзя, или то, что <button> воспринимается браузером как ссылка и позволяет использовать свойство hover, а input как ссылка не воспринимается).
Словом, нужно учитывать, какую именно кнопку использовали при создании модуля и не забывать задать тэги формы.
Отдельные несколько слов о верхней и нижней полосе сайта - "header" и "footer". В них особенно часто вносятся какие-либо изменения, добавляются и убираются строки. Соответственно, должно быть предусмотрена возможность установки новой надписи (изображения) на свободное место. Видимое как свободное место - обязательно должно быть свободным, декоративные выступы и эмблемы должны быть элементами, под которыми или сбоку от которых можно что-то расположить.
Вообще, в самом общем случае можно перечислить приемы, использование которых может нарушать читаемость верстки. Конечно, речь не идет о том, чтобы вообще запретить их использование: их нужно применять там, где они необходимы, в прочих же случаях применять их не следует.
К этим приемам относятся: позиционирование float (нарушает дальнейшую модифицируемость верстки), установка изображения фоновым рисунком контейнера (ухудшает читаемость при использовании где надо и где ненадо), тэг <body> с position:absolute.
Целесообразно вводить "пространство имен" для имен классов, которые используются в верстке. Оно может, допустим, состоять из префикса изготовителя, префикса названия проекта и префикса названия страницы, разделяемых знаком подчеркивания - после которого идет уже название стиля. Это название, в таком случае, может выглядеть приблизительно так: "fw_dialog_cat_line1". Немного длинно, зато гарантирует от совпадения с разметкой уже существующих элементов.
Для хорошей видимости структуры верстки, имеет смысл снабжать закрывающие тэги более или менее больших контейнеров ремарками, содержащими указание, какой именно контейнер закрывается. Например, <div class="maincont"> ... </div><!--end maincont-->
Более мелкие контейнеры достаточно обозначать, располагая их открывающие и закрывающие тэги на одной вертикали и сдвигая содержимое контейнера на одну позицию табуляции вправо относительно этой вертикали.
Еще одним источником недоразумений могут являться циклические операции, привязанные к данным из базы, причем содержимое этой базы может меняться. В качестве примера можно рассмотреть построение фотоальбома.
Фотографии в альбоме обычно имеют подписи. В базе данных тексты лежат вместе с изображениями и вместе с ними попадают в массив. А теперь представьте себе ситуацию: изображения выводятся в горизонтальном ряду а под ним, а другом горизонтальном ряду выводятся подписи. Но ведь цикл-то обработки у нас один! Он выводит и имя фотографии и изображение - выводит одновременно. Технически возможно, конечно, запомнить ID каждого выведенного изображения, связав его, допустим, с порядковым номером на странице (читай, шагом цикла) а потом пройти массив второй раз и выводить подписи - но это громоздкое и ресурсоемкое решение. Значительно удобнее предусмотреть одновременный вывод изображения и текста при верстке.
Продолжая тему изображений, замечу, что ошибок и здесь встречается немало: прежде всего, необходимо учитывать, что на верстаемое место может быть установлена фотография немного другого размера - а самое главное, с другим отношением сторон. Такая возможность должна быть учтена при верстке. Должно быть учтено, что текст под фотографией может оказаться немного длиннее, чем планировалось. Или немного короче... Разумеется, бывают случаи когда все фотографии имеют одинаковый размер и соотношение сторон - но, согласитесь, трудно ожидать такого, например, от объектов недвижимости или от достаточно разнообразного каталога товаров: одинаковыми, скорее, будут изображения, имеющие более декоративное значение. А значит, нужно уточнить, будут ли меняться отношения сторон у изображений, и действовать, исходя из этого.
На фотографии часто накладывают вспомогательные изображения - например, логотипы. Поскольку для этого, традиционно, предназначен нижний правый угол изображения, при верстке обязательно нужно "поймать" все четыре его угла растягивающимся контейнером. Не сделав этого во-время, получите верстку практически непригодную для дальнейшего применения, несмотря на внешнее сходство с заказом.
Резюмируя, должен сказать, что внешний вид верстки не является единственным критерием оценки ее качества. Согласитесь, что вряд ли кого-то устроит верстка, требующая коренной переработки для установки на двигатель? С этой целью - указать "узкие места", могущие сделать непригодным даже хорошо выглядящий продукт, и написана эта статья.
23.09.2010 г. Rigel.
Уроки фотографии
Размышлизмы о верстке.
Livejournal 
Я.ру 
Buzz