я бы сказал, есть три проблемы.

1. проблема позиционирования - в ошибочной попытке полимера стать фреймворком.

2. проблема реализации - в том, что многие важные вещи не продумали, зато придумали разную дичь. вроде shadow root у элемента body или возможности нескольких shadow root (было в v0 и полимере 0.5 - это реально смотрелось дико)

3. проблема взаимодействия с комьюнити - Гугл никого не хочет слушать.
Иегуда Кац об этом упоминал, к этому - как мне кажется - также аппелируют Андреа (WebReflection) и Рич Харрис

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

а насчет того, что люди не готовы платить такую цену, это наверно лучшая формулировка, что я когда-либо слышал, хорошо сказал в общем 👍

в svelte все с этим прекрасно. дополнительный статический css класс = 0 оверхеда в рантайме. + сорсмапы

итог сборки это просто класс вида: .my-class.svelte-fjsdkklsfj

совершенно статичный

О, ура

Я кстати давно хочу спросить. Почему Shadow DOM ассоциируют исключительно с изоляцией стилей? На мой взгляд как раз таки изоляцию стилей из этой идеи можно было бы нафиг выкинуть и заменить чем-то более лайтовым. Более того, мне кажется, что такое грубое огораживание стилей вообще не имеет смысла и крайне вредно. Механизм абстракции над вёрсткой выглядит в разы более интересным, даже если это просто дефолтный слот.

Эм, а что подразумевается под абстракцией над версткой? Как это поможет дизайн-системам?

Ответ на этот вопрос достоин целой статьи с большим кол-вом примеров. Абстракция в виду Shadow DOM (я сейчас не про реальный, а про абстрактый), могла бы упростить композицию элементов и дать возможность в большом кол-ве кейсов обходиться без помощи композитных возможностей современных фреймворков. Это хоть и не очевидно, но сильно упрощает логику приложений, позволяет эффективнее переиспользовать код. Также это дало бы зелёный свет новому поколению полифилов/абстракций для вёрстки, которые были бы более эффективными. Разумеется это всё при условии, что решение будет согласовываться с SSR и a11y.

И вот мне кажется что всем было бы сильно проще, если бы про жесткую инкапсуляцию стилей тут забыли бы.

Да, мне, видимо, надо пример, чтобы это представить)

Ну вот допустим ты хочешь сделать простой listitem. И иконкой ты хочешь видеть SVG-иконку обычную, чтобы цвет наследовать и т.п. Ты делаешь абстракцию (абстрактный Shadow DOM), пишешь <my-menuitem>Item text</my-menuitem> и получаешь что надо. Но в DOM при этом ничего не видно лишнего, нужно отдельным API запросить внутренний DOM элемента, чтобы увидеть SVG-иконку и прочее.

И никаких изоляций стилей, потому что не надо. Я хочу наследовать цвет, все кастомные переменные, базовый размер rem, базовый шрифт и т.п.

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

И им тоже надо как-то стилизоваться. Они может тоже часть дизайн-системы.

Ааа, блин, кажется, начинаю понимать))

Т.е. отдельная абстракция хранит чисто стили?

Не, со стилями тут вообще ничего не надо, они работают насквозь как и раньше. Возможно там надо будет чуточку изменить наследование, чтобы стили внутреннего DOM не текли во внешний (при условии, что это ничего сильно не усложнит), но барикадировать протечку стилей внутрь точно не надо.

Как же тогда сделать так, чтобы разработчик при интеграции дизайн-системы ее не сломал, не пойму?)