Re: [w3ctag/design-reviews] Question: should `shadowrootadoptedstylesheets` perform a fetch? (Issue #1195)

KurtCattiSchmidt left a comment (w3ctag/design-reviews#1195)

Thanks for the input @LeaVerou! A few responses/questions/clarifications:

> If a style module with that specifier (or even a specifier mapping) is not present at the time, what happens? Is the module map ever revisited or does the stylesheet just fail to get adopted?

Currently, it fails to get adopted. There is no step to revisit previously parsed items in HTML, and I would prefer not to add one for this feature. I agree that this adds resistance to using this with external files, but that's sort of the point. It doesn't explicitly block external files, but there is extra work required to use them. 

There are several other less problematic mechanisms for importing stylesheets in external files, and none currently to import declarative modules, so this does fill a capability gap as-is. I am not opposed to add a less-than-ideal mechanism for importing external CSS files for consistency, but I think it needs to have a good reason. This is where the TAG can really help.

> Also, reading the explainer it appears that the attribute accepts both URLs and specifiers, not just specifiers, and this behavior is even weirder with URLs.

It only accepts specifiers, which get mapped to URL's after import map processing (see https://html.spec.whatwg.org/#resolve-a-module-specifier). There isn't anything new with this proposal with regards to URL processing - it behaves exactly as an `import` would. Can you clarify what's weird here?

> Also, going into the weeds here briefly, but the error event could well fire on the element itself, or even on the template before it's removed, so that capturing still catches it.

The issue is that the template element *never* exists in the DOM with declarative shadow DOM, so there's no element itself, or time frame before it's removed. So this suggestion is not possible with the way declarative shadow DOM behaves.

If we warn that specifier references without an entry in the module map at `shadowrootadoptedsytlesheets` parse time should always have a corresponding `<link rel=modulepreload>`, that would mostly address these issues, as it would 1) provide an element to fire load/error elements on (the `<link>`) and 2) prevent an FOUC via preloading.

> It being an array doesn't seem relevant, since the ordering in the array is specified via the URL order, regardless of how long resources take to fetch.

I brought up the array to point out that it's not just a single FOUC like a `<link>` tag, it's a list of fetches. If you specify `a.css`, `b.css`, and `c.css`, does each fetch complete update `adoptedStyleSheets` upon each fetch completion or when all are completed? I don't believe there's an existing precedent for an attribute triggering multiple fetches, so I'm not sure how the resolution should behave.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1195#issuecomment-3916430559
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1195/3916430559@github.com>