Комментарии 26
Кажется, в angular material перешли на классы именно по этой причине.
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 при использовании атрибутов…
… Директивы разметки динамически генерируют классы во время выполнения…
Разработчикам следует продолжать использовать декларативный подход, поскольку классы могут быть изменены между версиями.
А отправить but report Microsoft не думали?
Что-то не вижу в выводах, чтобы вы отправили эту информацию разработчикам 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 ненавидит ваши атрибуты