Re: [w3c/webcomponents] define behavior of `@import` in Cascading Style Sheet (CSS) modules (#870)

Right.

So we have some *required*, but *incompatible* behaviors:

1. JS-imported top-level CSS modules will be shared across import sites, cached by the import url. (Since they're the same object, all the children sheets are the same object, but `@import`ing the same sheet in multiple JS-imported sheets can go either way.)
2. `<link>`-imported CSS sheets, and their `@import`'d child sheets, will be distinct stylesheet objects regardless of URL. (But might share their contents in copy-on-write semantics under the hood.)
3. Distinct calls to the CSSStylesheet constructor will always return distinct stylesheet objects, regardless of contents. (But you can stash the sheet and share it manually across different locations.) (Whether imports in a constructed sheet are shared by url or not can potentially go either way.)

We can't change any of these, and if someone used to one encounters the other, they'll have problems.

So the decision here is not "which behavior should we be consistent with", because we can't be consistent, it's "where do we draw the boundary between the two behaviors".

I believe that there's no particularly compelling usability argument either way, as the usage of crawling and mutating stylesheet objects is fairly low in general.

As such, I think the best option is to push the boundary as far in one direction as possible, so as much of the API-space is consistent as possible except for the small "quarantined" bit of inconsistency we can't remove.

Given the current spread of behaviors, I think the right choice is to keep the "everything is a distinct object" behavior as much as possible, containing the "shared objects" behavior to happen only at the JS import API; sheets imported lower down aren't shared across imports.

This keeps the overall semantics as consistent as possible; JS itself caches JS-imported sheets by url, but beyond that everything remains the same as it always has.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/870#issuecomment-599773867