| 05:53 | <annevk> | I'm pretty sure that when we did CSS imports we decided we would solve this before adding declarative markup. |
| 05:54 | <annevk> | Also from a CSP and security perspective it would be very weird if it suddenly started fetching more things. |
| 07:07 | <Noam Rosenthal> | I don't see how there is a CSP/security issue in doing this later. Also I don't know what we decided in the past, I wasn't there and it's a bit vague. I think declaratively importing modules and module support in @import are both important but I don't see why there is a clear order of which should come first. |
| 07:22 | <Noam Rosenthal> | As in <link rel=stylesheet> already fetches things, eg images and fonts and the stylesheet itself. The fact that type=module only fetches one style max and might fetch more in the future doesn't change that essence |
| 08:36 | <Noam Rosenthal> | Either way I think that an import attribute is slightly better... Maybe later we can have <style type=module> that imports from the module graph and tries to behave more like script |
| 09:22 | <JaseW> | Catching up.. It would be great to see a “where are we with CSS Modules” as a whole at TPAC. It would be great to have parity with scripts from a developer point of view, but I understand link works different and may not need the type=module. Scripts fetch the whole graph, I assume there’s currently no way for CSS to do this as @import isn’t supported in this context? |
| 09:50 | <annevk> | It's probably good to look into the history to understand why it might or might not be a problem then. Especially for module scripts there were a lot of concerns around all of this. |
| 15:11 | <annevk> | jarhar: any chance you can look at https://github.com/whatwg/html/pull/13005 today? |
| 15:11 | <annevk> | jarhar: https://github.com/whatwg/html/pull/12940 would be nice to land too as well as the tests. |
| 18:43 | <Kurt Catti-Schmidt> | Thanks annevk , this is a good idea to research. Noam Rosenthal is correct, it matches a style import via script (and modulepreload) where only the top-level resource is fetched. I did a deep-dive on the history here and I found a few things: There was this breakout, where it was agreed that @import gets ignored. Anne, you mentioned CSP briefly, but I didn't see any other discussion about it: https://www.w3.org/2020/10/29-components-minutes.html There's this topic dedicated to @import in CSS module scripts, with no mention of CSP or anything blocking a declarative version: https://github.com/WICG/webcomponents/issues/870 There's this discussion on MIME type enforcement with a mention of CSP not being sufficient, but 1) this proposal would be restricting the MIME type to text/css anyways and 2) No mention of @import: https://github.com/WICG/webcomponents/issues/839 The main discussion on CSS Module Script Imports has lots of discussion on @import, with the general agreement that it needs to be redesigned to work differently, but no mention of CSP or blocking a declarative version: https://github.com/WICG/webcomponents/issues/759 There's this proposal to use I don't see any mention of blocking on @import or CSP before declarative markup is solved in any of these. I do see desire to rewrite @import for modules, but I don't see how this would restrict that. I did come across this thread where Ryuske suggested blocking on adoptedStyleSheets in general until a declarative version was proposed, which is what this proposal essentially is: https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-826399951. Maybe that's what you were thinking of annevk ? |
| 18:48 | <Kurt Catti-Schmidt> | I have an hour reserved for this on the TPAC agenda for https://github.com/whatwg/html/pull/12860 JaseW After that I will continue to work on resolving https://github.com/whatwg/html/pull/11687 for declarative style module exports. AFAIK there are no other active proposals. I don't see any evidence that anyone is working on @import in a module context, although there was interest expressed by the community in a few threads. |
| 19:33 | <Noam Rosenthal> | The relevant past discussion is https://github.com/WICG/webcomponents/issues/870#issuecomment-719067611 from TPAC 2020 |
| 19:42 | <Noam Rosenthal> | The point I kind of agree with is that a CSS module is currently a leaf, which is inconsistent with But the main reason to use the import attribute is that overloading href to support specifiers has slightly weird consequences. |
| 20:37 | <Kurt Catti-Schmidt> | Yeah, agreed. Plus the import attribute semantically ties it to a script-like import and allows for fallback, whereas making href behave differently based on type=module in this one instance seems confusing. |