- From: L. David Baron <notifications@github.com>
- Date: Tue, 10 Sep 2019 18:11:59 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/405/530177847@github.com>
I'm currently looking at this with @kenchris in a breakout at the TAG meeting. I think we both think this looks pretty reasonable. I'm a little concerned about bypassing handling of `@import` for now -- worried that people will be disturbed by this feature not working. I'd note that at least some (maybe all?) browser CSS implementations use copy-on-write sharing for stylesheets that are `@import`ed multiple times (whose CSSOM representation start off as thin wrappers until they're accessed). So that might argue for just continuing to use that model. On the other hand, the desire to handle `@import`s in a way that allows the CSSOM to modify all the instances at once seems like a reasonable desire as well -- and it seems reasonable to do CSS modules such that `@import`s share the `CSSStyleSheet` objects, they're all part of the module graph, and any stylesheet that's part of the module graph just has a null parent style sheet even if it's actually imported in one or more places. It's a slightly bigger change to the model, but it does have benefits. It's not clear to me what the benefit of deferring the decision is. Is there particular evidence you're waiting for to settle this? If not, it seems like it might be better to hammer out the decision sooner rather than crippling part of the feature just because of failure to agree on which path to take. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/405#issuecomment-530177847
Received on Wednesday, 11 September 2019 01:12:22 UTC