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

👍

Не достаточно оставить стили, надо ещё нужные ноды пометить хешем

А селектор эти ноды не находит

а применит уже браузер )

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

и волки целы, и овцы сыты

А если для одного элемента он есть, а для другого не нашелся ? Селектор в css будет с хэшем, в шаблоне один вариант без хэша, другой с хэшем ?  или речь всегда только об одном элементе ?

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

И не важно в каком месте ты его вызывал, хоть в html интерполяции

Oh wait, это же попахивает css modules

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

если же тебе прям оооочень хочется так накосячить, то вот тебе воркараунд: https://svelte.dev/repl/4e1904a23e4640dc8d85ab7e3a1afaa7?version=3.30.0

вообще, у меня такие решения для листов обычно не возникают по причине того, что я четко отделяю "визуализацию айтема листа" от "лейаута айтема листа", а это больше похоже на селектор для какого-то вида лейаутинга. иными словами, присловутый класс .list-group-item должен быть не внутри компонента айтема, а внутри компонента который перебирает айтемы и реализует сам лист. проще говоря это подход:

<ul>
{#each }
   <Item /> <!-- <li> внутри Item -->
{/each}
</ul>

VS

<ul>
{#each }
   <li>
      <Item /> 
  </li>
{/each}
</ul>

я за второй варик

Item вообще по-идее должно быть пофиг на то, в листе он показывается, совместно с другими такими же, или в одиночку

Этой "логикой" должен управлять исключительно компонент реализующий лист. и селекторы вида .item + .item - это явно логика листа

снова всё оборачивать, пиццот лишних дивов ради инкапсуляции 😩

здрасти, так это дефрагментация называется. ребята с C тоже наверное сперва страдали когда им предложили C++ с классами, наследованиями, и другой требухой для “инкапсуляции”, вместо того, чтобы просто накатать функций

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

во-первых, я пока не испытывал подобных проблем со свелт. во-вторых, это концепция родом из html, так что жаловаться бесполезно) опять же речь не идет о милионах нод. Речь скорее о том, как декомпозировать свои компоненты. Имхо, пример с ul-li который выше очень показательный. Кол-во нод одинаковое, а смысл кардинально меняется. Очень много видел таких вот кейсов, где простое изменение подхода меняет многие вещи

и вот уже просто вынеся li из Item ты можешь юзать его не только внутри ul