Встречаются конечно и более дикии вещи, но редко. Например состояние toggle у кнопки:

”0 :active:focusable[.75em] :pressed:focusable[.75em] :pressed[.75em] :pressed:active[.75em]”

Это кастомный синтаксис описания состояний, на его основе генерится куча селекторов непересекающихся.

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

я вижу что ты еще передаешь .75em, но это просто переменная, которую ты потом в стилях отрендеришь
не понимаю как это относится к общему решению проблемы

то есть иными словами, ты заранее определяешь конечно число CSS-свойств, которые можно передать и которые будут правильным образом применены

так это также будет работать и с CSS property

написал с парой реальных примеров кода из наших компонентов

https://github.com/w3c/webcomponents/issues/864#issuecomment-591484810

Ну я могу переопределить другой набор состояний. Обычный CSS это не решит.

Я передаю короткую запись, которая говорит, какие значения в каких состояниях имеет элемент. И могу переопределить эту запись на любом уровне даже в рантайме. И это всё работает, даже внутри Shadow DOM, почти исключая необходимость в написании CSS.

мой пойнт, который я в issue пытаюсь продвигать - нам нужно CSS решение, которое будет работать с ::part(), :dir(), :state() и так далее

Спасибо, я начинаю понимать, что и зачем, но нужно переварить день-другой.

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

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

когда мы делали lion и думали о стилизации, мы не раз делали брейнштормы по поводу того, как наши компоненты будут расширяться и как стили будут переопределяться, мы же сами для них тоже делали второй слой с конкретными стилями компании
мы решили пойти путем БЭМ как это не странно, а еще называли это БЭМ API для расширений стилей
идея в том, что мы гарантируем, что определенные БЭМ компоненты будут присутствовать в Shadow DOM базового класса компонента и разработчики расширений для них (иными словами, разработчики тем) могут быть уверены, кто эти БЭМ компоненты не изменяют сяв рамках гарантий semver
единственно что, мы подумывали отдельное версионирование вести для расширений, но эта идея далеко не пошла

все это не решает проблему, которую вы пытаетесь решить, тем более не в общем виде
но решает очень практичную проблему - как позволить создавать темы и расширять существующие темы (или white-label тему, которая тоже тема, просто исключительно со "структурными" стилями)

далее
много слов было сказано именно о расширении
тут мне не нравится то, что зачастую разработчики white-label компонентов хотят предоставить максимальную гибкости при переопределении темы
но ведь ты Сереж сам заметил там в комментах, что это всегда компромисс между гибкостью и строгостью, тут мы ничего нового не изобретем, все это довольно очевидно
мне видится так, что надо думать не о максимально гибкости, а о том, что есть 2 группы потенциальных юзеров
1. те, кто просто хочет немного приблизить тему к своему брендбуку, поменять пару цветов и шрифты
2. те, кому нравится функциональность компонентов (JS логика, A11Y, еще что-то?), но кого стили вообще не устраивают, и кто готов написать свои

для группы 1 есть CSS Properties
для группы 2 мы придумали как раз БЭМ API для расширения стилей

у нас была внутренняя документация по поводу этого "БЭМ API для расширения стилей", надеюсь ребята его когда-нибудь опубликуют, но там никакого rocket-science, можно и так догадаться, о чем идет речь

Я могу изложить наши внутренние исходные данные, чтобы было понятнее - для issue они не особенно релевантны

Суть в том, что у нас UI в Java. Разработчики вообще не трогают HTML, не пишут классы. То есть, это можно делать, но задача стоит - добиться того, чтобы пришлось трогать HTML и DOM вообще по-минимуму.

Код на Java выглядит так:

Button button = new Button();
button.addThemeVariants(ButtonVariant.LUMO_SMALL);

Что именно будет делать метод addThemeVariants - для разработчика не важно.

Далее, у нас есть возможность подключения CSS, сейчас выглядит так:

@CssImport(value = “./my-button.css”, themeFor = “vaadin-button“)

Соответственно, разработчик накидает компонентов, дизайнер поправит стили, и готово.
Вот почему нас интересует возможность API на чистом CSS

Что касается “групп потенциальных юзеров” - я их разделяю на авторов адд-онов (сторонних компонентов) и авторов приложений
- Первым нужно переиспользовать стили с минимумом копипаста
- Вторым нужно переопределить только некоторые стили

Мой пример синтаксиса покрывает скорее вторую группу. Первую мы считаем “продвинутыми” пользователями, для них теоретически можно предоставить исходники стилей, например, в виде библиотеки Sass миксинов

Button button = new Button();
button.addThemeVariants(ButtonVariant.LUMO_SMALL);

@CssImport(value = “./my-button.css”, themeFor = “vaadin-button“)

Я правильно понимаю, что в таком подходе будет на чистом CSS тоже будет использоваться некий динамический import?

как именно подключать CSS - отдельная тема, не слишком в этом контексте принципиальная

то есть, мы не против идеи стандартизировать CSS module scripts / adoptedStyleSheets, но проживем и без них

но да, динамический импорт - это вариант