CSS parent selector
Тема родительского селектора в ЦСС всплывает ужа давно, если не ошибаюсь, в Вебките даже как-то был эксперементальный синтаксис для его поддержки.
Что такое родительский селектор? О, это очень простая и мощная штука, к примеру, если клиент выбрал что-то в каком-то окне, нужно всё окно спрятать. При помощи ЦСС это можно было бы сделать так:
.window < :checked { /* экспериментальный синтаксис родительского селектора из Вебкита */
display: none;
}
Сразу скажу, задумка мощная, а реализация плохая. Какую проблему тут видно сразу? Непонятно что значает этот знак. Непосредственного родителя мы здесь выбираем или любого? Если непосредственного, как выбрать любого и наоборот?
Все синтаксисы родительского селектора (включая, например, :parent) грешат чем-то подобным — они не гибкие или неоднозначные.
Мне бы хотелось видеть абсолютную гибкость в отношении родительского селектора и мне кажется, синтаксис тут напрашивается сам собой:
.window > (:checked ~ :checked) {
display: none;
}
Всё сразу становится логично, на мой взгляд: применить стиль к тегу с классом window, у которого два непосредственных потомка-соседа находятся в состоянии «checked».
ну почему же негибко?
:parent:parent:parent:parent:parent:parent:parent:parent:parent:parent
Отлично же ^____^
Комментарий для hshhhhh.name:
А если я не знаю где расположен родитель, но знаю его селектор? :)
Комментарий для Евгения Степанищева:
Это ваше кривое проектирование мне претит! Знаешь селектор -- значит знаешь и айдишник. Пост ни о чём.
Я шучу, конечно же :).
мб if?
Комментарий для BOLVERIN:
Это как? :)
Я даже больше скажу, может быть синтакисис вида
(.window > (:checked+:checked) + .border)
или
> (:checked) + .window > (:checked)
> if(.input:checked)
{
display: none;
}
тоже самое что предложили вы, по сути, но с привычным if который делает запись в разы понятнее
Комментарий для BOLVERIN:
CSS самобытный язык, ничего привычного в таком способе нет, это полностью вываливается из того синтаксиса, который там есть. Более того, полное ощущение, что if — тег.
прост конструкции без if могут превратиться ( и скорее всего превратятся в «умелых» руках ) в нечто ужасное и нечитабельное
мне не хотелось бы чтобы очень быстро настал момент когда с CSS невозможно будет работать без препроцессора как на вход так и на выход
про тег не подумал. верно
похоже путь к «мои глаза кровоточат от этих условий» неизбежен :(
Я люблю XPath, почему бы из него не взять предикаты?
.window[:checked ~ :checked] {
display: none;
}
Тем более, что это похоже на атрибутные селекторы, то есть переучиваться никому не надо :)
Помнится, предлагался синтаксис, где знаком $ отмечается тот элемент, к которому применяется правило. Вроде такого:
$.window > :checked ~ :checked
Это следует читать как «.window, внутри которого есть два отчекнутых элемента»
про бакс как указатель интересно. а почему не приняли такой синтаксис?
Комментарий для subzey:
А как такое сделать: .window > (:checked) + .window > (:checked)
«Элемент, прямой потомок которой чекнут, а у соседа тоже есть прямой чекнутый потомок»?
Я смотрю сейчас в CSS4 появился «subject selector»: http://www.w3.org/TR/selectors4/#subject Это всё равно не так гибко как со скобками.
Имхо, ты смотришь по старинке не в ту сторону развития CSS. Сейчас веб-компоненты куда более богатая и перспективная со всех точек зрения спецификация, нежели раз в год нужный parent selector. Я уж молчу о том насколько он будет медленным...
Комментарий для o-mokhov.ya.ru:
Я смотрю просто во все стороны :) Родительский селектор позволит делать просто офигительные вещи, сейчас его очень нехватает для всяких интересных трюков.
А кого это пугает? Я могу придумать жутко медленные сочетания их существующих селекторов (даже первого уровня), ничего, всё работает же. Скорость селекторов не всегда заметна, не все же делают богатые на вёрстку веб-приложения.
В CSS-парсере Slick предлагался синтаксис с восклицательным знаком перед комбинатором
html article ! html
html > body !> html
li ~ li !~ li
Мне
Комментарий для Ярослав Федин:
Это менее гибко, чем я предлагаю.
Безусловно, но тем не менее, согалситесь, инвертированые комбинаторы проще в имплементации. Кроме того определенную гибкость можно все-таки достичь:
Пример .window > (:checked ~ :checked) неплохо переносится на :checked ~ :checked ! .window
> (article + form > (:checked ~ :checked))
->
:checked ~ :checked !> form !+ article !> window
Есть какие-то примеры, которые я упускаю? Спасибо за ответ на комментарий к несвежей статье.
Прошу прощения за опечатки в примерах предыдущего комментария. В Slick были еще два комбинатора, которые стали доступны благодаря возможностью инвертирования: ++ и ~~ (немедленные соседи и соседи вообще — важные комбинаторы, которые сейчас отсутствуют в цсс как факт)
Комментарий для Ярослав Федин:
Чтобы спорить проще или нет, нужно детально рассматривать, а мне не хочется этим заниматься :)
Мне кажется единственный вывод, который тут можно сделать не вдаваясь во вкусовые баталии, это то что если заимплементят хотя бы один из механизмов, то можно пре-процессить свой синтаксис по вкусу и трансформировать в нечто общепринятое. Хорошего дня!