Бравзер читає CSS-селектори справа наліво.
Це загальновідомий факт, який, однак, потребує певного пояснення. По-перше, треба розуміти, коли це стається, а по-друге — чи завжди так.
Цей процес відбувається між етапом коли побудовані DOM та CSSOM та етапом render-tree. Це так званий style computation — крок, під час якого бравзер визначає, які стилі до якого елемента застосовуються. І саме тоді йому потрібно знайти відповідність між селектором та елементос в DOM.
Чому ж справа наліво? Усе просто — це зменшує кількість кандидатів для перевірки. Якби бравзер йшов селектором зліва направо, тобто зверху вниз DOM-деревом, йому б довелось перевіряти все дерево повністю. Натомість він відразу відсікає невідповідні кінцеві "листки" дерева, і прямує вгору від цільового елементу, який визначається найправішим простим селектором.
Погляньмо на приклад:
.card p ~ a.button
Тут бравзер відразу шукатиме усі
a.button, потім пройдеться його попередніми сусідами, які є p, і для кожного з них знайде безпосереднього батька з класом .card. Що примітно, бравзер навіть не "шукатиме" ці елементи, бо побудує індекс за тегами й класами ще на етапі побудови DOM-дерева. Тому розпочне пошук відразу з потрібних вузлів. Якби ми йшли зліва направо, то бравзер мусив би перебирати усі
.card, незалежно від того, чи містять вони p, потім — усі p в таких .card, незалежно від того, чи є у них сусідні a.button.Цей механізм, до речі, був закладений в CSS ще від самого початку появи технології.
А на цьому місці прийшов час поставити вподобайку та поширити допис. Хіба нє?
Взагалі, метчинг запускається доволі часто, коли постає потреба перезапустити style-calculation, наприклад, коли змінюються CSS-правила. Наприклад, на додачу до вище згаданого, коли ми змінюємо атрибути елементу з попереднім селектором (в цьому прикладі
p або .card). Чи коли змінюється структура DOM: переміщення, додавання, видалення вузлів, а також коли є динамічні псевдокласи.Але перерахунок відбувається точково, лише для потенційно зачеплених вузлів, а не по усьому дереву.
Важливо памʼятати, що DOM API не використовує саме цей рушій, але окремі операції можуть виглядати схоже. Наприклад,
closest() ззовні може нагадувати рух селектором справа наліво, бо йде вгору по дереву. Проте під капотом він просто розбиває комплексний селектор на частини й викликає matches() на кожному предку. matches() же працює через Selector API, а не через CSS matching, тому алгоритм там зовсім інший.Той же
querySelector прямує вниз деревом, а селектор перебирає зліва направо. І операції з DOM використовують Selector API, а не іпмлементацію CSS-рушія, тож і алгоритми, і оптимізації, і підходи загалом можуть суттєво відрізнятись.Загалом цей підхід спрямований не на якесь там "прискорення селекторів", а для забезпечення контрольованості інвалідації стилів. Завдяки такому напрямку браузер не перевіряє весь DOM, а працює локально — що й дозволяє CSS залишатися ефективним навіть на велетенських деревах.
Однак це не означає, що тепер можна видихнути і писати селектори на 15 складових. Треба памʼятати, що бравзеру однак доводиться виконувати титанічний обсяг роботи, особливо в умовах високодинамічних інтерфейсів. І якщо ми йому в цьому допоможемо, пишучи максимально прості селектори, він на нас точно не образиться.
Що почитати:
📖 The truth about CSS selector performance
@babichdev