Comments 24
Могли бы и уложиться в комментарий.
Я просто оставлю это сдесь.
Ваш цсс, как и html должен быть выразителен и читаться без комментариев, выбор названий классов или айдишников должен основываться на семантической роли элемента или блока-контейнера.
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>
что-то не пойму что вы хотели сказать
То, что CSS селекторы должны повторять html. Типичная ошибка которую делают люди которые начинают использовать SASS. А потом сплошные проблемы с этим.
nav.menu тоже не правильно.
nav.menu тоже не правильно.
То есть вы хотите сказать, что:
nav.menu li a
article.job h1
article.job.hot h1
— это правильные, хорошие селекторы..?
nav.menu li a
article.job h1
article.job.hot h1
— это правильные, хорошие селекторы..?
Нет, не это)
Я говорил, что:
hr {} — плохо
.whitesquare > h1 {} хорошо
инкапсулируйте обьявления, и контролируйте свой оргазм.
Для улучшения читаемости своих обьявлений другими членами команды не стоит брезговать длиной селектора.
Перечислять весь путь — плохо.
Я говорил, что:
hr {} — плохо
.whitesquare > h1 {} хорошо
инкапсулируйте обьявления, и контролируйте свой оргазм.
Для улучшения читаемости своих обьявлений другими членами команды не стоит брезговать длиной селектора.
Перечислять весь путь — плохо.
А всего то делов, автору той статьи было использовать что-то типа:
.head-hr { ... }<hr class="head-hr">
а почему все радеющие за селекторы по типу
скромно умалчивают о том, что браузер при обработке правила сначала вытащит со страницы вообще все ссылки, а потом оставит те из них, которые внутри .someclass?
или в спорах о повторении html в css или семантичности css селекторов производительность полученного решения не важна вовсе?
.someclass a{
font-size: 12px;
}
скромно умалчивают о том, что браузер при обработке правила сначала вытащит со страницы вообще все ссылки, а потом оставит те из них, которые внутри .someclass?
или в спорах о повторении html в css или семантичности css селекторов производительность полученного решения не важна вовсе?
Меня тоже давно интересует этот вопрос. Думаю тут два варианта:
1) я неправильно понимаю ситуацию и на самом деле браузер делает не совсем так
2) эта проблема очень слабо влияет на итоговую производительность
1) я неправильно понимаю ситуацию и на самом деле браузер делает не совсем так
2) эта проблема очень слабо влияет на итоговую производительность
влияет и весьма сильно — на mozilla developer network есть очень неплохая статья на тему оптимизации css селекторов
Статья хорошая, но там нет никаких цифр — просто GOOD, BAD. Нужно нормальное тестирование, из которого было бы понятно насколько быстрее тот или иной селектор и главное сколько это в абсолютных значениях.
Пока складывается впечатление что проблемы могут возникнуть только на очень больших страницах с десятками тысяч элементов подходящих под селектор. Например возникли у гитхаба, на странице с диффом speakerdeck.com/jonrohan/githubs-css-performance
Пока складывается впечатление что проблемы могут возникнуть только на очень больших страницах с десятками тысяч элементов подходящих под селектор. Например возникли у гитхаба, на странице с диффом speakerdeck.com/jonrohan/githubs-css-performance
UFO just landed and posted this here
если таким образом все ссылки у вас помечены классом 'a', то особой разницы между .something .a и .something a не будет.
посмотрите мой комментарий чуть выше — на mdn достаточно подробно описано всё
посмотрите мой комментарий чуть выше — на mdn достаточно подробно описано всё
За исключением того факта, что вновь пришедшему верстальщику придется узнавать магические сведения о том, что все ссылки должны иметь класс «a», а все картинки — «img».
почему вы отвечаете, не разобравшись в сути вопроса?
человек спросил — улучшит ли производительность его способ написания (указываем класс вместо тега) — я ответил что это то же самое что и «класс тег» при условии, что такие классы используются, например, для всех ссылок
человек спросил — улучшит ли производительность его способ написания (указываем класс вместо тега) — я ответил что это то же самое что и «класс тег» при условии, что такие классы используются, например, для всех ссылок
Льщу себе надеждой, что разбираюсь в сути вопроса:
1. Во-первых, крайне мала вероятность ситуации, когда выбор «a» работает с той же скоростью, что и ".a". Я не уверен в том, как работает парсер Gecko для таких случаев, но в Chrome этот парсер работает «лениво» (он не заполняет список классов ноды до тех пор, пока не придет туда при формировании Layout'а) и поскольку крайне редко все элементы на вашей странице обладают одним и только одним классом, получение списка всех нод с TAGNAME A работает несколько быстрее получения всех нод с классом A.
Конечно, сложность не так чтобы вырастает — на не более чем линию.
2. Во-вторых, цитирую вас
Вопрос zorro1211 состоял в ЧЯДНТ. Уверяю вас, разница в процессе разработки существенная — в первом случае чтобы добавить в проект ссылку, нужно просто написать ссылку. Во втором случае придется еще вешать на нее класс «A». Что попахивает магией и вряд ли где-то задокументировано. И даже если задокументировано, все равно плохо.
3. А вообще говоря, быстрее использовать не .something .a и не .something a, а .something-link. Если в этой ноде нет ID, прочих классов, у нее тот же :hover, :active и :link -state, что и у селектора, то она будет гораздо быстрее занимать свое место в Layout.
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.
Ок, в такой формулировке полностью согласен с вами, особенно про п.3
UFO just landed and posted this here
При таком коде проблема в том что браузеру нужно пару раз пройтись по всем ссылкам, коих может быть много, верно?
Я боюсь, вы недооцениваете оптимизацию этих алгоритмов. Не имею сейчас возможности посмотреть код, но почти уверен, что второй раз он не пойдет по дереву. Что касается индексации классов, Webkit (полагаю, Gecko работает схожим образом) занимается этим только на этапе интеграции DOM дерева и распарсенного CSS, в чем, собственно, и заключается построение Layout'а. Это логично, поскольку далеко не все классы, использованные в HTML коде обязательно будут описаны в CSS. Такая небольшая оптимизация, впрочем, вероятно, там есть и более глубокие идеи, которые мне из подвала не видно.
Сами понимаете, индекс по конечному и заранее известному списку допустимых имен тегов нод, отработает несколько быстрее чем индекс по списку всех классов. Но, ЕМНИП, там для таких индексов используется биндерево, а значит разница в производительности станет заметна только на ОЧЕНЬ большом количестве классов на странице.
Итого:
1. Самый быстрый вариант:
.sidebar-link2. Второй по производительности:
.sidebar a3. Самый долгий:
.sidebar .aНо разница в производительности не просто ничтожна — вы ее вряд ли выявите на тестах меньше нескольких десятков тысяч нод. Так что не парьтесь и лучше пишите понятный и читаемый код, не парясь за оптимизацию селекторов. По крайней мере, до тех пор, пока ваши селекторы не станут выглядеть как-нибудь так:
div#MyBlock .sideBar + .nextNode#Hello div a > img.classImgPS: В общем, MDN слушай, а сам не плошай. Есть в статье совет, не использовать селекторы вида
div#idSign up to leave a comment.
Простое правило выбора CSS селекторов