CSS parent selector

Тема родительского селектора в ЦСС всплывает ужа давно, если не ошибаюсь, в Вебките даже как-то был эксперементальный синтаксис для его поддержки.

Что такое родительский селектор? О, это очень простая и мощная штука, к примеру, если клиент выбрал что-то в каком-то окне, нужно всё окно спрятать. При помощи ЦСС это можно было бы сделать так:

.window < :checked { /* экспериментальный синтаксис родительского селектора из Вебкита */
    display: none;
}

Сразу скажу, задумка мощная, а реализация плохая. Какую проблему тут видно сразу? Непонятно что значает этот знак. Непосредственного родителя мы здесь выбираем или любого? Если непосредственного, как выбрать любого и наоборот?

Все синтаксисы родительского селектора (включая, например, :parent) грешат чем-то подобным — они не гибкие или неоднозначные.

Мне бы хотелось видеть абсолютную гибкость в отношении родительского селектора и мне кажется, синтаксис тут напрашивается сам собой:

.window > (:checked ~ :checked) {
    display: none;
}

Всё сразу становится логично, на мой взгляд: применить стиль к тегу с классом window, у которого два непосредственных потомка-соседа находятся в состоянии «checked».

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

hshhhhh (hshhhhh.name) № 1
ну почему же негибко?
:parent:parent:parent:parent:parent:parent:parent:parent:parent:parent

Отлично же ^____^
Евгений Степанищев (bolknote.ru) автор № 2
А если я не знаю где расположен родитель, но знаю его селектор? :)
hshhhhh (hshhhhh.name) № 3
А если я не знаю где расположен родитель, но знаю его селектор? :)

Это ваше кривое проектирование мне претит! Знаешь селектор -- значит знаешь и айдишник. Пост ни о чём.

Я шучу, конечно же :).

Евгений Степанищев (bolknote.ru) автор № 6
Я даже больше скажу, может быть синтакисис вида

.xwindow (.window > (:checked+:checked) + .border)
или
.window > (:checked) + .window > (:checked)
BOLVERIN № 7
.window > if(.input:checked)
{
display: none;
}
тоже самое что предложили вы, по сути, но с привычным if который делает запись в разы понятнее
Евгений Степанищев (bolknote.ru) автор № 8
Комментарий для BOLVERIN:

CSS самобытный язык, ничего привычного в таком способе нет, это полностью вываливается из того синтаксиса, который там есть. Более того, полное ощущение, что if — тег.
BOLVERIN № 9
прост конструкции без if могут превратиться ( и скорее всего превратятся в «умелых» руках ) в нечто ужасное и нечитабельное
мне не хотелось бы чтобы очень быстро настал момент когда с CSS невозможно будет работать без препроцессора как на вход так и на выход
makishvili.com № 11
Я люблю XPath, почему бы из него не взять предикаты?
.window[:checked ~ :checked] {
display: none;
}

Тем более, что это похоже на атрибутные селекторы, то есть переучиваться никому не надо :)
subzey № 12
Помнится, предлагался синтаксис, где знаком $ отмечается тот элемент, к которому применяется правило. Вроде такого:
$.window > :checked ~ :checked
Это следует читать как «.window, внутри которого есть два отчекнутых элемента»
Евгений Степанищев (bolknote.ru) автор № 14
А как такое сделать: .window > (:checked) + .window > (:checked)

«Элемент, прямой потомок которой чекнут, а у соседа тоже есть прямой чекнутый потомок»?
Мохов Олег (o-mokhov.ya.ru) № 16
Имхо, ты смотришь по старинке не в ту сторону развития CSS. Сейчас веб-компоненты куда более богатая и перспективная со всех точек зрения спецификация, нежели раз в год нужный parent selector. Я уж молчу о том насколько он будет медленным…
Евгений Степанищев (bolknote.ru) автор № 17

Я смотрю просто во все стороны :) Родительский селектор позволит делать просто офигительные вещи, сейчас его очень нехватает для всяких интересных трюков.

Я уж молчу о том насколько он будет медленным…

А кого это пугает? Я могу придумать жутко медленные сочетания их существующих селекторов (даже первого уровня), ничего, всё работает же. Скорость селекторов не всегда заметна, не все же делают богатые на вёрстку веб-приложения.

Ярослав Федин № 18
В CSS-парсере Slick предлагался синтаксис с восклицательным знаком перед комбинатором

html article ! html
html > body !> html
li ~ li !~ li

Мне
Ярослав Федин № 20
Безусловно, но тем не менее, согалситесь, инвертированые комбинаторы проще в имплементации. Кроме того определенную гибкость можно все-таки достичь:

Пример .window > (:checked ~ :checked) неплохо переносится на :checked ~ :checked ! .window

.window > (article + form > (:checked ~ :checked))
->
:checked ~ :checked !> form !+ article !> window

Есть какие-то примеры, которые я упускаю? Спасибо за ответ на комментарий к несвежей статье.
Ярослав Федин № 21
Прошу прощения за опечатки в примерах предыдущего комментария. В Slick были еще два комбинатора, которые стали доступны благодаря возможностью инвертирования: ++ и ~~ (немедленные соседи и соседи вообще — важные комбинаторы, которые сейчас отсутствуют в цсс как факт)
Евгений Степанищев (bolknote.ru) автор № 22
Комментарий для Ярослав Федин:

Чтобы спорить проще или нет, нужно детально рассматривать, а мне не хочется этим заниматься :)
Ярослав Федин № 23
Мне кажется единственный вывод, который тут можно сделать не вдаваясь во вкусовые баталии, это то что если заимплементят хотя бы один из механизмов, то можно пре-процессить свой синтаксис по вкусу и трансформировать в нечто общепринятое. Хорошего дня!