Comments 36
Но статья, конечно, заставила задуматься что это немного сложнее, чем кажется.
Это конечно неожиданно, потому что список достаточно большой, в нем много совершенно банальных вещей, которые не знать стыдно, и она google developer expert по web разработке.
и иногда я понимаю, что о некоторых важных нюансах CSS мне никто не рассказал, потому что люди просто не тратят время на изучение этой темы.
Чтобы исправить это, я провела некоторые исследования и составила небольшой список
Странная логика. Почему кто-то ей должен был об этом говорить?
> Селектор потомков может дорого обойтись
Хорошо бы показывать доказательную ссылку на исследования, а не просто «мне так сказали». По логике селекторов, ничто не мешает анализировать теги «a» только внутри области старшего селектора и этим могут различаться различные движки.
С тех пор многое что изменилось, в том числе в Firefox(а вот это было уже недавно) прилетел новый CSS парсер, который парсит по-человечески.
Век учись, век переучивайся.
Да, я глянул статью "Внутри супер-быстрого CSS-движка: Quantum CSS (aka Stylo)" и даже исходный код посмотрел, так как сам когда-то свой велосипед писал и мне интересно как эту логику реализуют другие. Оптимизации и распараллеливание заслуживают отдельного внимания, отсюда и может идти разговор о стоимости, особенно если стоимость определять в контексте усредненного приложения, тут даже есть предмет для исследований. Но общая логика алгоритма такая, что проверка селектора происходит рекурсивно, от потомка к родителю, а следовательно совет в статье логичный и является всего лишь следствием из алгоритма, никаких исследований для этого следствия не нужно.
Если выразить это более конкретно, но попрежнему умозрительно, то я хочу сказать, что возможен такой пример CSS и HTML, который будет антипримером, данного в статье, совета и будет плохо работать во всех браузерах, так как будет обходить условия всех возможных оптимизаций. Условия там элементарные и очень ограничивают возможности применения этих оптимизаций.
Сам я этой темой заинтересовался, когда начал пилить enterprise с чрезвычайно перегруженным dom
…
на большинстве проектов производительность css находится где-то в пределах погрешности.
…
Теперь на собеседованиях фронтов и верстальщиков часто задаю вопросы о производительности css
Это что, такая форма доминирования? Унижения? Издевательства? Вещь редкая, нужна мало где, так давайте как я буду её спрашивать у верстальщиков (которые зачастую новички) либо фронтов (которые мало касаются верстки)
Вещь редкая, нужна мало где
но нам нужна, поэтому при выборе из пяти, условно, верстальщиков, приоритет отдается тому, кто нам больше подходит.
либо фронтов (которые мало касаются верстки)
Может быть я не прав, но если фронт не умеет толково верстать — это у меня вызывает непонимание
Если рассмотреть вариант когда человек сразу начинает как фронтенд софтвеер энжинир, не знает ничего про верстку, но пытается натянуть бизнесовую логику на непонятные особо конструкции языка разметки, манипулируя со стилями и DOM, особо не понимая как это устроено — я опять оказываюсь удивлен.
но пытается натянуть бизнесовую логику на непонятные особо конструкции языка разметки
А он и не должен это (натягивать логику на нтмл) делать — для примера на Реакте он может обеспечить разбивку на компоненты, и передавать этим компонентам правильные props-ы, а верстальщик уже на JSX верстает "тупые" компоненты
чрезвычайно перегруженным dom
Может сперва эту проблему решите, а потом уже будете "оптимизировать селекторы"?
Некоторые из дорогих свойств:
border-radius
box-shadow
filter
:nth-child
position: fixed
Почему свойства border-radius / box-shadow / filter являються ресурсо затратными это понятно, но вот почему к этому списку припадает :nth-child? Не думаю что он настолько же тяжелый как тот же box-shadow, а так же насколько сильно отличаеться :nth-child(2n) от :nth-child(2) по производительности.
Так же можно было немного сказать про position: fixed / absolute, что они отрисовываються вообще отдельно, и так же просчитываються отдельно.
Сама логика вычисления позиции и проверки на соответствие уравнению элементарная и затрат, заслуживающих внимания, там нет. Проблема :nth-child и прочих подобных псевдоклассов, зависящих от положения, заключается в особенностях работы кэша. При использования таких псевдоклассов и при изменении DOM структуры, приходится заново искать CSS правила, не только для тех элементов, что непосредственно были затронуты, но и для всех соседей и, вместе с тем, для всех дочерних элементов. В общем случае, я думаю, это все мелочи, и экономия на спичках, но в каких-то особо сложных структурах, наверное, это может стать заметным.
Допустимы ли inline комментарии наподобие:
something: /*comment*/red;
Чего мне никогда не говорили о CSS