CSS-live.ru

Новые спецификации CSS-селекторов

Привычные нам CSS-селекторы 3 уровня стали рекомендацией W3C еще в 2011-м (почти одновременно с CSS2.1), а черновик селекторов 4 уровня был опубликован еще в 2013-м и очень долго не менялся. Но на этой неделе рабочая группа CSS спохватилась и показала, что работа над селекторами не заброшена. С перерывом в два дня обе спецификации обновились: 30 января — старая, а 1 февраля — новая.

В старой спецификации фактически исправлена лишь одна ошибка (применимость селекторов вида :nth-* к корневому элементу). Но поскольку из-за этой ошибки пришлось менять набор тестов к спецификации и заново проверять, как его проходят браузеры, формально ее «понизили в статусе» до кандидата в рекомендации. Впрочем, это уже неважно — основная работа идет над селекторами 4 уровня.

Новый же черновик переработан почти до неузнаваемости — все статьи про новые селекторы, ссылающиеся на версию 2013 года, можно выбрасывать. Изменилась терминология, сам язык спецификации стал точнее и строже. Даже те, кто вместе с нами следили за новинками редакторского черновика и его первыми реализациями в браузерах, найдут в новой редакции немало сюрпризов.

Активизацию работы над селекторами во многом подтолкнуло недавнее решение разработчиков Chrome реализовать (вслед за Safari) некоторые из новых селекторов — как минимум, :matches(). Как часто бывает, в последний момент у многих стали появляться идеи дальнейший улучшений, и прямо сейчас на Гитхабе обсуждается (порой с жаром) немало ишью про селекторы. В частности, пока так и не придумали названия новому аналогу :matches() с нулевой специфичностью. Так что если не хотите, чтобы в браузерах навеки закрепилось неудачное, на ваш взгляд, решение — присоединяйтесь и выдвигайте свои аргументы, именно сейчас они могут оказаться определяющими. А мы постараемся и дальше держать вас в курсе текущих новоCSSтей и знакомить с самыми интересными новинками, так что следите за нашими обновлениями!

P.S. Это тоже может быть интересно:

14 комментариев

  1. Учитывая, что всякие CSSNext и т.п. раскрывают `:matches()` в отдельный селекторы, а не `:-*-any()`, то, непонятно, зачем вообще нужен `:something()`?.. Тем более, что есть еще `:is()` (аль как там его сейчас называют?), который, в теории, может сбрасывать эту саму специфичность у чего угодно. Safari, с одной стороны, подтолкнул всех к принятию решения, выкатив поддержку `:matches`, но, с другой стороны, прошло уже несколько лет и теперь это только проблем создает из-за уже имеющейся реализации.

    1. :something() и :is() — это одно и то же. Название :is() не прижилось, а подходящей для всех замены пока не придумали. Вот для текущего черновика и поставили название-заглушку, по которому сразу понятно, что оно временное и его надо заменить на что-то нормальное:)

      1. Да, `is` / `as` / `when` (который почему-то у всех ассоциируется со временем %), видимо. из-за селекторов времени к субтитрам) и прочие. На самом деле из всего обсуждения мне больше всего понравилось именно ваше предложение: https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-354832935. Возможно, его стоит проработать с точки зрения синтаксиса (`:matches(as as 0,0,0)` (тег `as` вполне себе может существовать)), но плюс в том, что можно ввести поддержку `:matches()` уже сейчас, позже добавив вторую часть из предложения Таба. Осталось только решить, будет ли добавлять сам `matches()` себя к специфичности селектора, аль растворится по аналогии с тем, как это происходит когда его «растворяет» препроцессор.

        В обсуждении на Github’е многие оперируют тем, что очень сложно в наши дни что-то переименовать, так как есть реализация в Safari, поддержка инструментами разработки, различные пособия, книги и прочее, где описан именно `:matches()`. Но это никогда не было стандартом, крайне мало используется и, в любом случае, можно объявить устаревшим, добавив новое имя, более простое (короткое) и с большими возможностями, чтобы не иметь `:matches()`, который по-разному работает в разных браузерах. Как правильно заметили, градиенты умудрились переименовать имея поддержку во всех браузерах, хоть это и было кощунством по мнению Таба, но это прошло вполне себе безболезненно. Непонятно, что мешает сделать тоже самое и с `:matches()`, у которого поддержка 0.0000n?..

    1. Упс! Спасибо, действительно упустил!

      (Но нам всё равно, думаю, лучше следить за редакторским черновиком, https://drafts.csswg.org/selectors-4/ — именно туда вносятся актуальные исправления, и именно на него ориентируются разработчики браузеров. Публикация в TR скорее ценна как индикатор того, что консорциум снова всерьез взялся за селекторы, не «забил» на них:)

    1. Ого! Оперативно, ай да Виктория Су! Но теперь поменять определение в спеке будет еще труднее:)

        1. Справедливости ради, с блинковской страницы для :is ссылка на редакторский черновик ведет на раздел, который сейчас озаглавлен этим временным :something. Думаю, они оставили :is просто как исторически первое название для этой штуки, и скорее всего поменяют у себя, когда новое название (хоть какое-нибудь) утвердят.

  2. То есть, разработчикам ближе обнулять специфичность, чем задавать её явно, вроде div:matches(#foo, as 0, 1, 0, .bar as 1, 0, 0) {…} ?

    1. Разработчикам браузеров, видимо, это действительно проще. Явно указывать очень соблазнительно, но пока не очень понятно как…

  3. Есть ещё пару моментов, которые хотелось бы прояснить:

    возможность применять больше/меньше и больше равно/ меньше равно в медиавыражениях планируют применять?
    Будут ли использовать переменные не только в блоке деклораций, но и для селекторов? (в частности, в тех же медиавыражениях)

  4. Ну и такая, в принципе, простая вещь, как использование двойных скобок (по-сути — одинарных, поскольку скобки, для записи условий, это — синтаксис, правило оформления, и они не несут в себе основную функцию скобок — группировку).

    Что-нибудь вроде такого:

    (min-width: 800px) and (min-width: 50em) and ((max-width: 1000px), (max-width: 62.5em))

    Без скобок это почти что бессмыслица, как минимум max-width из второго условия, нивелирует min-width из первого.

    А со скобками получается следующее: при изменении браузерного шрифта в любую сторону, из двух минимумов или двух максимумов, будет выбрано наибольшее (если в em шире чем в пикселях, то будут использоваться em, если в пикселях шире — то пиксели).

    Немного меняем, получаем наименьшее:

    ((min-width: 800px), (min-width: 50em)) and (max-width: 1000px) and (max-width: 62.5em)

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

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

    Ну это, понятно, пример, можно не согласиться, что это целесообразно, но смысл именно тот, что в выражении медиазапросов, появляется гибкость…

Оставить комментарий

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

Получать новые комментарии по электронной почте. Вы можете подписаться без комментирования.