@Pozadi27 ноя 2013 в 23:59

Простое правило выбора CSS селекторов

2 мин

22K

CSS * HTML *

Туториал

Комментарии 24

@cjmaxik 28 ноя 2013 в 00:16

Могли бы и уложиться в комментарий.

@glebmachine 28 ноя 2013 в 01:06

Я просто оставлю это сдесь.

nav.menu li a { color : red }

article.job h1 { color : grey }
article.job.hot  h1 { color : red; font-weight : bold }

footer nav.menu li:nth-child(2n-1) a:hover::before { width : 20px; height : 20px; background : red; border-radius : 10px; margin-left : -20px }

Ваш цсс, как и html должен быть выразителен и читаться без комментариев, выбор названий классов или айдишников должен основываться на семантической роли элемента или блока-контейнера.

<header>
  <nav class="menu">
    <li><a class="active" href="/jobs">Jobs</a></li>
    <li><a href="/companies">Companies</a></li>
    <li><a href="/about">Contacts</a></li>
  </nav>
</header>
<div class="layout">
  <section id="jobslist">
    <article class="job">
      <h1>Web Engineer </h1> 
      <p>Few words about..</p>    
      <a href="#">read more </a>    
    </article>  
    <article class="job hot">
      <h1>Senior Web Engineer </h1> 
      <p>Few words about.. 
      </p>    
      <a href="#">read more </a>    
    </article>  
    <article class="job">
      <h1>Web Engineer </h1> 
      <p>Few words about.. 
      </p>    
      <a href="#">read more </a>    
    </article>  
  </section>
  <aside id="advertising">
    <article class="banner">
      <iframe>...</iframe>    
    </article>  
    <article class="banner video">
      <iframe>...</iframe>    
    </article>  
  </aside>
</div>
<footer>
  <nav class="menu">
    <li><a class="active" href="/jobs">Jobs</a></li>
    <li><a href="/companies">Companies</a></li>
    <li><a href="/about">Contacts</a></li>
  </nav>
  <script src="..."></script>
  <script src="..."></script>
  <script src="..."></script>
</footer>

@Pozadi 28 ноя 2013 в 01:12

что-то не пойму что вы хотели сказать

@Zelgadis 28 ноя 2013 в 02:33

То, что CSS селекторы должны повторять html. Типичная ошибка которую делают люди которые начинают использовать SASS. А потом сплошные проблемы с этим.

nav.menu тоже не правильно.

@PavlovM 28 ноя 2013 в 04:26

То есть вы хотите сказать, что:
nav.menu li a
article.job h1
article.job.hot h1

— это правильные, хорошие селекторы..?

@Zelgadis 28 ноя 2013 в 04:59

Я говорю, что это не правильно и такую ошибку допускают все кто на sass начинает писать.

@PavlovM 28 ноя 2013 в 05:03

А, ясно, хорошо, меня просто фраза «То, что CSS селекторы должны повторять html» сбила с толку.
«Повторять html» селекторам как раз не надо.

@Zelgadis 28 ноя 2013 в 07:28

Так я пояснял пост выше. Это не значит, что я с ним согласен.

@glebmachine 28 ноя 2013 в 08:55

Нет, не это)

Я говорил, что:
hr {} — плохо
.whitesquare > h1 {} хорошо

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

НЛО прилетело и опубликовало эту надпись здесь

@pewpew 28 ноя 2013 в 04:29

А всего то делов, автору той статьи было использовать что-то типа:

.head-hr { ... }

<hr class="head-hr">

@PavlovM 28 ноя 2013 в 05:01

Или просто


.whitesquare {border-top: 5px solid #ccc;}

без лишней разметки.

@lleo_aha 29 ноя 2013 в 05:26

а почему все радеющие за селекторы по типу

    .someclass a{
         font-size: 12px;
    }

скромно умалчивают о том, что браузер при обработке правила сначала вытащит со страницы вообще все ссылки, а потом оставит те из них, которые внутри .someclass?

или в спорах о повторении html в css или семантичности css селекторов производительность полученного решения не важна вовсе?

@Pozadi 29 ноя 2013 в 10:30

Меня тоже давно интересует этот вопрос. Думаю тут два варианта:
1) я неправильно понимаю ситуацию и на самом деле браузер делает не совсем так
2) эта проблема очень слабо влияет на итоговую производительность

@lleo_aha 2 дек 2013 в 06:52

влияет и весьма сильно — на mozilla developer network есть очень неплохая статья на тему оптимизации css селекторов

@Pozadi 2 дек 2013 в 09:58

Статья хорошая, но там нет никаких цифр — просто GOOD, BAD. Нужно нормальное тестирование, из которого было бы понятно насколько быстрее тот или иной селектор и главное сколько это в абсолютных значениях.

Пока складывается впечатление что проблемы могут возникнуть только на очень больших страницах с десятками тысяч элементов подходящих под селектор. Например возникли у гитхаба, на странице с диффом speakerdeck.com/jonrohan/githubs-css-performance

НЛО прилетело и опубликовало эту надпись здесь

@lleo_aha 2 дек 2013 в 06:55

если таким образом все ссылки у вас помечены классом 'a', то особой разницы между .something .a и .something a не будет.

посмотрите мой комментарий чуть выше — на mdn достаточно подробно описано всё

@Quilin 2 дек 2013 в 07:37

За исключением того факта, что вновь пришедшему верстальщику придется узнавать магические сведения о том, что все ссылки должны иметь класс «a», а все картинки — «img».

@lleo_aha 2 дек 2013 в 08:22

почему вы отвечаете, не разобравшись в сути вопроса?

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

@Quilin 2 дек 2013 в 12:27

Льщу себе надеждой, что разбираюсь в сути вопроса:
1. Во-первых, крайне мала вероятность ситуации, когда выбор «a» работает с той же скоростью, что и ".a". Я не уверен в том, как работает парсер Gecko для таких случаев, но в Chrome этот парсер работает «лениво» (он не заполняет список классов ноды до тех пор, пока не придет туда при формировании Layout'а) и поскольку крайне редко все элементы на вашей странице обладают одним и только одним классом, получение списка всех нод с TAGNAME A работает несколько быстрее получения всех нод с классом A.
Конечно, сложность не так чтобы вырастает — на не более чем линию.
2. Во-вторых, цитирую вас

особой разницы между .something .a и .something a не будет

Вопрос zorro1211 состоял в ЧЯДНТ. Уверяю вас, разница в процессе разработки существенная — в первом случае чтобы добавить в проект ссылку, нужно просто написать ссылку. Во втором случае придется еще вешать на нее класс «A». Что попахивает магией и вряд ли где-то задокументировано. И даже если задокументировано, все равно плохо.
3. А вообще говоря, быстрее использовать не .something .a и не .something a, а .something-link. Если в этой ноде нет ID, прочих классов, у нее тот же :hover, :active и :link -state, что и у селектора, то она будет гораздо быстрее занимать свое место в Layout.

@lleo_aha 2 дек 2013 в 13:05

Ок, в такой формулировке полностью согласен с вами, особенно про п.3

НЛО прилетело и опубликовало эту надпись здесь

@Quilin 3 дек 2013 в 09:24

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

Я боюсь, вы недооцениваете оптимизацию этих алгоритмов. Не имею сейчас возможности посмотреть код, но почти уверен, что второй раз он не пойдет по дереву. Что касается индексации классов, Webkit (полагаю, Gecko работает схожим образом) занимается этим только на этапе интеграции DOM дерева и распарсенного CSS, в чем, собственно, и заключается построение Layout'а. Это логично, поскольку далеко не все классы, использованные в HTML коде обязательно будут описаны в CSS. Такая небольшая оптимизация, впрочем, вероятно, там есть и более глубокие идеи, которые мне из подвала не видно.
Сами понимаете, индекс по конечному и заранее известному списку допустимых имен тегов нод, отработает несколько быстрее чем индекс по списку всех классов. Но, ЕМНИП, там для таких индексов используется биндерево, а значит разница в производительности станет заметна только на ОЧЕНЬ большом количестве классов на странице.

Итого:
1. Самый быстрый вариант:

.sidebar-link

Это не магия, поскольку будет все понятно. В вашем первом посте мне показалось, что вы вообще на все ссылки в проекте планировали вешать класс «а», что, разумеется, совершенно бессмысленно. Класс, использованный в контексте одного блока будет легко воспроизводим и никак не повлияет на другие части кода.
2. Второй по производительности:

.sidebar a

Проблемы начнут возникать только если в сайдбаре появится еще какая-нибудь ссылка, которая должна выглядеть как все остальные. Придется огребать.
3. Самый долгий:

.sidebar .a

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

div#MyBlock .sideBar + .nextNode#Hello div a > img.classImg

PS: В общем, MDN слушай, а сам не плошай. Есть в статье совет, не использовать селекторы вида

div#id

, дескать, работает неоптимально. Но — вот ужас — в Webkit идентификатор ноды работает с CSS иначе. Если на вашей странице два блока с одним ID и правило CSS с селектором этого ID, они оба отрисуются с использованием этого правила. И работающий с неким индексом селектор # тоже в некоторых случаях отработает дольше чем div#id. У меня, например, в проекте нод с ID на странице встречается просто безумное количество. Они, правда, никогда не участвуют в CSS, но, боюсь, если бы участвовали, селектор div#id был бы не такой уж и медленный ;)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий