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

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

Кажется, в angular material перешли на классы именно по этой причине.

Честно говоря, не нашел, где они перепилили свою CSS либу на классы. Можете поделиться ссылкой? В этом случае не пришлось бы переписывать самому.
Уточню, в доке они пишут:
Due to performance problems when using Attribute Selectors with Internet Explorer browsers…
...Layout directives dynamically generate class selectors at runtime…
Developers should continue to use Layout directives in the HTML markup as the classes may change between releases.

Вольно переведу:
Из-за проблем с производительностью Internet Explorer при использовании атрибутов…
… Директивы разметки динамически генерируют классы во время выполнения…
Разработчикам следует продолжать использовать декларативный подход, поскольку классы могут быть изменены между версиями.
А data-* атрибуты случаем не тестировали?
Нет. Сомневаюсь, что есть принципиальная разница.

А отправить but report Microsoft не думали?

НЛО прилетело и опубликовало эту надпись здесь
Я так понимаю, эта проблема была актуальна еще у дедушки IE. Когда писал статью, то всплывали смутные воспоминания о том, как я де-то когда-то мельком видел инфу, что в IE аттрибуты тормозят. Тем не менее отправить баг репорт стоит. Спаибо за мысль.

Что-то не вижу в выводах, чтобы вы отправили эту информацию разработчикам Edge. По-моему это первый вывод что стоило бы сделать из данной ситуации.


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

А откуда вы заранее узнаете, какие правила используются? Особенно если атрибуты изменяются, что вполне типично для интерактивного UI.


Графики кстати странные, я бы не был так уверен, что кривая экспоненциальная (хотя исключать скажем полиномиальную зависимость тоже бы не стал бы). Может автор ответит, почему от 0 до 500 и от 500 до 1000 разное расстояние по оси X?

Я не об экспоненциальности как таковой, а о том, что человек сделал отличный анализ ситуации и было бы неплохо чтобы разработчики это исправили.

Не, ну понятно что практически это все равно, и то и другое плохо. Но все-таки было бы интересно понять, насколько плохо.


Насчет исправили — написать баг репорт конечно же стоит, но я просто смотрю практически. Чтобы поиск по атрибуту был быстрее, нужно строить некий индекс по значениям атрибута. А он будет занимать память. И еще его нужно обновлять, потому что атрибуты (да и набор правил CSS) могут меняться, на что тоже будут тратиться ресурсы. Ну т.е. я это к чему — любая такая оптимизация, она есть компромисс. Нельзя оптимизировать все операции. Нельзя оптимизировать на базе изменения одной операции.

Ось логарифмическая. Если не удобно смотреть в таком представлении, то вы можете скопировать себе гуглодок по ссылке и отредактировать графики.

Если это несложно, было бы лучше это просто немного пояснить, прямо под графиком. Ну, на будущее, если кто-то еще прибежит почитать через год-другой.

Если делать ось не логарифмической, то значения в начале сбиваются в кучу и их не удобно читать

Автор, что у вас за сетка такая на графиках странная? Ось X неравномерная как будто, вводит в заблуждение.

Погодите, погодите. Логарифмическая или линейная — но на оси все-же принято рисовать штрихи через одинаковые промежутки. Ну т.е. между 10^1, 10^2 и 10^3 рисуют отрезок одинакового размера.


А на этих графиках отрезок от 0 до 500 выглядит вдвое длиннее, чем от 500 до 1000. При этом в обоих отрезках, если верить написанному, по 500 единиц. Вот я о чем. Ну т.е. да, скорее всего оси логарифмические, но разные размеры отрезков сбивают все-таки с толку.

Замечу, что там не от 0 шкала, а от 100. То есть штрихи на 100, 500, 1000, 5000. log(500/100)~= 0.7. log(1000/500) ~= 0.3. log(5000/1000)~= 0.7. log(10000/5000) ~= 0.3. Т.е. как раз получается, что там интервалы более чем двойной длины чередуются с короткими.


На логарифмической шкале штрихи получаются равномерными, если их привязывать к "круглым" (по основанию) числам. Например 1, 10, 100, 1000 (для основания 10). А если возникает желание поставить промежуточные деления, но с привязкой к круглым числам, то шкала сразу же перестаёт быть равномерной. И в этом нет ничего необычного для тех, кто привычен к логарифмической шкале.

А у вас начальство требует обязательной поддержки Edge? Он же вроде не особо популярен…
У нас начальство, например, не нём (Edge) и сидит…
Определенные заказчики на определенных проектах требуют. По дефолту нет.
По последней таблице получается, что Chrome и Edge работают даже медленнее, если правила не применялись. Это действительно так, или столбцы перепутаны?
Нет. Все именно так и обстоит. Возможно, разницу можно списать на параллельные случайные процессы в системе, и предположить, что время одинаково примерно. Другой вариант — для каждого отдельного элемента в DOM дереве браузер пытается вычислить окончательные стили в CSS дереве. В случае если стили могут быть найдены для конкретного элемента, то браузеру достаточно обойти только часть дерева, а если их нет, то он обходитвсе дерево, чтобы удостовериться, что подходящих стилей нет. Повторюсь, что это только предположение.

Вполне нормальное предположение. Скорее всего есть перебор элементов и перебор правил CSS. Если вы что-то нашли в CSS, то скорее всего можно на этом перебор закончить (особенно если правила у вас отсортированы до этого). Если нет — то перебираете до конца таблицы.

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