Как стать автором
Обновить

Комментарии 36

С какого перепугу css язык программирования?
Думаю, что его можно считать декларативным DSL, хотя конечно это не очень принято.

Но статья, конечно, заставила задуматься что это немного сложнее, чем кажется.
Неожиданно, CSS является тьюринг-полным.
Другой вопрос, что неизвестно что лучше: кодить задачи на брейнфаке или на css.
Другой-другой вопрос, что CSS воспринимается и используется как декларативная шестеренка, поэтому обзывание его «языком программирования», это как называть микроскоп молотком.
Если речь идет об этой реализации правила 110, то она требует действий пользователя: постоянного нажатия Tab + space (сначала нужно накликать желаемое начальное состояние в первой строке, потом следовать инструкции). С таким же успехом Тьюринг-полными можно назвать комментарии на Хабре и камни на берегу моря. Мне кажется, это не совсем честная Тьюринг-полнота, т.к. требует активного участия человека в вычислениях, по крайней мере для меня как любителя портировать трехмерные движки на все подряд.
Оно не требует осмысленного участия человека и не требует принятия решений. Норм, ИМХО.
Какой лучший перевод, для computer language?

"Как и в любом компьютерном языке, для описания понятий...."


"Как и в любом языке компьютера, для описания понятий...."


я за второй вариант

> Он содержит только новое, что я узнала за последние несколько дней и чем хочу поделиться, вдруг это поможет кому-то ещё.

Это конечно неожиданно, потому что список достаточно большой, в нем много совершенно банальных вещей, которые не знать стыдно, и она google developer expert по web разработке.
Совершенно не удивительно, что с такими google developer expert новый gmail теперь две и более минут сохраняет статус «прочитано» у прочитанного письма.
Google developer expert — это не должность в гугл. Автор оригинальной статьи работает в ThoughtWorks.
Про справа налево могут начинающего верстальщика на собеседовании спросить в обычной конторе, а тут — гугл. А уж то, что порядок имеет значение, трудно не заметить.

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

Чтобы исправить это, я провела некоторые исследования и составила небольшой список


Странная логика. Почему кто-то ей должен был об этом говорить?
> Селектор потомков может дорого обойтись

Хорошо бы показывать доказательную ссылку на исследования, а не просто «мне так сказали». По логике селекторов, ничто не мешает анализировать теги «a» только внутри области старшего селектора и этим могут различаться различные движки.
НЛО прилетело и опубликовало эту надпись здесь
В Яндексе проводили много исследований по этому делу, и расказывали много раз на Субботниках, и было это 6-8 лет назад (в общем давно).
С тех пор многое что изменилось, в том числе в Firefox(а вот это было уже недавно) прилетел новый CSS парсер, который парсит по-человечески.

Век учись, век переучивайся.
Не совсем понятно что значит «по-человечески» с алгоритмической точки зрения. Я думаю можно завести какие-то эвристики, которые на достаточно ранних этапах будут отсекать некоторые селекторы, для некоторых веток DOM. Но как в целом поменять механизм проверки селектора от потомка к родителю совершенно не представляю. Единственный вариант, это поменять местами DOM и CSS, то есть не для каждого элемента DOM искать селекторы CSS, а для каждого селектора CSS искать DOM элементы, что частично соответсвует человеческой логики, но я не понимаю как это может эффективно работать с точки зрения машины.

Да, я глянул статью "Внутри супер-быстрого CSS-движка: Quantum CSS (aka Stylo)" и даже исходный код посмотрел, так как сам когда-то свой велосипед писал и мне интересно как эту логику реализуют другие. Оптимизации и распараллеливание заслуживают отдельного внимания, отсюда и может идти разговор о стоимости, особенно если стоимость определять в контексте усредненного приложения, тут даже есть предмет для исследований. Но общая логика алгоритма такая, что проверка селектора происходит рекурсивно, от потомка к родителю, а следовательно совет в статье логичный и является всего лишь следствием из алгоритма, никаких исследований для этого следствия не нужно.


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

НЛО прилетело и опубликовало эту надпись здесь
Не могут.
Не ожидал прочитать в 2019 баяны из 2010.
И правда, об этих вещах не пишут в starter tutorial. И многие о них так и не узнают, так как на большинстве проектов производительность css находится где-то в пределах погрешности. Сам я этой темой заинтересовался, когда начал пилить enterprise с чрезвычайно перегруженным dom. Теперь на собеседованиях фронтов и верстальщиков часто задаю вопросы о производительности css, как минимум на уровне приоритета селекторов и примеров «дорогих» css свойств. Как показывает практика — знание не очень распространенное
Сам я этой темой заинтересовался, когда начал пилить enterprise с чрезвычайно перегруженным dom

на большинстве проектов производительность css находится где-то в пределах погрешности.

Теперь на собеседованиях фронтов и верстальщиков часто задаю вопросы о производительности css

Это что, такая форма доминирования? Унижения? Издевательства? Вещь редкая, нужна мало где, так давайте как я буду её спрашивать у верстальщиков (которые зачастую новички) либо фронтов (которые мало касаются верстки)

Абсолютно нет, никакого доминирования и унижения. Эти вопросы не являются определяющими, основа — базовые знания JS и несколько задач опять таки по базовым знаниям.
Вещь редкая, нужна мало где

но нам нужна, поэтому при выборе из пяти, условно, верстальщиков, приоритет отдается тому, кто нам больше подходит.
либо фронтов (которые мало касаются верстки)

Может быть я не прав, но если фронт не умеет толково верстать — это у меня вызывает непонимание
Уже некоторое время как существует мир веб-приложений. Фронт может быть хорошим инженером и отлично уметь архитектуру\развязывание логики. Если ему в пару дать верстальщика, то все будут заняты своим делом и процесс будет очень хорошо распараллелен. Естественно, такой фронт может что-то сверстать, но это не будет «толково», потому что чистый верстальщик оттачивает этот навык каждый день.
Могу оказаться неправ, но редко кто желает быть верстальщиком на постоянной основе. Поэтому часто позиция верстальщика совмещается с джун позицией на фронте, со временем человек переходит в разработку, но память о боевой юности никуда не пропадает, поэтому такой фронт умеет верстать.
Если рассмотреть вариант когда человек сразу начинает как фронтенд софтвеер энжинир, не знает ничего про верстку, но пытается натянуть бизнесовую логику на непонятные особо конструкции языка разметки, манипулируя со стилями и DOM, особо не понимая как это устроено — я опять оказываюсь удивлен.
но пытается натянуть бизнесовую логику на непонятные особо конструкции языка разметки

А он и не должен это (натягивать логику на нтмл) делать — для примера на Реакте он может обеспечить разбивку на компоненты, и передавать этим компонентам правильные props-ы, а верстальщик уже на JSX верстает "тупые" компоненты

чрезвычайно перегруженным dom

Может сперва эту проблему решите, а потом уже будете "оптимизировать селекторы"?

Шаг 0: некоторым не говорили, что это «си эс эс», а не «ка эс эс»
Мы сейчас говорим о «цэ эс эс»?
Как я люблю описание на манер «Так надо делать, и не задавайте лишних вопросов»

Некоторые из дорогих свойств:
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 правила, не только для тех элементов, что непосредственно были затронуты, но и для всех соседей и, вместе с тем, для всех дочерних элементов. В общем случае, я думаю, это все мелочи, и экономия на спичках, но в каких-то особо сложных структурах, наверное, это может стать заметным.

Так вот и я так же думаю, все зависит от вложений, и как ими пользоваться, сам же псевдокласс в себе ничего затратного не имеет, как и остальные псевдоклассы, так что не понимаю почему его сравнивают с намного процессоемкими CSS свойствами. Да и как по мне тема затрат на вычисления довольно таки обширная, и тут нельзя просто сказать что данные свойства лучше избегать, а другие можно использовать повсеместно.
О, вопрос по теме:
Допустимы ли inline комментарии наподобие:
something: /*comment*/red;
CSS валиден, но не красив, я бы не стал так писать.
Мне это нужно для poor man's препроцессинга как метки определенных точек.
Просто IE отказался читать такое, хотя вроде по стандарту комментарий может быть где угодно между term'ами. Вот и думаю — то ли IE сачкует, то ли я стандарт неправильно понимаю.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.