Как стать автором
Обновить

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

Замечательно. Хотелось бы больше услышать про отличие ":" от "::".
С одинарного двоеточия ":" начинаются псевдо-классы, например, a:hover. То есть, это неявный класс элемента a. Двойное двоеточие "::" — это псевдо-элементы, например, a::before. То есть, это неявный элемент, которого нет в разметке, но мы его как-бы создаем через css (точнее, браузер понимает, это мы выделяем что-нибудь в элемент).

Подробнее про разные псевдо-элементы и псевдо-классы лучше читать в справочниках. Для начального ознакомления подойдет htmlbook.ru.
А если Вы спрашиваете про отличия, например, :after от ::after, то тут все просто. В спецификации CSS2.1 использовалось одинарное двоеточие для псевдо-элементов, а в CSS3 стали применять двойное, чтобы отделить псевдо-элементы от псевдо-классов.
: — для псевдоклассов
:: — для псевдоэлементов

Но, для first-line, first-letter, before и after допустимы обе нотации. Обратная совместимось форева.
Интересно, а если использовать: и :: для одного класса, то боаузер перезапишет правила или создаст новый объект?

PS: под рукой нет возможности протестировать.
p + p img {
     margin-left: -1em;
}

А теперь дискотека:
<p>…</p>
<p>
<img src='…' alt='…'><img src='…' alt='…'><img src='…' alt='…'>
</p>


Нельзя же так в лоб действовать.
Для наглядного примера самое то: )
p + p img:first-child {
margin-left: -1em;
}

?
Ну почти.
<p>…</p>
<p>
<span><img src='…' alt='…'></span>
<span><img src='…' alt='…'></span>
<span><img src='…' alt='…'></span>
</p>
ну если задача специфическая, то
p + p > img:first-child

хотя в таком случае лучше ходить по классам
В примере с социальными иконками можно ::before заменить на метод с background-image и эта конструкция будет работать во всех браузерах, даже в ие7
Там вся соль в селекторах атрибутов, а не в before. В зависимости от ссылки добавляем иконку ту или иную иконку.
ну да
если заменить before на бекграунд, эта соль никуда не денется, и каждая ссылка будет со своей иконкой. зато будет работать почти во всех браузерах
а… ну я понял. Думал, что селекторы атрибутов вообще в малом количестве браузеров поддерживаются, а оказалось, что даже ie7 поддерживает, просто праздник
кстати, протестировать браузер на поддержку селекторов можно на сайте Криса Койера
линк
НЛО прилетело и опубликовало эту надпись здесь
На деле даже в последних «Хромах» (нестабильные не смотрел, правда) работают не все сочетания селекторов CSS3.
Ну и неплохо бы закончить заметку (ибо на полноценную статью это не тянет) этой ссылкой, так как всегда есть нюансы, будь они неладны.
Первый раз слышу чтобы у кого-то возникли проблемы при познаии CSS. Может дело в том, что его пытаются учить как «язык программирования», в то время как это обычные конфигурационные файлы с элементарным и довольно гибким синтаксисом?
Это на первый взгляд все элементарно. При верстке сложных макетов часто всплывают довольно неочевидные нюансы, которые в книгах и спецификациях не упоминаются и побороть которые удается благодаря опыту/гуглению.
Плюс, даже самую простую html разметку можно стилями задизайнить десятком способов, и здесь мастерство в том, чтобы сделать это самым оптимальным и кроссбраузерным способом.
Да, CSS — одна из самых простых штук, что есть в вебе, но элементарной я бы ее не называл
Это какие нюансы не упоминают с стандартах?
ок, упоминаются, но по-разному интерпретируются браузерами :)
Например каким? За всю жизнь никаких проблем не видел.
А какой у вас опыт, если не секрет?
Самый простой пример — бордеры у таблиц
вот здесь неплохо с примерами показано
Мда. Я думал, что этим комментарием отвечаю совсем на другой комментарий. Можно считать, что его не было.
Мда. Я думал, что этим комментарием отвечаю совсем на другой комментарий. Можно считать, что его не было…
#page > * { width: 100%; }
Это из серии «Научи меня плохому»? Ну давайте вообще везде будем универсальный селектор ставить, а то сайты что-то слишком быстро открываться стали, да и процессорные мощности не используются на полную.
А с чего бы это должно тормозить? Т.к. здесь используется #, то разбор начнется слева направо и данный селектор будет работать быстро. Не вижу смысла пренебрегать универсальным селектором в ситуациях, в которых он удобен.
Кто же это Вам сказал, что разбор начнётся слева направо? Но даже если бы это было так, всё равно это очень медленный селектор, потому что будут обрабатываться _все_ элементы внутри #page.

The style system matches rules by starting with the key selector, then moving to the left (looking for any ancestors in the rule’s selector). As long as the selector’s subtree continues to check out, the style system continues moving to the left until it either matches the rule, or abandons because of a mismatch.
developer.mozilla.org/en/Writing_Efficient_CSS

Знакомая статья. В интернете по сути все только на нее и ссылаются. Во всяком случае иного я не нашел. Но основываясь на собственном опыте + том факте (если память не изменяет), что Джон Рейсиг в своем Сизле (имена и названия могу чуть исказить :) ) (движок селекторов в jQuery) при использовании id меняет порядок разбора начиная с нахождения этого самого id + до недавнего времени он работал в Mozilla.., могу предположить, что я был прав :). И этому могу предложить доказательства. Ах да, ремарка, "_все_ элементы внутри #page" — сие неверно, ибо используется дочерний селектор (">").

Так вот, я собрал небольшой тест: jsfiddle.net/E49EL/1/

Проверил только на Aurora 7.0a2 (2011-07-14) (версия Firefox для разработчиков).

Результат: «Serator прав на все 181мс». (погрешность в ~ 10 мс)

Интересно было бы посмотреть на результаты в иных браузерах + возможно вы что-то сможете предложить в ответ. На самом деле мне сей вопрос тоже очень интересен, ибо плохо документирован и, возможно, при различной структуре DOM-дерева результаты будут отличаться.
Всё может быть, разработчики браузеров что только не делают, чтобы поднять производительность.

Я в js понимаю примерно столько же, сколько в балете, но при заходе на тест в FireFox 5 получаю алерт «lampslave прав на все 52мс» :) Там точно скорость CSS, а не JS измеряется? Ещё интересным будет вариант с заведомо неправильным кодом, когда #id будет несколько одинаковых.

#id > * так или иначе проиграет другим селекторам, что по смыслу, что по неожиданным багам, что про удобству изменения. Независимые классы мне представляются намного более эффективными. Но вообще меня сейчас больше волнует скорость обработки [attr=«value»] против tag[attr=«value»].
Я использовал нативный поиск по селектору в js. По идее это тоже самое, что и в css, так что по времени оно по сути одно и тоже. + у меня достаточно медленный компьютер по современным меркам и, быть может, вам имеет смысл увеличить количество циклов выполнения скрипта, чтобы погрешность не была слишком малой (аль запустить скрипт несколько раз и посмотреть на тенденцию). В реальности же какой бы вариант не выиграл, по сути разница уже настолько мизерна, что в большинстве случаев этим можно пренебречь.

Рассматривать баги браузеров, аль ошибки разметки я тоже не вижу смысла, ибо с универсальным селектором я багов уже не помню (может быть во времена ie6 они и были :) ), ну а кривая верста — увы :).

Если бы кто-то провел полномасштабное исследование данного вопроса, то это было бы здорово, ибо исследования 2000-го года с несколькими правками на MDC (MDN) уже давно устарело, а на нем основаны все статьи-клоны в сети (иного я не нашел).

В одном я уверен точно, что если универсальный селектор ("*") в какой-то ситуации предпочтительнее, то имеет смысл использовать его (при этом понимая то, каким образом браузер парсит селекторы, ну или хотя бы думая, что понимаешь :) ).
Может и так, но не факт. Секунды в целом сохраняются. Pentium® Dual-Core CPU 2210 @ 2.20GHz

Не знаю, как там в жизни, а по тесту содружество #id > * показывает себя с очень хорошей стороны. Я удивлён. Не люблю повторять чужие глупости :(

Да, было бы здорово, только вот кто это будет делать…

В любой ситуации надо использовать предпочтительный вариант :) Просто предпочтения у всех разные.
И ещё вариант. У Вас 3 дочерних элемента. Посмотрите, что будет, если их станет 10 или 20.
Продублировал контейнер article c содержимым, теперь их 20. + увеличил количество циклов выполнения скрипта в 10 раз. Комп призадумался и выдал: «Serator прав на все 6597мс» в том же браузере, что и в прошлый раз.

jsfiddle.net/xKX32/2/ — пробуйте.
Да, в этом виде отрыв увеличивается.

Только вот Вы, кажется упустили одну деталь. Вы используете #id > * против #id tag. Если заменить этот «мой» селектор потомков на селектор дочерних элементов #id > tag, я остаюсь в выигрыше более чем на 2 секунды.
Я основывал свои опыты на примере из статьи, а там использовались именно такие селекторы. Но! Я изменил последний скрипт, уменьшил количество циклов в 10 раз (мой компьютер уж очень долго думал над прошлым скриптом :) ) и сменил селектор "#container header,#container article,#container footer" на "#container>header,#container>article,#container>footer".

Мой результат на все том же браузере: «Serator прав на все 751мс».

Новый скрипт: jsfiddle.net/ZwtyJ/
«lampslave прав на все 399мс»
Видимо, у FF7 будет очень большой отрыв по производительности. И это здорово.
Самая большая проблема CSS и кодеров — IE6.
Сколько лет верстаю, и уже отказался от поддержки IE6 очень давно, но все равно никак не могу перейти на использование всех CSS-селекторов в полной мере. Как запилилось в голову, что IE6 поддерживает их самый минимум и что нужно использовать этот минимум — так где-то и сидит…
Хотя и IE7 не блещет, а его пока приходится поддерживать, что тоже беда…
Даже как-то «кто-то их поддерживает не в полной мере, потому только. # :hover и т. п.»
Да все просто.
"*",".", "#", «elem» — используем только это, если у нас ИЕ6+.

Если у нас ИЕ7+ и выше, то можно также:
elem[attr=value] и все похожее, " > ", E+E, E ~ E :first-child. Вот, курите эти селекторы, это ща наиболее актуально. Как тока мы отказались от поддержки ИЕ6, я наоборот оч рад был, что наконец могу юзать эти селекторы.

Если у нас ИЕ8+, то добавляются:
:before, :after, :last-child, возможно что-то еще.
>> Возможно, вы более точны в своей работе, и чтобы избежать нежелательных изменений в элементах верхнего уровня, используете:
Принципы Блок, Элемент, Модификатор (БЭМ)
Может, года через 3 это и станет актуально.
Пока же даже с двумя классами у одного элемента (типа «first selected») — уже беда-печалька.
не советовал бы менять иконки в зависимости от урла, мне кажется это плохая идея, хоть и оригинальная. напишешь vk.com вместо vkontakte.ru или еще по какой причине урл изменится и иконка отвалится. юзайте старый добрый класс (или ид).
А вы не забыли ":not", который в CSS3?
Очень удобно между прочим:
a:not([href^="/"], [href*="gordio.pp.ua/"]) {
  padding-right: 18px;
  background: url("../img/external.png") right top no-repeat;
}
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории