Принципы корректных HTML и CSS
Данная статья начинает небольшой цикл, в котором мы поделимся принятыми у нас в организации правилами написания кода. Корпоративные правила — не простая формализация процесса, а средство оптимизировать работу: если все придерживаются одних и тех же правил, код, написанный одним человеком, будет легко восприниматься другим, а значит, и работа движется быстрее.
Семантическая вёрстка
Часто термин «семантическая вёрстка» используют не совсем корректно, в плане просто отделения формы от содержимого. Допустим, есть страница, свёрстанная на блоках, а всё разукрашивание ведётся средствами CSS. Логика и оформление в этом случае разделены, но при одном условии: если идентификация блоков ведётся не по внешним признакам, а действительно по семантике. Распространённая ошибка многих веб-верстальщиков — использовать идентификаторы и классы по их верстальным возможностям. Например, специальный блок для завершения группы плавающих элементов. Span, выделяемый красным цветом. Одинаковый класс и для эпиграфа, и для авторской подписи к материалу (выравнивание по правому краю + курсив). Чем это плохо: если возникнет необходимость изменить стилевое описание элементов, используемых на одной странице, то есть опасность, что «поедет» вёрстка или проявятся нежелательные изменения на страницах другого типа, где применены те же классы. (При редизайне установили для блока ширину в 415px вместо 512, но не проверили, что на одной из страниц из-за этого съёжились поля для ввода и лейблы, заключённые в блок с тем же стилевым идентификатором).
Принципы правильной вёрстки
1. Использовать только смысловые имена. Если блок для формы регистрации и блок для отправки писем похожи по каким-то признакам или на данном этапе вообще обладают одинаковыми стилями, лучше сделать два идентичных описания, но для разных ID или классов. В будущем вы обезопасите себя от багов в вёрстке, случившихся по недосмотру.
2. Если стилей получается слишком много, можно использовать несколько стилевых файлов: один основной, для классов и идентификаторов, встречающихся на большинстве страниц, остальные по разделам. Соответственно и подгружать нужные в соответствующих разделах (это легко поручить серверу).
3. Целесообразно использовать префиксы в именах классов и идентификаторов, например: regform_main, regform_input, regform_label, regform_announcement и так далее (помимо всего прочего, это создаст удобства при динамическом изменении стилей средствами JavaScript или серверного языка).
В стилевых файлах очень удобно снабжать комментариями разделы, например:
/* Main */
a { ... }
p { ... }
/* Forms */
input { ... }
input.abcd { ... }
/* IDs */
#abc { ... }
#pretend { ... }
Старайтесь использовать в стилевых файлах только латиницу во избежание проблем некоторых браузеров в кодировкой: если страница на UTF, а стилевой файл на Windows-1251 с использованием кириллических символов, то Internet Explorer (до 6 версии точно) просто проигнорирует эту стилевую таблицу.
И, конечно, нужно использовать последовательный стиль вёрстки и написания стилевых файлов: отступы, особенности имён, стилевые правила в столбик или в строчку…
4. Можно в качестве вспомогательных мер использовать возможности наследования, или вложенности, как некий аналог ООП. Если я напишу:
div#register input {...},
то я буду точно уверен, что таким стилевым описанием я разукрашу только поля ввода, заключённые в блок с id=”register”, а не какие-либо другие.
А для всех полей ввода можно описывать общие правила, только если они точно и всегда будут соблюдаться на всех страницах сайта и соответствуют общему стилю.
5. И не нужно забывать про таблицы. Их некто не отменял, если они также используются семантически, то есть для табличных данных (статистика, результаты, цены и т. п.)
Код на CSS
1. CSS-файл с помощью комментариев разбивается на разделы:
- основное (*, p, a, формы и т.п.),
- идентификаторы и классы, которые встречаются на всех страницах,
- разделы по конкретным страницам или группам страниц
В этом случае проще найти причинно-следственные связи глюков вёрстки
2. Стандарт оформления одного стилевого описания:
селектор {
правило 1;
правило 2;
правило 3;
}
Не забываем о точке с запятой, несколько раз исправлял; это в некоторых браузерах бывает критично.
3. Желательное расположение правил в описании:
селектор {
блочные правила (display, position, z-index, top, right, float, clear);
правила, относящиеся к блокам (margin, padding, border, width, height);
линейные правила (цвет и гарнитура текста, подчёркивание);
разное (курсоры и т. п.)
}
4. Единицы измерения пишем вплотную к числам: в некоторых браузерах из-за пробела возникнут разночтения.
5. В начале CSS-файла обнуляем все отступы.
* {
margin:0;
padding:0;
border:0; /* Если не нужны рамки для элементов форм */
}
Затем в каждом конкретном случае назначаем отступы и рамки индивидуально. В этом случае у нас ничего не едет в разных браузерах.
6. Ограничения
С помощью CSS невозможно описать некоторые вещи, чтобы они корректно отображались во всех браузерах. Для их эмуляции можно использовать графику и обходные пути, это чуть дольше (учитывать эти трудозатраты при обсуждении предложенного дизайна интерфейса), но реально.
Чекбоксы. В Опере можно настроить цвета и размеры, в ИЕ частично (объёмная рамка остаётся всегда), ФФ игнорирует CSS для чекбоксов. Если нужно кардинально менять внешний вид, решение такое: блок с чекбоксом делать с position:relative, внутри блока до самого input ставить span с такими же размерами, как у блока с чекбоксом, но абсолютно позиционированный, а фон span’а в CSS написать и скриптом менять в зависимости от нажатия. При отсутствии картинок будут видны чекбоксы (если не прописать цвет фона, конечно), при наличии — заменители.
Радиобаттоны (переключатели). То же самое, что и для чекбоксов. При CSS-изменении фона в Опере фон меняется внутри поля, в ИЕ вокруг него, в ФФ не меняется.
Поля для загрузки файлов. Наименее поддающаяся правке часть формы. В ФФ даже нельзя регулировать длину поля, во всех браузерах внешний вид кнопки Browse/Обзор не редактируется, надпись зависит от языка браузера, на border все браузеры реагируют по-разному: кто рисует вокруг поля ввода, кто целиком обрамляет поле ввода + кнопку, кто игнорирует. Решение: поле сделать прозрачным:
filter:progid:DXImageTransform.Microsoft.Alpha(opacity=50); /* IE 5.5+*/
-moz-opacity: 0.5; /* Mozilla 1.6 и ниже */
-khtml-opacity: 0.5; /* Konqueror 3.1, Safari 1.1 */
opacity: 0.5; /* CSS3 - Mozilla 1.7b +, Firefox 0.9 +, Safari 1.2+, Opera 9 */
Под поле положить поле ввода и нарисованную кнопку, точно позиционировав их, а поле для загрузки выровнять по правому краю. Получится, что при щелчке на видимой нарисованной кнопке на самом деле будет происходить щелчок по прозрачной кнопке, а информацию о выбранном файле нужно скриптом записывать в редактируемое видимое поле ввода.
Выпадающие списки. Нормально редактируются в ФФ и Опере, в ИЕ остаётся объёмный край. Тэг optgroup, группирующий элементы option, во всех браузерах интерпретируется по-разному и не редактируется CSS.
Позиционирование. При вставке флэш-объекта он всегда оказывается на переднем плане, даже если есть элемент с z-index:40000. Решение только в правильном построении блока embed/object:
#flash {
position: relative; /*or absolute*/
z-index: 0;
}
<div id="flash">
<object ...>
<param name="wmode" value="opaque">
<embed ... wmode="transparent">
</object>
</div>
Фоновые изображения. Желательно указывать не только картинку, но и цвет фона, чтобы без графики у блока не было прозрачного фона. В URL не надо использовать кавычки: IE 5 под Макинтошем, встретив их, вешается.
Код на HTML
Если ориентируемся на XHTML-вёрстку, в одиночных тэгах завершающий слэш ставим через пробел: <br /> — это нужно для корректного их чтения старыми браузерами. Нетскейп 4 и прочая архаика не знает тэга <br/> (без пробела), но корректно проигнорирует неизвестный атрибут / тэга <br>, а для новых браузеров всё равно, есть пробел или нет. Одиночные тэги: <img />, <br />, <hr />, <input />, <meta />, <link />, <base /> (последний не поддерживается спецификацией). В выпадающих списках всегда закрываем <option>вот так</option>. Не закрывать тэги и писать их большими буквами — хамство (© Катя Журданова).
Для всех элементов форм используем и name, и id — если не нужно сразу, пригодится в дальнейшем.
Если чекбокс один в форме, то имя и идентификатор могут совпадать.
Для чекбоксов и радиобаттонов используем лейблы:
<input type="checkbox" name="checkbox1" id="checkbox1" value="1" /><label for="checkbox1">Нажимать тут</label>
Желательно и для остальных полей ввода использовать не абстрактные блоки или span, а лейблы (<label>) — с помощью стилей их легко сделать и строчными, и блочными элементами, и в любом браузере они легко разукрашиваются.
Не гнушаемся абзацами. Часто так получается, что все мыслимые текстовые фрагменты заключены в «дивы», а для очистки от флоатинга потом используется <br> с каким-нибудь классом. Если использовать <p>…</p> с содержимым в нужных местах, а в стилях для абзацев назначить clear:both, то можно избежать ненужного мусора в коде.
Использование ссылок и «системных спэнов». Не очень хорошая практика: вешать onClick на ссылку, которая никуда не ведёт. С точки зрения интерфейса — эффект обманутого ожидания, плюс некоторые пользователи смотрят в статусную строку или на всплывающую подсказку и видят, что со ссылкой что-то не то. Современная практика: делать span с особым классом, визуализирующийся как текст цвета ссылки, подчёркнутый прерывистой линией (dashed), чтобы было похоже на ссылку, но лишь отчасти. Это не правило, но серьёзная рекомендация. Для span можно использовать атрибут title, который будет выполнять роль всплывающей подсказки.
Запрет кэширования. В большинстве случаев достаточно пары тэгов:
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Expires" content="0">
Хотя бы на время отладки приложений.
При выделении (эмфазисе) фрагментов текста вместо тэгов <b> и <i> используем <strong> и <em>, если это действительно семантически оправдано и нет смысла делать спэны с классами. Такая замена соответствует спецификации XHTML и будущим стандартам HTML 5 (отказ от визуального форматирования в пользу логико-семантического).
Если используем таблицы, избавляемся от <thead> и <tbody>, если вдруг они невзначай генерируются редактором. Это устаревшие элементы.
Copyright © 1999–2010 LAR