Важнейшие практические принципы CSS кодирования, которые вредят нам.

Перевод статьи:  Our (CSS) Best Practices Are Killing Us.
Автор:  Nicole Sullivan.

Ранее в этом году, готовясь к выступлению на Webstock (*Статья была опубликована автором в апреле 2011 года.), я вдруг осознала, что мне придётся отменить запланированную речь. Я передумала делать доклад на тему «Ошибки масштабного CSS кодирования», так как поняла, что суть затрагиваемой в нем проблемы лежит намного глубже, чем это кажется на первый взгляд. Дело в том, что те принципы, которые по нашему мнению являются лучшими решениями большинства проблем, в действительности приводят к нежелательным результатам, которых мы изначально пытаемся избежать. И я осознала, что, несмотря на то, что это противоречит давно устоявшемуся суждению, в данном конкретном случае «упорство и труд ничего не перетрут». Каждый раз, начиная новый проект, мы обещаем себе, что «на этот раз я приложу все усилия, чтобы мой код был максимально четким и понятным», что «этот проект будет блестящим примером эффективного использования CSS». И со временем, в процессе добавления нового контента на сайт и его усовершенствования, некогда чистый код медленно, но уверенно превращается в запутанный клубок, состоящий из множества дублирующих фрагментов, усугубляя проблему своей непредсказуемостью.

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

Какие же из устоявшихся тенденций практического кодирования можно отнести к категории проблемных? Вот они:

  • classitis!
  • никогда не добавляйте элементы, нарушающие семантику документа;
  • не используйте несемантические имена классов;
  • применяйте селекторы потомков в исключительных случаях;
  • сайты должны иметь абсолютно идентичное отображение во всех браузерах.

Classitis!

Откуда, скажите на милость, мы можем знать какие аспекты CSS кодирования абсолютно положительны, а какие из них являются воплощением зла? Кто принимал эти решения и чем при этом руководствовался? Совпадают ли приследуемые ими цели с нашими? Поверьте, нет ничего плохого в использовании классов. В подавляющем большинстве случаев имена классов более полезны и влекут за собой меньше непредсказуемых последствий, чем использование идентификаторов (ID) или селекторов названий элементов (p, img, span и т.д.).

При помощи классов вы можете определять стили практически в любой ситуации. Суть в данном случае заключается в том, чтобы создать некий баланс между слишком объемными правилами классов, так называемыми «свалками», и слишком бедными в плане содержания классами. Другими словами, вы не должны использовать на столько скудные правила классов, каждое из которых содержит лишь одну пару свойство:значение. Имея в своем распоряжении набор экстремально маленьких классов с правилами, содержащими минимальное количество определений, вам будет чрезвычайно сложно удовлетворять требованиям дизайна в процессе его дальнейшего развития.

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

Классы – это наши лучшие друзья. А вот случаи множественного использования идентификаторов (ID) элементов, вот это действительно катастрофа. Избегайте такого стиля кодирования:

#sidebar #accounts #accountDetails h3{}

Никогда не используйте дополнительные не семантические элементы.

Никто не заинтересован в создании чересчур громоздкого HTML кода, перегруженного лишними элементами. С другой стороны, очень часто дополнительный элемент разметки может быть использован в качестве буфера между двумя наборами CSS правил, которые изначально не предназначались для прямого взаимодействия. Я, допустим, предпочитаю, чтобы определенные элементы декоративного оформления контейнера были независимы от его контента.

Если не расположить, скажем, элемент параграф <p> внутри блока с предусмотренными дизайнерским решением закругленными углами, а применить соответствующие стили непосредственно к элементу параграфу, то следующий раз чтобы таким же образом оформить любой другой, отличный от параграфа элемент, допустим элемент список <ul>, без дублирования стилей вам не обойтись. В таком случае это будет единственным выходом.

Но вы ведь хотите максимально эффективно использовать возможности HTML в своей разметке, применяя широкий набор элементов, таких как <p>, <ul>, <ol>, <li>, <h1>…<h6>, <strong>, <em> и т.д. В таком случае добавьте в разметку несколько элементов-обёрток, для того чтобы четко разграничить контент от контейнеров и отделить тем самым его декоративное оформление. Тогда ваш HTML код будет чистым, а CSS предсказуемым и читабельным.

Не допускайте применение не семантических имен классов.

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

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

Дискуссии в области семантики зашли слишком далеко. Она бесспорно должна присутствовать при рассмотрении общих вопросов, но зачастую я сталкиваюсь с ситуациями, когда разработчики интерпретируют определенные моменты стандартов неверно, пытаясь втиснуть понятие семантики в те области дизайна, где она вовсе не предусмотрена. Если в контексте дизайна между двумя объектами нет визуального отличия, то зачем все усложнять? Имена классов более полезны при использовании в рамках визуальной семантики, чем в случае привязки их к контенту.

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

Применяйте селекторы потомков в исключительных случаях.

Никогда не встречала столь ужасной рекомендации (Нет, ну я, конечно же преувеличиваю, но можно сказать, что в рамках CSS ее эффективность зависит от ситуации.). Селекторы потомков уместны только для выбора требуемого элемента, который входит в группу дочерних узлов одного родительского объекта (допустим панели закладок), и то с оговоркой, что вы абсолютно уверены в том, что в соответствующий фрагмент разметки вы не будете вносить изменения в будущем. Неужели так трудно это гарантировать? Думаю, что нет.

Однажды, один из дизайнеров представил мне панель, содержащую две группы закладок, к каждой из которых применялись разные стили. И в том случае, если для стилизации реализующего панель <ul> элемента вы уже применили селектор потомка, то добиваясь различного визуального оформления для двух групп ее закладок, вам придется заниматься переопределением стилей, которые в дальнейшем вам не понадобятся. В данном конкретном случае более предпочтительными являются имена классов и поскольку интересующие нас узлы принадлежат одному объекту, то они могут использоваться в комбинации с селекторами потомков.

Насколько я помню, единственным случаем, когда лично я допускаю использование селектора потомка совместно с селектором элемента – это стилизация элементов списка (<li>), и даже в этом случае мне достаётся, если кто-нибудь захочет использовать вложенные списки. Можно с уверенностью сказать, что было бы не лишним введение некоторого улучшения поддержки дочерних селекторов, направленного на упрощение подобного рода стилизации. А в идеале мы вообще не должны допускать случаи наследования стилей элемента контейнера его контентом.

Возьмем пример привязки стилей с использованием медиа блока (@media), то есть когда вы, допустим, рассматриваете вопрос стилизации изображения с помощью имени класса, применяемого в рамках определенного медиа блока. Да, это звучит вполне резонно до тех пор, пока мы вдруг не осознаем, что изображение, по сути, само по себе является отдельным объектом. И если вам в последующем понадобиться использовать конструкцию из нескольких вложенных медиа блоков, то ваши ожидания не будут оправданы и требуемые стили к вашему элементу изображению применены не будут. Проблему можно решить, если имя класса использовать в связке с названием элемента (в нашем случае изображением) — img.className.

На некотором промежуточном этапе работы над проектом вы, возможно, сочтете, что создание по одному объекту отображения для каждой различной ситуации вполне оправдано, поскольку такой подход облегчает процесс использования этих объектов. Но на CSS уровне вы вряд ли пожелаете связывать все воедино таким же образом.

Отображение сайта должно быть абсолютно одинаковым во всех браузерах.

Факт разночтения дизайна вашего сайта, это, конечно же, плохо, он усложняет процесс тестирования ресурса, но это совсем не означает, что он должен одинаково, с точностью до пикселя отображаться во всех существующих браузерах. Если вы попытаетесь, к примеру, предоставить пользователям IE6 возможность увидеть все прелести современного дизайна, то вы нанесете серьезный удар вопросу производительности. Сайт будет загружаться медленно, что в большей степени будет объясняться процессами перекомпоновки и перерисовки элементов при помощи JavaScript. Для пользователей ранних версий браузеров вопрос скорости загрузки сайта и его реакции на их действия более важен, чем закругленные углы.

* Примечание переводчика.

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *