2009-08-14 2 views
11

При создании стилей CSS один подход, как представляется, полностью квалифицирован стиль, такие какЭффективны ли полноценные стили CSS?

#pnlImage div.ipd-imageInfo div.ipd-tags span.ipd-tag 

по сравнению с более коротким определением, такие как

div.ipd-tags span.ipd-tag 

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

Есть ли успех в производительности от полностью отборочного стиля, т. Е. Дольше? Есть ли какие-то рекомендации/рекомендации по передовой практике для наименования стилей?

Благодаря

+0

Что такое ipd-метки? –

+0

Я думаю, что-то конкретное приложение – nickf

+0

Если сайт меняется, метод * first * также рискует не идентифицировать правильные элементы. – nickf

ответ

5
  1. Глядя в #id быстро.
  2. Глядя на tag, это немного медленнее.
  3. Глядя на .class является самым медленным.

Запуск селекторов с более быстрым поиском уменьшит количество запросов, необходимых для следующей части. То есть, если я написал p.myClass, тогда браузер может очень быстро найти все теги p, а затем ему нужно только прокрутить те, чтобы проверить имя класса.

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

+0

Моя реализация не работает. Алгоритм, который я реализовал, «для каждого элемента в DOM, см., Какие правила выбраны (т. Е. Получить из набора правил правила, селекторы которых соответствуют элементу), а затем применить каскадный алгоритм». Поэтому любой простой селектор (тег, класс, идентификатор) занимает примерно такое же небольшое количество времени (чтобы проверить, соответствует ли он соответствующему элементу DOM). Смежные селекторы занимают больше времени (требуется время, линейно пропорциональное числу предков, которые имеют элемент DOM). – ChrisW

+2

* ваш * алгоритм? вы пишете свой собственный механизм CSS? – nickf

+0

Да, я. Но это алгоритм, который мне показался по спецификациям: API между моим рендерером HTML и моим парсером CSS похож на http://www.w3.org/TR/DOM-Level-2-Style/css.html# CSS-ViewCSS, который я вызываю для каждого элемента в DOM (как оптимизация производительности, для достаточно-подобных элементов DOM парсер CSS возвращает результаты из кеша). Вы действительно говорите, что алгоритм, используемый другими реализациями браузера, «для каждого правила CSS, найдите элементы DOM» вместо «для каждого элемента DOM, найдите правила CSS»? И если вы так думаете, почему бы так сделать? – ChrisW

0

Я не понимаю, как теоретический ответ возможен: ответ зависит от реализации; поэтому я предлагаю вам профиль, чтобы быть уверенным.

0

Есть ли удар производительности от полностью отборочного стиля, т. Е. Дольше?

Да, при каждом динамическом изменении DOM-дерева выражение CSS должно быть переназначено по меньшей мере на некоторые узлы. Я сомневаюсь, что это приведет к какой-либо заметной задержке.

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

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

7

Google (not a search, actually them) seems to think that it does cause a performance hit.

Кроме того, фонд Mozilla есть статья «Writing Efficient CSS for use in the Mozilla UI», который обрисовывает в общих чертах возможные подводные камни производительности CSS селекторы в браузере (ов), а также как оптимизировать правила стиля для их рендеринга. В их статье много примеров того, что хорошо, а что плохо. Помните, что это относится только к их браузерам.

Есть также некоторые тесты общедоступными, о CSS селекторов влияет на скорость рендеринга:

Я, однако, считаю, что это, по большей части, лошадиный навоз. Вы можете изменить FAR на скорость загрузки/рендеринга вашей страницы, используя некоторые другие простые оптимизации. Я считаю, что ваше здравомыслие и хорошо организованная база кода должны быть первыми. Если бы это было так же важно, как некоторые из них, все мы вернемся с помощью 4 атрибутов (bgcolor =, border = и т. Д.) Для стилизации наших веб-страниц.

1

Возможно, вас заинтересует Дэвид Барон (Mozilla) Google Tech talk.

+0

+1 очень релевантный. Описание выбора селектора CSS начинается примерно в момент времени 0:15:40. – ChrisW

0

Хотя ваш вопрос касается производительности (и я бы предложил, измерил ее). Я бы очень хотел добавить, что вы всегда должны стараться использовать кратчайшее определение, чтобы идентифицировать правильные элементы.

Причина не в размере файла, а в возможности расширения сайта без изменения основного css.

Например, вы получили эту часть в вашем HTML-сайте:

<div id="Header"> 
    <h1>Css example</h1> 
    <h2>Welcome to the css example site</h2> 
    <p>An example page by davy</p> 
</div> 

и это CSS:

#Header 
{ 
    background-color: #ffeedd; 
    padding: 1em; 
} 
#Heading h1 
{ 
    font-size: 3em; 
    color: #333; 
} 
#Heading h2 
{ 
    font-size: 1.5em; 
    color: #666; 
} 
#Heading p 
{ 
    margin: 0 0.5em 1.5em 1em; 
    font-size: 1.1em; 
    color: #999; 
} 

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

Если вы решили использовать div#Header в главном файле css, вам нужно либо изменить html (который в зависимости от вашей системы может означать создание другого шаблона/главной страницы), чтобы добавить дополнительный класс, либо создать более квалифицированный селектор css, такой как body div#Header.

Используя самый короткий селектор, вы все равно можете использовать div#Header { background : ... }, чтобы изменить заголовок. Вы можете создать дополнительный файл css и загрузить его в свой заголовок на этой странице (если разрешено) или добавить определение стиля непосредственно в раздел <head>. Самое приятное в этом - ваш css-файл не растет с селекторами для каждой другой страницы, и вы можете избегать classitis.

Вы также можете использовать его, чтобы переключить метод калибровки вашей страницы (статический/жидкий), чтобы один шаблон/главная страница использовала по умолчанию css, а другая - из этого шаблона/главной страницы и просто связывает css под названием FluidWitdth90. css, чтобы изменить шаблон на 90% ширину раскладки жидкости.

+0

Чтобы убедиться, что я правильно вас понял, предпочтительный пример? Вместо того, чтобы использовать более длинный полностью квалифицированный стиль, сделать их короче и более конкретными только для этого элемента, чтобы их можно было заменить? – ChrisP

+0

Мое правило - всегда использовать наименее специфический селектор. Таким образом, у вас будет примерно 3/4 раза, чтобы переопределить стиль с другими файлами css, будучи более конкретными. –

1

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

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

Таким образом, с точки зрения технического обслуживания это неэффективно. Также неэффективна с точки зрения ввода.

Смежные вопросы