Оказывается, чтобы выбрать элемент, принадлежащий классам foo и bar одновременно (<div class="foo bar">, например), то можно писать так:

div.foo.bar { ... }

Выяснил случайно экспериментально. Не знал, стыдно.

Собственно, перепал мне не так давно небольшой заказец. Вроде и несложный — а потанцевать с бубном немного пришлось. А всё из-за того, что заказчик оказался немного «падкой на дизайн блондинкой» (образно говоря), и требовал строгого соответствия конечного результата макету. Требовал попиксельно, и его совершенно не волновали такие вопросы, как валидность, семантичность и всё такое. «Хоть таблицами сверстай, а сделай». И сегодня речь пойдёт о том, как в таких условиях сделать весьма хитровыделанно нарисованное меню табами. Как и за свой код не устыдиться, и не пасть в грязь лицом перед заказчиком, вот в чём вопрос?

После заметки о Peppy я почти обрадовался — вот оно, счастье. Наконец появился движок CSS-селекторов, который делает тоже самое, что и jQuery, только быстрее. Сильно быстрее.

Радоваться было недолго, как только я посмотрел в код, то немного ужаснулся: он не соответствовал моим представлениям об исключительной производительности. Совсем не соответствовал. Точнее, немного удовлетворял, но не до конца. Поэтому сразу встал вопрос: а если быстрее?

Почему нельзя сделать быстрое мини-ядро для CSS-селекторов, которое обеспечит базовую функциональность для работы с DOM (ну, совсем базовую — просто выборку элементов, например)? И, самое главное, чтобы это работало не медленнее (в идеале, даже быстрее), чем нативные вызовы.

После статьи «Разгоняем CSS-селекторы: стоит ли?» было предложено рассмотреть несколько дополнительных случаев, учитывающих транзитивность селекторов (например, насколько быстрее a c, чем a b c, или наоборот). Данное исследование посвящено как раз разбору таких случаев.

Методика

Методика и уменьшение погрешности подробно рассматривались в первой статье, на них сильно много останавливаться не буду. Скажу лишь, что при наращивании количества классов и идентификаторов Opera стала значительно медленнее (раза в 3) отображать код (при этом общий его объем увеличился примерно в 1,5-2 раза). Скорее всего, в следующую статью войдет исследование влияния количества классов/идентификаторов/размера кода на общую производительность браузера.

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

читать дальше на webo.in →

Виталию Харисову посвящается

После перевода заметки «Оптимизируем CSS-производительность» и справедливых замечаний Виталия  vithar, я решил поставить серию экспериментов по скорости работы CSS-селекторов внутреннего движка браузеров. Результаты получились весьма забавными, а местами, наверное, даже интересными.

Методика. Размер файлов

Естественно, что скорость работы одиночного CSS-правила весьма высока, и даже десятки и сотни их не должны заметно замедлить работу браузеров. Поэтому нужно ставить эксперимент по работе с несколькими тысячами правил, иначе точность результатов будет весьма невысока. Использовать JavaScript для генерации HTML/CSS-кода не представляется разумным, ибо тогда придется учитывать еще и скорость работы JS-движка в браузерах, в итоге, эксперимент будет недостаточно чистым.

В конце концов, было решено сгенерить статичные файлы (порядка 300Кб), которые будут содержать достаточное число различных CSS-селекторов. Это самое «достаточное» число подбиралось по нескольким параметрам, в том числе: размер файла (гонять несколько Мб через браузер и интернет совсем не хотелось) и скорость работы HTML/CSS-кода в браузерах (она должна быть достаточно низкой, чтобы файлы в несколько сотен Кб уже заметно тормозили при открытии).

читать дальше на webo.in →