какой метод получения элемента через css селектор самый быстрый баллов 1

Оптимизация CSS: ID селекторы и другие мифы

В современном вебе, где сайты в среднем отправляют 500КБ сжатого JavaScript и 1,5 МБ изображений, работая при этом на Android-устройстве среднего уровня через 3G с лагом в 400мс, производительность CSS-селекторов является, наверное, наименьшей из существующих проблем.

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

Основы парсинга CSS

Во-первых, чтобы избежать непонимания в дальнейшем — эта статья не касается производительности CSS-свойств и их значений. Здесь мы рассматриваем эксплуатационные затраты самих селекторов. Я сосредоточусь на движке рендеринга Blink, а именно на браузере Chrome версии 62.

Селекторы можно разделить на несколько групп и (грубо) отсортировать их по возрастанию затрат на их обработку:

Тип селектораПример
1.Идентификатор (ID)#classID
2.Класс (Class).class
3.Тег (Tag)div
4.Обобщенный и cоседний родственный комбинатор (General and adjacent sibling)div

Означает ли это, что нужно использовать только ID и классы? Ну не совсем. Зависит от ситуации. Во-первых, давайте рассмотрим, как браузеры интерпретируют CSS-селекторы.

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

Измерение производительности

Бен Фрейн создал серию тестов для измерения производительности различных селекторов еще в 2014 году. Тестирование заключалось в измерении скорости, необходимой для анализа различных селекторов, начиная с простых идентификаторов (ID) и заканчивая некоторыми, действительно сложными и длинными, составными селекторами. Измерение производилось на огромном DOM, состоящем из 1000 идентичных элементов. В итоге он обнаружил, что разница между самым медленным и быстрым селектором составляла

Однако с тех пор многое изменилось, а заучивание старых правил в постоянно меняющемся мире браузеров почти бесполезно. Всегда помните, что нужно делать собственные тесты, особенно когда речь идет о производительности.

Я решил сделать свои собственные тесты и для этого я использовал тест Пола Льюиса, упомянутый в одном комментарии, выражающем озабоченность полезными, но чрезмерно замысловатыми «количественными CSS-селекторами»:

Тест был немного изменен — количество элементов увеличено до 50000, и вы можете проверить его сами. Я сделал в среднем 10 прогонов на моем MacBook Pro 2014, и я получил следующие результаты:

Даже при таких экстремальных условиях, когда на странице находится 50000 совпадающих элементов и используются действительно «безумные» селекторы, типа последнего в таблице выше, мы обнаруживаем, что самый медленный селектор обрабатывается примерно 20мс, самый быстрый — простой класс — примерно 3,5мс. Не такая уж и существенная разница. В реалистичном и менее экстремальном DOM, насчитывающем от 1000 до 5000 узлов, можно ожидать падения времени обработки примерно в 10 раз, доведя время парсинга до нескольких миллисекунд.

Из этого теста можно сделать вывод о том, что беспокоиться о производительности CSS селекторов не стоит. Просто не стоит переусердствовать с псевдоселекторами и действительно длинными составными селекторами. Мы также видим, как за последние два года улучшился движок Blink. Вместо указанного в цитируемом комментарии замедления в

Качество важнее количества

Хуже наличия «дорогих» селекторов является только большое их количество. Это явление известно как «раздутые стили» и, вероятно, вы встречали эту проблему в своей практике. Типичными примером являются сайты, которые целиком импортируют различные CSS-фреймворки (типа Bootstrap или Foundation), используя при этом менее 10% их кода. Другой пример — это старые, никогда не переживавшие рефакторинг, проекты, чей CSS-код перешел в состояние «хронологические таблицы стилей» — т.е. CSS с кучей классов, добавленных в конец файла по мере роста проекта, который со временем стал похож на заброшенный сад.

Кроме того, что передача большого файла стилей по сети занимает много времени (а сеть является самым узким местом в производительности веб-сайта), большие CSS-файлы также дольше парсятся. А ведь помимо построения DOM вашего HTML документа, браузеру необходимо построить CSSOM (объектную модель CSS), чтобы сравнить его с DOM и сопоставить селекторы.

Итак, держите свои стили «стройными», не добавляйте в них что попало, загружайте только то, что вам нужно, и только тогда, когда это вам нужно. Кроме того, по необходимости пользуйтесь различными инструментами для выявления неиспользуемого CSS-кода (типа UNCSS).

Для получения более детальной информации о том, как браузеры парсят CSS, посмотрите запись Николь Салливан о движке Webkit, статью Ильи Григорика о движке Blink или статью Лин Кларк о новом CSS-движке Mozilla (aka Stylo).

Очевидная проблема: инвалидация стилей

Мы рассмотрели хорошие примеры зависимости скорости обработки CSS-селекторов от их сложности, однако это всё касается единоразового рендеринга. Но сегодняшние веб-сайты уже не являются статическими документами, а больше напоминают приложения с динамическим контентом, с которым пользователи могут взаимодействовать. Это всё немного усложняет, поскольку синтаксический анализ CSS-кода — это всего лишь один шаг в конвейере рендеринга браузера. Вот более детальный (рендеринг-ориентированный) взгляд на то, как браузер отображает кадр на экране (из статьи «Производительность визуализации» на developers.google.com):

какой метод получения элемента через css селектор самый быстрый баллов 1. Смотреть фото какой метод получения элемента через css селектор самый быстрый баллов 1. Смотреть картинку какой метод получения элемента через css селектор самый быстрый баллов 1. Картинка про какой метод получения элемента через css селектор самый быстрый баллов 1. Фото какой метод получения элемента через css селектор самый быстрый баллов 1

Мы опустим вопрос производительности JavaScript и композитинг («Composite» на рисунке выше), а сосредоточимся на фиолетовой части — парсинге стилей («Style») и компоновке элементов («Layout»).

После построения DOM и CSSOM, браузеру необходимо объединить их в дерево рендеринга, прежде чем начать отрисовку на экране. На этом этапе браузеру необходимо вычислить окончательный набор CSS свойств и их значений для каждого найденного элемента. Вы сами можете это наблюдать в панели Elements > Styles инструментов разработчика браузера. Браузер берет все, соответствующие определенному элементу стили, включая специфические, свойственные самому браузеру (так называемые user agent stylesheet) для создания окончательного, вычисленного (computed) стиля элемента.

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

Наконец, на этапе отрисовки, браузер преобразует каждый узел дерева рендеринга в фактические пиксели на экране.

Теперь о том, что происходит, когда мы видоизменяем DOM, изменяя некоторые классы на странице, добавляя или удаляя некоторые узлы, изменяя некоторые атрибуты или каким-либо другим образом «балуясь» с HTML (или самими стилями)?

Другой способ — уменьшить область действия — например, количество отменяемых (требующих пересчёта стилей) элементов. Будьте конкретны в вашем CSS. Имейте это в виду, особенно при использовании анимации, где браузеру даётся всего

10мс *, чтобы выполнить всю необходимую работу.

Более детально изучить проблему инвалидации стилей можно прочитав статью Style Invalidation in Blink.

Заключение

Подводя итоги, можно сказать, что беспокоиться о производительности CSS-селекторов не стоит, если только вы действительно не переходите границы. Несмотря на то, что в 2012 году эта тема была актуальной, с тех пор браузеры стали намного быстрее и умнее. Даже Google больше не беспокоится об этом. Если вы посмотрите страницу PageSpeed Insights Rules, вы не увидите там правила «Use efficient CSS selectors» — «Используйте эффективные CSS-селекторы», которое было удалено оттуда в 2013 году.

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

И последнее замечание: всегда делайте свои собственные тесты. Не верьте тому, что было написано кем-то в Интернете несколько лет назад. Ситуация меняется кардинально и невероятно быстро. То, что актуально сегодня, может стать устаревшим раньше, чем вы это изучите.

* Имеется ввиду, что для гладкой анимации (с частотой 60 fps) на один кадр отводится 1000мс/60кадров ≈ 16,6мс. Отбросив время на саму отрисовку кадра, у браузера остаётся

10мс для проведения всех вычислений. — прим. перев.^

Источник

Взвешиваем селекторы CSS

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

Глава один – идём направо!

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

Итак, взвешиваем — сначала представим пару рядов из 8 чисел:

Знакомьтесь — так в числах выглядят некоторые два селектора, чтобы никто ни о чем не догадался назову их условно «верхний» и «нижний»

Самая страшная тайна

Если вы это прочитаете, от вас навсегда уйдет душевный покой, но по крайней мере вы сможете спать по ночам.

Раскрывая самую страшную тайну я расскажу, как собственно превратить обычный селектор в такие понятные и красивые цифры? Всё как всегда очень просто:

Я думаю суть вы уловили, теперь можно приступать к небольшой викторине, чтобы это проверить:

Викторина

Вопрос: Какого цвета бэкграунд будет в абзаце?
Ответ: Правильно, красного, потому что селектор не волнует что вам там кажется, и расстояние между тэгами его не интересует. А так как вес тэгов равен – применится последний.

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

Вопрос: Все тот же.
Ответ: А ответ, для разнообразия другой: наш див будет серым. Потому что как я уже упоминал выше селектору абсолютно безразлично что вы там имели ввиду. У первого селектора вес больше, и никого не волнует что скорее всего ожидали вы не такого поведения.

Продолжаем раскрывать секреты

Все мы любим викторины

Вопрос: Какого цвета будет знак вопроса в ссылке?
Ответ: Красного, неважно что селектор на точное совпадение атрибута выглядит более специфичным, чем селектор который выбирает все что «начинается с». Вес они имеют одинаковый.

Источник

CSS cелекторы и производительность

CSS cелекторы и производительность

Селекторы и производительность

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

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

Справа налево!

Для каждого текущего обрабатываемого элемента HTML-разметки браузер последовательно проверяет применимость всех относящихся к данному HTML-документу CSS-правил, разбирая селекторы в направлении справа налево. Рассмотрим для определенности пример:

Встречая CSS-правило, начинающееся таким селектором, браузер сперва проверяет, является ли текущий обрабатываемый элемент пунктом списка (li).

Если ответ — «нет», обработка данного CSS-правила завершается. Разумеется, оно не применяется к текущему элементу. Браузер переходит к обработке следующего CSS-правила (или же следующего элемента HTML-разметки, если для текущего элемента проверена применимость всех имеющихся правил, то есть данное правило было последним в очереди).

Если же ответ — «да», браузер следует вверх по DOM-дереву в поисках элемента ul с целью проверить, является ли наш пункт списка (li) потомком какого-либо неупорядоченного списка (ul).

Дальше события развиваются аналогичным образом. Если упомянутое условие вложенности элементов выполняется, браузер следует еще выше по дереву DOM, проверяя, является ли этот список (ul) потомком некоего элемента с классом content.

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

Кто самый быстрый?

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

В рамках «сферической в вакууме» модели с такими селекторами вполне сравнимы простые селекторы по типу элемента («по тегу»), например:

Теоретически в данном случае на производительность обработки CSS-правил (но не собственно селекторов) может повлиять тот факт, что HTML-документы обычно содержат большее количество элементов какого-то определенного типа (например, div), чем элементов с каким-либо одним заданным классом. Ну, а элемент с конкретным идентификатором по природе своей может быть вообще лишь единственным в пределах всей страницы — в противном случае код разметки будет невалидным. Можно сформулировать общее правило — при прочих равных условиях более предпочтительным с точки зрения производительности оказывается применение селекторов с большей специфичностью.

Поведение некоторых распространенных в реальном мире браузеров несколько отличается от «теоретически рассчитанного». При прочих равных простые селекторы по идентификаторам и по классам обрабатываются практически во всех браузерах одинаково быстро — разница в скорости не превышает статпогрешности. А вот простые селекторы по типу элементов обрабатываются порой заметно медленнее, даже в случае «лабораторных» тестовых примеров, когда все остальные условия специально сохраняются полностью идентичными.

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

Так или иначе, практика использования в CSS-коде только простых селекторов по классам и никаких более, сложившаяся в рамках парадигмы верстки независимыми блоками (включая, разумеется, разработку с применением методологии БЭМ), имеет под собой веские основания в том числе и с точки зрения производительности.

От быстрых к медленным. Простые селекторы

Итак, если бескомпромиссная производительность критически важна, можно порекомендовать ограничиться исключительно применением простых селекторов по идентификаторам и по классам, но ведь спецификации CSS дразнят веб-разработчиков несравненно более богатым выбором селекторов. Более того, этот «ассортимент» существенно дополнился разнообразными «вкусными» новшествами в спецификациях селекторов третьего и четвертого уровней. (Напомню, Selectors Level 3 — уже почти год как стабильная рекомендация W3C, полностью реализованная к настоящему моменту во всех приличных браузерах, а Selectors Level 4 — активно разрабатываемый черновик, некоторые части которого уже начинают получать экспериментальную поддержку.) Если звезды зажигают более ресурсоемкие селекторы все же существуют, значит, это кому-нибудь нужно.

Разумеется, их вполне можно использовать в реальной практике, только подходить к делу следует с умом. Понимание того, как браузер анализирует селекторы, поможет не допустить глупостей на ранних стадиях работы над проектом и избежать необходимости в будущем переделывать «тормознутый» сайт с нуля.

Обсудим некоторые другие, более «медленные», чем перечисленные выше, простые селекторы. Попытаемся ранжировать их в порядке снижения производительности, обусловленного возрастанием количества всевозможных проверок и/или их усложнением.

Универсальный селектор (селектор-«звездочка») обладает наименьшей возможной специфичностью (0). Поэтому обработка CSS-правила, начинающегося с такого селектора, отнимет объективно больше времени, чем обработка правила, предваряемого селектором по типу элемента (при прочих равных условиях, конечно). CSS-правило, начинающееся селектором-«звездочкой», будет применяться буквально к каждому элементу документа:

Еще больше ресурсов отнимет обработка CSS-правила с селектором по атрибуту:

В данном случае для каждого элемента HTML-документа будет проверяться наличие атрибута title — только при соблюдении данного условия правило окажется применимым к элементу.

Как вы понимаете, селекторы по значениям атрибутов еще менее эффективны. Из всех их разновидностей наиболее «медлителен» селектор, требующий проверки вхождения подстроки в значение атрибута (такой вид селекторов впервые появился, кстати, только в CSS3):

Также крайне «медленным» будет простой селектор, использующий динамический псевдокласс:

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

Уточнения на пользу и во вред

Простые селекторы, перечисленные в предыдущем разделе, на практике используются редко. (За исключением, возможно, «звездочки», которой зачастую начинают CSS-правило, обнуляющее значения свойств margin, padding и border, по умолчанию отличные от нуля для некоторых элементов. Речь идет о так называемом «ластике», вместо которого предпочтительнее использовать более деликатный reset.css, рекомендованный Эриком Мейером.

Код: Выделить всё Развернуть /* http://meyerweb.com/eric/tools/css/reset/
v2.0 | 20110126
License: none (public domain)
*/

html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed,
figure, figcaption, footer, header, hgroup,
menu, nav, output, ruby, section, summary,
time, mark, audio, video <
margin: 0;
padding: 0;
border: 0;
font-size: 100%;
font: inherit;
vertical-align: baseline;
>
/* HTML5 display-role reset for older browsers */
article, aside, details, figcaption, figure,
footer, header, hgroup, menu, nav, section <
display: block;
>
body <
line-height: 1;
>
ol, ul <
list-style: none;
>
blockquote, q <
quotes: none;
>
blockquote:before, blockquote:after,
q:before, q:after <
content: »;
content: none;
>
table <
border-collapse: collapse;
border-spacing: 0;
>

Как правило, эти синтаксические конструкции чаще применяются не сами по себе, а в составе последовательностей простых селекторов наподобие img[title] или a:hover. Подобные уточнения увеличивают специфичность соответствующих селекторов по сравнению с простыми селекторами [title] и :hover и сокращают время обработки относящихся к ним CSS-правил за счет существенного ограничения множества элементов, в отношении которых должны производиться сложные ресурсоемкие проверки.

Тем не менее, дополнительные уточнения не всегда полезны, а иногда и вовсе вредны. В частности, нет никакого смысла заменять простой селектор по идентификатору #intro на последовательность, скажем, header#intro. Элемент с соответствующим идентификатором в любом случае может быть лишь единственным во всем HTML-документе — иначе разметка окажется невалидной. Совершенно незачем требовать от браузера осуществления абсолютно лишней дополнительной проверки — принадлежит ли элемент с заданным идентификатором (intro) какому-то конкретному типу (header).

От быстрых к медленным. Комбинированные селекторы

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

Очевидно, из всех типов часто используемых на практике комбинированных селекторов, описанных в спецификациях CSS ранних уровней, наиболее «шустрым» будет такой:

В данном случае для каждого элемента p требуется произвести одну сравнительно несложную проверку — предшествует ли ему непосредственно элемент h1.

Вот такой комбинированный селектор отнимет, при прочих равных, чуть больше ресурсов:

Здесь потребуется в отношении каждого элемента li произвести проверку, является ли его родителем (то есть непосредственным предком, располагающимся внутри DOM строго на один уровень выше) некоторый элемент ul.

Селектор, использующийся в нижеследующем правиле, при прочих равных отнимет еще большее количество ресурсов:

Тут браузеру надлежит в отношении всякого элемента code выяснить, не является ли его предком (находящимся на каком угодно более высоком уровне иерархии внутри DOM) какой-либо элемент pre. В худшем случае для констатации неприменимости CSS-правила браузеру потребуется дойти при продвижении вверх по дереву DOM до уровня элемента body.

Чем меньше звеньев, тем надежнее цепь

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

Иногда в CSS-коде вполне реальных проектов можно встретить конструкции наподобие таких:

Код: Выделить всё Развернуть body ul.navigation li a

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

Упоминание body не нужно по той причине, что, как мы уже говорили, браузер сразу же, вне зависимости от наличия или отсутствия в коде разметки обрабатываемого HTML-документа соответствующих тегов, создает внутри DOM элементы html и body, и все элементы, использующиеся для структурирования контента, в любом случае считает вложенными внутрь body. Так что упоминание этого элемента в составе комбинированного селектора в лучшем случае никак не повлияет ни на что, включая производительность.

(С точки зрения буквы спецификаций HTML 4.01 и HTML5 пара тегов и

Источник

Урок 2. Селекторы и правила CSS

В прошлом уроке мы разбирали способы подключения CSS. Теперь перейдём к самому языку.

Как и любой другой язык, CSS имеет свой, однако предельно простой синтаксис. Состоит всего из двух компонентов:

Пример работы CSS

Код CSS (файл style.css)

Обратите внимание, не будет разницы, записывать блок стилей в строчку (h1,h2) или в столбик (body). И тот, и другой вариант будут работать. Выбирайте так, как Вам удобно.

Теперь создаём HTML-файл. Неважно, какое будет название, главное, чтобы путь к файлу с CSS кодом был указан верно. Указывается также как и в ссылках, путях к изображениям. В примере ниже указан путь (style.css) в ту же директорию, что и html-файл. То есть оба файла должны быть в одной папке.

Код HTML

Результат работы кода можно увидеть по ссылке ниже.

Если Вы измените какие-либо свойства в блоке стилей, то для обновления дизайна достаточно обновить страницу (Ctrl+F5).

Селекторы CSS

В примерах выше в качестве селекторов использовались элементы страницы: body, h1, h2. Однако бывают ситуации, когда нужно работать с конкретным элементом, а не со всеми. Например, все заголовки были синего цвета, а один, в конце, чёрного. Для это существуют разные виды селекторов. Давайте рассмотрим их подробнее.

Идентификаторы

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

Если хотите задать стили для нескольких элементов, то следует использовать классы.

Классы

Названия (имя) для id и class могут быть одинаковыми, однако для CSS это всё равно будут разные элементы. В CSS к идентификатору обращается упоминанием символа #, а к классу . (точкой).

В результате параграф с идентификатором (id) blue будет иметь текст синего цвета, элементы с class blue будут выделены полужирным шрифтом и синим цветом. А все остальные элементы p будут иметь шрифт чёрного цвета.

Как видите, класс можно применить несколько раз. Соответственно всё элементы будут иметь свойства описанные для данного класса.

Унифицированные селекторы

Контекстные селекторы

Соответственно синим будет выделен только тот полужирный текст (strong), который будет в параграфе (p).

Группировка селекторов

По тексту сложно понять. Лучше сразу к примеру.

В первой строке мы упоминаем сразу несколько элементов. Для того, чтобы обратиться сразу к нескольким элементам надо в селекторе перечислить их через знак , (запятую) и пробел. Перед последним перечисляемым элементом запятая и пробел НЕ нужны.

Последующими упоминаниями данных элементов мы добавляем им значения новых свойств. В данном случае размера шрифта.

В результате все заголовки будут синего цвета. Однако разных размеров, так как последующие записи в таблице стилей давали заголовкам разный размер.

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *