Написание эффективного CSS

Ok Итак, в другом вопросе что-то обсуждалось, и эта ссылка была упомянута:

https://developer.mozilla.org/en/Writing_Efficient_CSS

в этой статье они говорят некоторые вещи, которые я не знал, но прежде чем я спрошу о них, я должен спросить это... Это относится к CSS, интерпретируемому Firefox? Простите мою noobness, но я не был уверен, что они имел в виду интерфейса в Mozilla. (не бейте меня!)

Если это применимо, когда они скажи:

избежать селектор!

селектор потомков является наиболее дорогой селектор в CSS. Это ужасно дорого, особенно если правило с помощью селектора находится в теге или универсальная категория. Часто что действительно нужные ребенку селектор. Использование потомка селектор запрещен в UI CSS без явное одобрение вашей кожи владелец модуля.

* BAD - treehead treerow treecell { }
* BETTER, BUT STILL BAD (see next guideline) - treehead > treerow > treecell { }

потомок селектор-это просто пространство? И тогда какая разница между ребенком и потомком? Ребенок-это элемент внутри другого, но разве это не то же самое, что и потомок? Пока я пишу, мне кажется, я все понял. Потомок может быть ребенком / внуком/правнуком / и т. д.? И ребенок только один?

Извините еще раз за глупый уровень мой вопрос... просто интересно, потому что я постоянно использую потомков в моем CSS для моего сайта. Но да, если дело не в этом. Firefox тогда весь этот вопрос бессмыслен...

Если это не о Firefox, есть ли у кого-нибудь ссылка на статью, объясняющую эффективность для Firefox или браузеров в целом?

8 ответов


прежде всего-предложения в этой статье являются не для html-страниц - они специально для Mozilla UI-XUL, поэтому это может быть лучшей практикой для XUL, но не для html.

применение CSS на средней HTML-странице - одна из самых быстрых вещей, чем при загрузке страницы.
Кроме того, статья может предложить самый быстрый способ применения правил css, но какой ценой? Например, они предлагают не иметь больше, чем один класс за правило:

плохо .treecell.отступ { }
ХОРОШИЙ. - treecell-indented { }

почти эпатажная. Это может привести к более быстрому CSS, но кого это волнует? Предполагая, что у вас уже есть .treecell и .indented, следуя этим предложениям, приводит к сложная логика, более трудное обслуживание,дублированный css правила, более жесткий JavaScript (который стоит намного больше, чем CSS) и т. д.
Они предлагают не используя полное богатство CSS селекторы и замена этих селекторов плоскими классами, что является позором.


потомок может быть ребенком / внуком/правнуком / и т. д.? И ребенок только один?

Да, точно. Поскольку ребенок может быть только одним глубоким, есть гораздо меньшее пространство, которое движок рендеринга должен рекурсивно искать, чтобы проверить, соответствует ли правило или нет.

и да, эта статья касается как Firefox, так и браузеров в целом. Большинство (все?) из того, что в нем применяется к любому движку рендеринга страницы.


...Когда я пишу, я думаю, что, возможно, понял это. Потомок может быть ребенком / внуком/правнуком / и т. д.? И ребенок только один?

в самом деле.

одна вещь, которую я могу добавить на стороне эффективности вещей:Не используйте *, если вы действительно не имеете в виду это. Это довольно интенсивно, поскольку правила идут, и большинство людей могут уйти, просто указав элементы, которые они действительно хотят нацелить.


"родитель > ребенок" - это только один шаг вниз, тогда как" потомок предка " может быть одним или несколькими шагами вниз.

еще лучше использовать теги "#id " везде, где это возможно, чтобы было меньше поиска DOM.


UI CSS предназначен для стилизации внутренних частей браузера-диалог настроек, интерфейсы расширений и т. д.

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


проблема с дочерним селектором заключается в том, что он не так хорошо поддерживается. Конечно, это могло быть исправлено в новых браузерах IE.

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


О'Рейли "Еще Быстрее Веб-Сайты" имеет целую главу об этом под названием "упрощение селекторов CSS". Он ссылается на вашу ссылку на Mozilla.

Я думаю, что два момента стоит иметь в виду.

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

  2. Как отметил другой комментатор, браузеру требуется миллисекунды, чтобы понять, как применять ваши стили при загрузке страницы. Однако, где это может иметь гораздо большее влияние, это с DHTML. Каждый раз, когда вы меняете DOM, браузер повторно применяет всю таблицу стилей к странице. В этом случае многие неэффективные селекторы могут оказать видимое влияние на вашу страницу (воспринимаемая запаздывание/ невосприимчивость.)


документация для скорости страницы Google (Firefox / Firebug add-on) включает в себя хорошая страница на эффективном CSS.