После тщательного анализа HTML и CSS кода, который постоянно переделывается, можно сделать выводы, которые должны помочь читателю в этом нелегком деле.
В этой статье не будем привязываться к конкретным реализациям и готовым рецептам, дабы избежать основной проблемы любой CSS документации — за время написания статьи выйдет пара-тройка браузерных обновлений. И советы будут попросту бесполезны.
Начну с базового: если в каком-то браузере страница отображается не так, как задумано, значит вы сделали что-то неправильно. Создатели браузеров, и в том числе и IE6 — не дураки. Они думали головой, прежде чем задавать правила рендеринга и способа отображения. Любой сползший элемент сползает из-за особой интерпретации совокупности CSS свойств, а не потому что «IE6 глючный». Поэтому, чтобы решить проблему сползшего элемента, нужно понять почему он туда сполз.
Вскользь коснемся понятия кроссбраузерности. Каков рецепт кроссбраузерной верстки? Верстайте сразу для всех поддерживаемых браузеров. Только для всех и сразу. Правило «сверстаю для файерфокса, а потом буду фиксить для остальных» не работает. Поди потом разберись, кто виноват и что делать, когда уже написано куча мала CCS-а. Конечно, в таком случае, в ход пойдут «грязные хаки» и условные комментарии. Безусловно, вообще без хаков не обойтись, ибо различия в рендеринге все-же присутствуют. Какие хаки нужно запомнить? Никакие. Минутный поиск выдаст тонну решений. Сначала нужно определится со списком браузеров (платформ, версий, устройств), некоторые фундаментальные решения не позволят расширить список в конце разработки. Не подумайте, что я советую после каждого изменения обходить весь список и проверять не поехало ли что-либо. Частота тестирования приложения в разных браузерах разная. Начинаем верстать в любимом файерфоксе с любимым файербагом. Периодически открываем IE7, чтобы убедится, что ничего не поехало. Немного реже открываем оперу и сафари и девятый эксплорер. И уж совсем редко — хром.
Кстати, такой порядок частоты проверки в разных браузерах легко объясним. Файерфоксовский Gecko хотя и аутентичен среди популярных браузеров, но очень близок к WebKit’у и оперовскому Presto. Safari и Chrome используют WebKit и почти полностью идентичны в алгоритмах рендеринга. Последняя версия браузеров еще мало изучена и эти браузеры остается темной лошадкой нашего забега —особенно последний IE. Предпоследний IE достаточно хорошо соблюдает стандарты, и не доставляет особых хлопот, чего нельзя сказать про младших братьев оного — седьмой (Trident V) и шестой (Trident IV) версии интернет эксплорера. Плюсом сложившейся ситуации могу отметить, что эти две версии очень похожи между собой — если будет выглядеть хорошо в IE7, мало что придется исправлять в IE6. Тем более, что поводов поддерживать шестой и седьмой эксплорер все меньше и меньше.
Что касается CSS шаблонов и фреймворков. Самая крупная, переносимая из проекта в проект, частица должна быть не больше решения «как расположить такие-то элементы в такой-то последовательности». Решения типа «трехколоночный макет с прижатым футером и горизонтальным меню» не работают в силу того, что на свое решение требуют генерации кучи неконтролируемого и сложноизменяемого кода. Любое изменение уже существующего стороннего решения вызовет головную боль и приведет к переписыванию кода с нуля.
В довесок к сказанному стоит учесть тот факт, что такие готовые решения никаким образом не учитывают последующие изменения CSS: меняя внутренние отступы у div, лежащих внутри
Отдельно упомяну про структуру css файлов и картинок. Существуют тысяча и один способ грамотно распределить картинки и цээсэски. А вот неправильных очень мало.
Вспомним про самый ужасный из всех ужасных способов — единственный файлик
Еще примером не менеее ужасной, но более аккуратной тактики расположения и именования при верстке может служить такая ситуация. Картинки располагаются не в одной папке, а располагаются в подпапках по назначению. Всевозможные фоны кладуться в папку
Логичным остается вопрос о повторном использовании картинок для двух разных сущностей. Примером может служить дизайн, в котором строка в списке последних новостей имеет такой же фон, что и элемент в списке продуктов. В таком случае есть несколько решений. Например, фон можно дублировать в две разные папки
Также распространен алгоритм скинов для расположения файлов. В таком случае внутри css-файлов указывается относительный путь к картинкам и таблицы стилей и картинки кладутся в одну общую папку. Например, в корне сайта, внутри папки
А в css-файлах фоны указываются так:
Вместо указания абсолютных путей (от корня).
О валидациях и валидаторах стоит упомянуть в контексте данной темы. Правильно утверждают верстальщики студии Лебедева говоря, что лучшей валидатор — это браузер. Если страница выглядит идеально во всевозможных браузерах, то не о чем беспокоиться. Но стоит помнить о том, что главный козырь в валидном коде — адекватная реакция на него будущих браузеров. Сразу пример. Во времена становления третьего файерфокса автором был написан код, в котором внутри ссылки помещался здоровый лапоть текста со всевозможной разметкой:
Клик на внешнюю ссылку обрабатывался, в результате чего выпадало меню и что-то там делало, что не относится к текущей теме. Но после выхода Хрома автор обнаружил, что вышеуказанный код не работает в новом браузере. Проблема скрывалась в невалидном коде — внутри ссылок нельзя располагать параграфы (как и любые другие блочные элементы разметки).
Из документации:
В результате чего код был переписан с учетом требований валидного кода и проблемы самоустранились.
В итоге можно сформулировать что стантарты нужно соблюдать до тех пор, пока сами стандарты не препятствуют достижению целей и вариантов написать код валидно нет. Иными словами соблюдайте стандарты всегда и нарушайте это правило будучи уверенным в своей правоте.
В этой статье не будем привязываться к конкретным реализациям и готовым рецептам, дабы избежать основной проблемы любой CSS документации — за время написания статьи выйдет пара-тройка браузерных обновлений. И советы будут попросту бесполезны.
Начну с базового: если в каком-то браузере страница отображается не так, как задумано, значит вы сделали что-то неправильно. Создатели браузеров, и в том числе и IE6 — не дураки. Они думали головой, прежде чем задавать правила рендеринга и способа отображения. Любой сползший элемент сползает из-за особой интерпретации совокупности CSS свойств, а не потому что «IE6 глючный». Поэтому, чтобы решить проблему сползшего элемента, нужно понять почему он туда сполз.
Вскользь коснемся понятия кроссбраузерности. Каков рецепт кроссбраузерной верстки? Верстайте сразу для всех поддерживаемых браузеров. Только для всех и сразу. Правило «сверстаю для файерфокса, а потом буду фиксить для остальных» не работает. Поди потом разберись, кто виноват и что делать, когда уже написано куча мала CCS-а. Конечно, в таком случае, в ход пойдут «грязные хаки» и условные комментарии. Безусловно, вообще без хаков не обойтись, ибо различия в рендеринге все-же присутствуют. Какие хаки нужно запомнить? Никакие. Минутный поиск выдаст тонну решений. Сначала нужно определится со списком браузеров (платформ, версий, устройств), некоторые фундаментальные решения не позволят расширить список в конце разработки. Не подумайте, что я советую после каждого изменения обходить весь список и проверять не поехало ли что-либо. Частота тестирования приложения в разных браузерах разная. Начинаем верстать в любимом файерфоксе с любимым файербагом. Периодически открываем IE7, чтобы убедится, что ничего не поехало. Немного реже открываем оперу и сафари и девятый эксплорер. И уж совсем редко — хром.
Кстати, такой порядок частоты проверки в разных браузерах легко объясним. Файерфоксовский Gecko хотя и аутентичен среди популярных браузеров, но очень близок к WebKit’у и оперовскому Presto. Safari и Chrome используют WebKit и почти полностью идентичны в алгоритмах рендеринга. Последняя версия браузеров еще мало изучена и эти браузеры остается темной лошадкой нашего забега —особенно последний IE. Предпоследний IE достаточно хорошо соблюдает стандарты, и не доставляет особых хлопот, чего нельзя сказать про младших братьев оного — седьмой (Trident V) и шестой (Trident IV) версии интернет эксплорера. Плюсом сложившейся ситуации могу отметить, что эти две версии очень похожи между собой — если будет выглядеть хорошо в IE7, мало что придется исправлять в IE6. Тем более, что поводов поддерживать шестой и седьмой эксплорер все меньше и меньше.
Что касается CSS шаблонов и фреймворков. Самая крупная, переносимая из проекта в проект, частица должна быть не больше решения «как расположить такие-то элементы в такой-то последовательности». Решения типа «трехколоночный макет с прижатым футером и горизонтальным меню» не работают в силу того, что на свое решение требуют генерации кучи неконтролируемого и сложноизменяемого кода. Любое изменение уже существующего стороннего решения вызовет головную боль и приведет к переписыванию кода с нуля.
В довесок к сказанному стоит учесть тот факт, что такие готовые решения никаким образом не учитывают последующие изменения CSS: меняя внутренние отступы у div, лежащих внутри
.content, нельзя быть уверенным, что это не вызовет коллапс на уровне меню в старой версии IE.Отдельно упомяну про структуру css файлов и картинок. Существуют тысяча и один способ грамотно распределить картинки и цээсэски. А вот неправильных очень мало.
Вспомним про самый ужасный из всех ужасных способов — единственный файлик
user.css и папочка images с, извините, насраными туда картинками. Некоторые умники догадываются о том, что должна быть какая-то структура в ресурсах и именуют картинки с приставками и суффиксами. Например, "article-bg.png" или "product-li-bg.png". Давайте отстранимся от CSS и представим себе жесткий диск такого разработчика. Фильмы лежат в одной папке, но вот именуют такие файлы, допустим так: "alien_life_documental_discovery.avi" или "pelmeni_vs_pyatigorsk_kvn_2008_polufinal.avi". При большом количестве файлов ориентироваться в этой куче малой невозможно. Оставим полемику на тему автосортировщиков медиатек (iTunes, Windows Media Player или подобное) для другой статьиЕще примером не менеее ужасной, но более аккуратной тактики расположения и именования при верстке может служить такая ситуация. Картинки располагаются не в одной папке, а располагаются в подпапках по назначению. Всевозможные фоны кладуться в папку
images/bgs, иконки — в папку images/icons. Такой способ неудачен из-за неправильной класификаций ресурсов. Большую практичность принесет разделение картинок не по сходству использования, а по логическому сходству — все картинки, принадлежащие к новостям, следует класть в папочку images/news и называть "bg.png", "li.png", "first-item.png". Такое расположение предрасполагает разделение ресурсов, в следствии чего ресурсы легко контролируются.Логичным остается вопрос о повторном использовании картинок для двух разных сущностей. Примером может служить дизайн, в котором строка в списке последних новостей имеет такой же фон, что и элемент в списке продуктов. В таком случае есть несколько решений. Например, фон можно дублировать в две разные папки
articles и products. Это следует делать по той же причине, что и минимальное количество букв в пароле у пользователя и минимальная длинна заголовка статьи не должны быть одной переменной. Или как вариант, переименовать сущность в более общую и создать папку не articles и news_items, а как-то более общно — publications, или как-то так. Дилема выбора имени для общей сущности между двумя сущностями натянута. В случае одинакового вида двух разных сущностей их можно обобщить по какому либо критерию, ибо это уже сделал дизайнер. Случай скупого дизайна «главной страницы и одной внутренней» мы не рассматриваем, как клинический.Также распространен алгоритм скинов для расположения файлов. В таком случае внутри css-файлов указывается относительный путь к картинкам и таблицы стилей и картинки кладутся в одну общую папку. Например, в корне сайта, внутри папки
themes создать папки stylesheets и images. Это никоим образом не влияет на структуру папок внутри папки images. Прошу заметить, что некоторые фреймворки предоставляют только такой способ интеграции собственных стилей. Поэтому знание о фреймворке перед началом верстки необходимо. Но это совсем другая история.А в css-файлах фоны указываются так:
background-image: url(../images/articles/bg.png)
Вместо указания абсолютных путей (от корня).
background-image: url(/images/articles/bg.png)
О валидациях и валидаторах стоит упомянуть в контексте данной темы. Правильно утверждают верстальщики студии Лебедева говоря, что лучшей валидатор — это браузер. Если страница выглядит идеально во всевозможных браузерах, то не о чем беспокоиться. Но стоит помнить о том, что главный козырь в валидном коде — адекватная реакция на него будущих браузеров. Сразу пример. Во времена становления третьего файерфокса автором был написан код, в котором внутри ссылки помещался здоровый лапоть текста со всевозможной разметкой:
<a href="#" onclick="editMe(); return false;">
<p>Lorem ipsum dolor set...</p>
</a>
Клик на внешнюю ссылку обрабатывался, в результате чего выпадало меню и что-то там делало, что не относится к текущей теме. Но после выхода Хрома автор обнаружил, что вышеуказанный код не работает в новом браузере. Проблема скрывалась в невалидном коде — внутри ссылок нельзя располагать параграфы (как и любые другие блочные элементы разметки).
Из документации:
One possible cause for this message is that you have attempted to put a block-level element (such as "<p>" or "<table>") inside an inline element (such as "<a>", "<span>", or "<font>").В результате чего код был переписан с учетом требований валидного кода и проблемы самоустранились.
В итоге можно сформулировать что стантарты нужно соблюдать до тех пор, пока сами стандарты не препятствуют достижению целей и вариантов написать код валидно нет. Иными словами соблюдайте стандарты всегда и нарушайте это правило будучи уверенным в своей правоте.
