Lea: why would style be written ... also the fact that we're recreating filenames that don't exist

... feels like this solving problems ... inventing API surface to solve a problem that could be solved by saying "they should not trigger additional network requests"

Tess: It is a big pile of stuff... but the number of cases they are trying to cover is big enough that it might be justified... similar reaction... some of the naming hoops I need to jump through... attribute names ... get unwieldy really quickly... Given the constraints I think they ended up somewhere reasonable. I wonder how it works for closed shadow roots? The whole big debate of "what the default mode" - wasn't resolved... but de dactor there has been an assumption of "open"...

Lea: 2 problems this is trying to solve - sharing styles between components or between host page and components... if you use existing mechanisms, it triggers additional network requests...

Tess: i think the problem is encapsulation...

Lea: they are saying it's a problem... javascript actually defines when you import a ESM across multiple modules it's not requested multiple times. why not just define that that is how CSS works? 2nd thing tis is trying to do: importing parts of a style sheet... why not having a mechanism that allows for this using existing mechanisms? Feels non-ideal and introduces new API surface? ... fixing the problem outside of web components... there have been a lot of opponents to web components based on complexity...

Jeffrey: they're argument about the @sheet alternative considered is "not implemented" which isn't great...

Peter: i'm also curious about "may cause network requests" - i've implemented code to not load style sheets multiple times... what are the conditions that WOULD coause a network request?

Lea: seems like this could be specified...

Tess: it's a question of data .. does the web ...

Peter: behaviour that is 20+ years old to not do extra requests... maybe if there is a clearly defined condition...?

Tess: asking for data to back up their assertions...

Jeffrey: maybe @sheet and then a link rel pointing at that named sheet .. would be a better way to do this if it's web compatible...

Peter: yeah

Lea: yeah

Fodder:

We're concerned about the developer complexity ... Do you have data to back up the assertions you're making? Compat analysis

we will draft a comment and discuss further before leaving it

discussion of whether this is a chrome bug or a general issue

Lea drafted a comment here: https://github.com/w3ctag/design-reviews-private-brainstorming/issues/65#issuecomment-2427387664

A long discussion about the nature of stylesheets and whether adoption results in (logically) a clean copy of the sheet or a reference to a sheet. This matters because encapsulation is enhanced by making a copy. Having a reference means spooky action at a distance.

<blockquote>

A concern about whatever mechanism is used here is that there is an existing behavior of copy-on-write behavior when the same stylesheet is loaded from multiple places. e.g. if I <link> a.css twice, there's one instanace in RAM, but if it's modified via CSSOM, it splits into two instances so page authors can't tell it was shared in the first place.

However, with stylesheets that are adopted via JS API, the same instance is re-used and changes to that instance are reflected in each place they are referenced.

At the least we need to be clear what the expected behavior will be when declaratively adopting a stylesheet. It's also worth thinking about either reconciling the behavior or giving authors explicit mechanisms to opt-in to the behavior they desire.

</blockquote> <blockquote> We're happy to see this feature progress. There are a few things that we've identified in the comments above that need to be considered by the working group as you continue to develop the feature. Closing the early review as "satisfied with concerns" to reflect that. </blockquote>