- From: Westbrook Johnson <notifications@github.com>
- Date: Fri, 07 Feb 2025 12:22:53 -0800
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/1083/2644052224@github.com>
Great session today! Thanks you so much for everyone who was able to make time to join in the conversation. 🙇♂ Notes from today's session are available [here](https://docs.google.com/document/d/1yfYARhuobQb3lKOGYLhD1D6NlVEYvel-RBzA-mjAPT4/edit?tab=t.0#heading=h.8cs25bxv3n61). ### Action Items: - [ ] `@sheet`: @KurtCattiSchmidt to process feedback from the conversation into issues - [ ] Declarative CSS Module Scripts: @KurtCattiSchmidt to process feedback from the conversation into issues - [ ] Adopting non-Constructed StyleSheets: - [ ] @sorvell to prepare cross document testing of the feature - [ ] continued testing of the Firefox Nighty implementations - [ ] Expanding export parts: @sorvell to process feedback into the next round of discussion - [ ] `:host(:has(...))` and `:host:has(...)` - should we expand or contract this unspecified functionality? - [ ] @justinfagnani to share some recent use cases to help clarify the benefits of each for implementors - [ ] @rniwa, @smaug---- and (maybe) @kbabbitt to get insight from there respective teams if there are any blockers to expanding the spec to include this - [ ] Everyone is asked to review https://github.com/WICG/webcomponents/issues/1049 to see if it is worth developers spending time on thinking through before the Q2 face-to-face for deeper exploration See you all next week for even more great discussion! 👋🏼 <details> <summary>Session chat hidden within...</summary> You 12:59 PM https://docs.google.com/document/d/1yfYARhuobQb3lKOGYLhD1D6NlVEYvel-RBzA-mjAPT4/edit?tab=t.0#heading=h.8cs25bxv3n61 keep Pinned Kurt Catti-Schmidt 1:09 PM https://docs.google.com/presentation/d/1OUr5IYQ-t4jlqPCalkTG55e8SHbkXTGCeIqv1uR1dyA/edit#slide=id.p Dan Clark 1:13 PM nit: the `assert` keyword is now `with` :) Rob Eisenberg 1:15 PM Hate to bike shed too much, but what about an "import" attribute instead of "sheet" to use existing terminology and make things a bit more extensible for other link types in the future. Andy Luhrs 1:16 PM Definitely could make sense once we stabilize direction a bit Mayank 1:17 PM The advantage of "sheet.css#sheet1" is that it avoids introducing new API. It's "just" a URL. Justin Fagnani 1:18 PM right, but that still leaves the question of how to reference a sheet from an inline style Rob Eisenberg 1:18 PM It seems as if there are two proposals, but frankly the first one should be rejected because it doesn't meet the requirements. So, really only the sheet attr meets all the requirements. Justin Fagnani 1:24 PM and what about nested @sheet? Is nesting disallowed? Justin Fagnani 1:25 PM IMO, we shouldn't talk about "the global sheet" we have multiple nested scopes. What works "globally" should work the same in a shadow root Mayank 1:27 PM Lifting the `constructed` limitation on `adoptedStyleSheets` also implies allowing `@import`, no? You 1:27 PM 👆 great added case for testing the change Keith is working on to remove that in Firefox as of late. Justin Fagnani 1:28 PM not directly, I don't think. The big question was whether @import from within an constructed stylesheet created a new stylesheet object or reused a shared object ^ re: Mayank Pascal Vos 1:29 PM i wonder if with custom elements will start streaming css in to one file SRR wise Mayank 1:30 PM `<link rel layer>` is being proposed. Mayank 1:32 PM I would love for CSS modules to export mixins, functions, keyframes, properties, sheets, etc. A lot of these are more relevant for CSS than for JS. Jochen Kühner 1:34 PM maybe we need levels in the javascript export like { sheets: ..., classes: .... }, so they are not directly on the object Rob Eisenberg 1:36 PM Well, especially when we get functions, combined with properties, we're talking about all the same things that JS needs. So, some sort of generic way to export things from a .css file and some way to generically import/apply any of those things in a variety of contexts. Mayank 1:39 PM The advantage over named `{ sheet1 }` import over `default.sheet1` needs to be justified. s/over/of Rob Eisenberg 1:41 PM I think making exports explicit is something we should definitely consider. +100 Pascal Vos 1:41 PM react has a lot of librarys like styled-components that uses importing class i think i remember there are others as well already in userland Mayank 1:43 PM Re: layer attribute on link, here's the proposal: https://css.oddbird.net/layers/link-layer/ Justin Fagnani 1:45 PM I think the TAG was just wrong on this point though. Might be worth going back to them on it. Rob Eisenberg 1:46 PM I think tag was wrong in focusing on @sheet. It should be focusing on the general problem of export/import. Wiht that in place, we can have an HTML syntax that will work for not only css but js, wasm, and html as well. Rob Eisenberg 1:51 PM +1 to what Justin is saying. Need to consider how a server will actually work when streaming nested component trees. Pascal Vos 1:52 PM would scoping to CE scoped registry make sense? Rob Eisenberg 1:54 PM I think we need to consider that all this should be usable independent of custom elements. Justin Fagnani 1:54 PM it needs to be global Justin Fagnani 1:56 PM <link> doesn't help here because in order to not have many network requests you need to href the same file, but you don't know the contents of the file yet as you're streaming Pascal Vos 1:56 PM would this also work with ShadowRealm ? cause it got seperated vm then right like iframe Mayank 1:57 PM Kurt was describing `<link rel="stylesheet" href="#style-element">` earlier, which should help with streaming. re: Justin Justin Fagnani 1:57 PM <script> would usually be tool output. Humans wouldn't write styles that way Mayank 2:00 PM Not everyone uses tooling. Rob Eisenberg 2:00 PM I know that adding new tags to html are difficult, but what about having a <module> element with a type attr. And then having an <import> element to import from any type of module? You 2:00 PM is="sheet"? Dan Clark 2:00 PM We should think ahead to declarative HTML modules scripts too. Would we write those in a <script> tag too? IMO it would be a lot nicer for it to be a <template>. Mayank 2:01 PM <template> makes a lot of sense. Justin Fagnani 2:01 PM it doesn't to me Pascal Vos 2:01 PM why not put style tag in a template? Justin Fagnani 2:01 PM you're not instantiating a HTML module times *multiple times Pascal Vos 2:01 PM <style-template? Dan Clark 2:02 PM I think the case where you'd want to instantiate an HTML module a bunch of times is if you have multiple instances of a component with a shadow DOM. You'd want to define the HTML module in one place, then include it into each component's shadow somehow. Mayank 2:02 PM (I write DSD by hand all the time) Danny Blue 2:02 PM And there are uses for it outside of web components which means they are outside of tooling or your SSR would be handled by something like liquid or handlebars or something which will need to have the tags themselves Pascal Vos 2:03 PM you could stream css in to a css file i guess and add it by sheet.. Steve Orvell 2:04 PM Don't mean to pile on Kurt: super happy to have you and M$ working on this! Olli Pettay 2:06 PM Browsers cache the parsed stylesheets in case of same-origin page loads. No need to even parse anything ...when loading a new page. Just do basically a hashtable lookup Justin Fagnani 2:08 PM https://github.com/w3c/csswg-drafts/issues/3714 Pascal Vos 2:08 PM yes Dan Clark 2:11 PM That's what I was going to ask :) Kurt Catti-Schmidt 2:12 PM https://github.com/w3c/csswg-drafts/issues/10013 Kurt Catti-Schmidt 2:16 PM https://web.dev/articles/css-module-scripts#import_rules_not_yet_allowed Justin Fagnani 2:17 PM https://github.com/w3c/csswg-drafts/issues/6130 is relevant You 2:17 PM 🙇♂️ Mayank 2:19 PM constructed ≠ adopted You 2:20 PM Great point! Mayank 2:23 PM StyleSheetObserver issue might be relevant to the contructed discussion: https://github.com/WICG/webcomponents/issues/1041 Jochen Kühner 2:24 PM Does the cross document case work at the moment with JS created adopted Stylesheets? At the moment I need to clone them in chrome manualy Pascal Vos 2:28 PM probably if you want to use astrix people would also want regex like things here ^startswith-* You 2:32 PM Possibly related microsyntax discussion? https://lea.verou.me/specs/var-groups/ Jochen Kühner 2:32 PM maybe the * should only match at the end at a first draft, otherwise the comparison would be much complexer and slower Pascal Vos 2:42 PM this is tree up, there not a better way to think of style tree down somehow Jochen Kühner 2:47 PM now we see someone using the tooling only syntax in a demo ;-) Steve Orvell 2:47 PM Great explanation Westbrook Justin Fagnani 2:49 PM re @sheet and what's exported, I updated some thoughts on the CSS Reference Selector issue that maybe we want to use at-rules for references insteadL: https://github.com/w3c/csswg-drafts/issues/3714#issuecomment-2643886033 You 3:01 PM https://github.com/WICG/webcomponents/issues/1049 Steve Orvell 3:02 PM Homework for implementers... appetite for 1. decomposing shsaodw DOM 2. exposing the shadow tree as Lea proposed </details> -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/1083#issuecomment-2644052224 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/1083/2644052224@github.com>
Received on Friday, 7 February 2025 20:22:57 UTC