Когда не следует применять селекторы потомков.

Перевод статьи:  When to Avoid the Descendant Selector.
Автор:  Louis Lazaris.

Тем из нас, кто не понаслышке знаком с принципами модульного или объектно-ориентированного CSS кодирования, не нужно напоминать, что необходимо максимально сокращать случаи применения селекторов потомков (или как их называют в спецификации — комбинаторов потомков).

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

.sidebar p {
color: hotpink;
font-size: 3em;
}

Всё, что находится перед открывающей фигурной скобкой и является селектором. Комбинатором в данном случае выступает символ пробела. Существует также ряд других видов комбинаторов, но в нашем, представленном выше случае мы имеем дело именно с комбинатором потомков.

Теперь, закончив с техническим определением селектора как такового, давайте перейдем к обсуждению того, что необходимо принимать во внимание при использовании такого рода селекторов.

Почему действие селекторов потомков ограниченно?

Чтобы понять почему селектор потомков может вызвать проблемы, давайте подробнее рассмотрим приведенный мной выше пример. Действие стилей, указанных в нашем CSS правиле, ограниченно не только элементом параграфа <p>, более того, они не будут иметь никакого эффекта в том случае, если параграф не является потомком элемента с именем класса .sidebar.

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

Данная тема затронута Николь Салливан (Nicole Sullivan) в теме OOCSS в рамках обсуждения вопроса «разделения контейнера и его контента».

В действительности ли OOCSS препятствуют применению селекторов потомков?

Этот вопрос затронут в рекомендациях на ту же тему — OOCSS FAQ, и отчасти ответ на него звучит следующим образом:

Нет, селекторы потомков не запрещены данным подходом кодирования, но их размещение слишком высоко в древовидной структуре DOM не желательно.

То есть, идея заключается в том, чтобы избегать использования селекторов потомков в тех случаях, когда это приводит к нежелательным ограничениям, в частности, не допускать «их размещения слишком высоко в древовидной структуре DOM». Совсем необязательно полностью исключать их использование (уверенна, большинство из вас убедились в том, что иногда селекторы потомков очень даже полезны).

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

Поэтому без боязни используйте комбинатор потомков в своих селекторах, но не допускайте экземпляров подобных этим:

.header p { }
.container div { }
.sidebar h2 { }

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

Нет, это не догма.

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

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

Обзор комментариев

Большинство комментариев к оригиналу данной статьи очень критичны и обвиняют автора в неправильном трактовании принципов OOCSS кодирования. Дело в том, что Луис Лазарис, советует разработчикам (прошу заметить, именно советует) не налегать на селекторы потомков именно высокого уровня DOM структуры. То есть, автор призывает сокращать разрыв между используемыми селектором элементами в плане иерархии структуры документа. Другими словами, если вам необходимо изменить уже определенные ранее стили конкретного элемента, который находится в другом, более специфическом месте, то либо устанавливайте для него новый класс, либо используйте для его выборки ближайший контейнер более высокого уровня.

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

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

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

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