> - Вторым нужно переопределить только некоторые стили

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

замена миксинов на ::part и ::theme не решает коренную дилемму - как приоткрыть часть внутренностей, не лишая Shadow DOM самой сути его существования

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

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

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

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

кажется я начал повторяться) надеюсь донес свою мысль

Да, мысль ясна

проблемы тупикового пути миксинов я хорошо помню, много работал с Polymer 1
кроме того, помню и как выглядели стили с кучей вложенных ::shadow и /deep/ в Polymer 0.5 - много такого рефакторил в свое время

сегодня просто попытался подумать над тем, как сделать это красиво, вводя минимум новых сущностей

согласен, что часть этих проблем решается на уровне “форкнуть” - но эта опция доступна не всегда

Форкнуть не предлагаю в первую очередь, это всегда крайняя мера.

Мой опыт это подтверждает. Довелось делать темизацию для биллинговой системы (провайдеры ее у нас покупали и кастомизировали). В итоге из коробки была доступна темизация через css variables. Если же покупатель хотел больше, то форкали основную тему и делали под него, это удовольствие стоило не дешево и требовало дополнительные вложения при обновлении основной темы. Но многих это устраивало и они были готовы за это платить. Про БЭМ API, звучит интересно, но у нас руководство и css variables то не сразу восприняло.

Мне кажется в CSS есть более конкретные проблемы связанные с кастомизацией. Одну - описал выше про состояния, Вторая - отсутствие нормального наследования/переопределения (суть та же кастомизация). Я бы сфокусировался на этих для начала.

Про переопределение - что конкретно имеется в виду?

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

По сути кастомизация часто строится на том, что мы перебиваем старые стили. Одно и то же по сути состояние может описываться не только разными стилями, но и селекторами, что еще усложняет всё.

A recap of my FE / DOM related libraries
https://gist.github.com/WebReflection/761052d6dae7c8207d2fcba7cdede295

вот тут Андреа (WebReflection) подробно отвечает на вопрос, зачем у него столько библиотек и чем они отличаются

весенний F2F в Париже вроде отменяется из-за коронавируса

Максимум созвонятся онлайн, что с учётом часовых поясов вряд ли всем подойдет

https://github.com/w3c/webcomponents/issues/855#issuecomment-593566405

Кто-нибудь знает онлайн-IDE, которые поддерживают lit-плагины для VSCode? Вроде CodeSandbox объявлял поддержку плагинов для VSCode, но я не вижу, где и как их устанавливать в интерфейсе.