Sharing styles with Declarative Shadow DOM

[KurtCattiSchmidt]

Session description

Script-based Shadow DOM can share styles with AdoptedStylesheets, but Declarative Shadow DOM must either initiate network requests or use scripting to share styles. This session will discuss various proposals for sharing styles with Shadow DOM's declaratively. These include:

WICG/webcomponents#909
w3c/csswg-drafts#10176

Session goal

Come to a consensus on which approach is preferred for sharing stylesheets in Declarative Shadow DOM.

Additional session chairs (Optional)

No response

Who can attend

Anyone may attend (Default)

IRC channel (Optional)

#share-styles

Other sessions where we should avoid scheduling conflicts (Optional)

#27, #75

Instructions for meeting planners (Optional)

No response

Agenda for the meeting.

1. Discuss requirements from developers
   a. Fully declarative (no network requests)
   b. Able to opt-in for specific shadow roots
   c. Able to export styles out of shadow roots
2. Discuss various proposals
   a. "open-stylable" Shadow Roots WICG/webcomponents#909
   b. [css-cascade-5] Add an adoptStyles capability in ShadowRoots (WICG 909: open-stylable Shadow Roots) csswg-drafts#10176

Links to calendar

• 2024-09-25, 08:30 - 09:30

Meeting materials

• Minutes

[tpac-breakout-bot]

Thank you for proposing a session!

You may update the session description as needed and at any time before the meeting, but please keep in mind that tooling relies on issue formatting: follow the instructions and leave all headings and other formatting intact in particular. Bots and W3C meeting organizers may also update the description, to fix formatting issues or add links and other relevant information. Please do not revert these changes. Feel free to use comments to raise questions.

Do not expect formal approval; W3C meeting organizers endeavor to schedule all proposed sessions that are in scope for a breakout. Actual scheduling should take place shortly before the meeting.

[justinfagnani]

Hi @KurtCattiSchmidt, this topic is exactly what we intend to cover in #29

[KurtCattiSchmidt]

Thanks Justin! I think it will make sense to have both sessions. I was planning on covering the problem more broadly, going over background, requirements from developers, and discussing some of the other proposals from the thread.

I do think declarative CSS modules are the best solution, but I also think it's worth discussing the background and other suggestions, given that this thread got so much engagement and alternate proposals.

That way #29 can stay focused on the specifics of CSS Declarative Modules (of which I think there's a lot to discuss!). I also think it's good that my session is earlier in the day, so I can direct people to the later session.

@rniwa - what do you think about this arrangement?

I'll share my slides and our explainer here later in the week.

[rniwa]

Sounds reasonable to me.

[KurtCattiSchmidt]

Here's a draft of my slides for reference - I still need to convert them to the TPAC template but this should give an idea of content: https://docs.google.com/presentation/d/1GfFzROUKWqUde300qDDzi9ydKdpjuOVX9L7kGLyZcpA/edit?usp=sharing

[dandclark]

Expand for the minutes from the Sept 25 TPAC breakout session

present+
8:37 AM E present+
8:37 AM → siye3 joined (~siye@9d40a032.publics.cloak)
8:37 AM A Alison Maher Slides: https://docs.google.com/presentation/d/1GfFzROUKWqUde300qDDzi9ydKdpjuOVX9L7kGLyZcpA/edit?usp=sharing
8:37 AM → kbabbitt joined (~kbabbitt@9d40a032.publics.cloak)
8:37 AM J Jesse Jurman present+
8:37 AM → sanketj joined (~uid392014@9b5cb9fd.public.cloak)
8:38 AM K present+
8:38 AM S present+
8:38 AM A Alison Maher explainer: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ShadowDOM/explainer.md
8:38 AM present+
8:39 AM → kizu joined (~kizu@9d40a032.publics.cloak)
8:39 AM D Dan Clark present+
8:39 AM scribe: dandclark
8:39 AM kurt:
8:39 AM K present+
8:39 AM D Dan Clark ...: Style sharing in declarative shadow dom is unsolved problem
8:40 AM ...: adoptedStyleSheets allows you to have styles that don't apply to root doc, and shadow roots can opt in
8:40 AM ...: Can plug in mutliple sheets
8:41 AM ...: Shouldn't have to compromise with markup-based version
8:41 AM ...: DSD doesn't have this yet.
8:41 AM ...: DSD has advantages. Perf, developer friendly.
8:41 AM ...: No JS, SEO friendly
8:42 AM ...: You can use JS adoptedStylesheets with DSD, but that requires script. Can have FOUC. Ergonomics are worse.
8:42 AM ...: Doesn't work with script disabled
8:42 AM → robglidden joined (~robglidden@9d40a032.publics.cloak)
8:43 AM D Dan Clark ...: Using in is a workaround solving lots of these problems. Why do we still need another solution?
8:43 AM ...: Because we don't always want to use an external file. Sometimes prefer inline styles.
8:43 AM ...: Parsing and applying other stylesheet can come after FCP
8:44 AM ...: DataURI needs to be parsed separately for each instance. Dev ergonomics not good.
8:45 AM ...: Only one stylesheet per link tag. Not good if your styles are modular; the issues get multipled per sheet.
8:46 AM ...: Ideal solution is all markup-based, supports inline styles, aligns with script-based adoptedStyleSheets, can define style without applying them.
8:47 AM ...: Should be forward-looking towards other resource types.
8:48 AM ...: One suggestions is for fully-open styles for shadow DOM. This solves problem but still leaves gap with adoptedStyleSheets. Confusing to have isolation with script but not style. Styles can leak.
8:48 AM Justin: (In other chat?) These solve a different problem.
8:49 AM kurt: Currently not a notion of defining a stylesheet in markup and not applying it to main document.
8:49 AM → bkardell_ joined (~uid10373@9b5cb9fd.public.cloak)
8:49 AM D Dan Clark ...: Imperative adoptedStylesheets must be constructed. This requirement has been loosened in spec but not implemented yet.
8:50 AM ...: Proposal @layer and adoptStyles, supported in Chromium
8:50 AM (Many people): Everyone supports
8:50 AM kurt: Can selectively inherit styles, rename them
8:51 AM ...: Doesn't quite solve issue because doesn't integrate well with adoptedStyleSheets. Doesn't have ability to define styles without apply to light DOM by default. Not extensible for other resource types. I did prototype this but not sure it's right solution.
8:52 AM ...: Other proposal for @sheets. Give identifiers to sheets, give it to adoptedStylesheets on template. Still can't define styles without applying to light DOM. Not extensible to other resource types.
8:52 AM ntim: It's not standardized.
8:53 AM bkardell: What do you mean it's not extensible?
8:53 AM kurt: Devs might want to share other types of resources. E.g. Images
8:53 AM dandclark: Particularly HTML
8:53 AM → justinf joined (~justinf@9d40a032.publics.cloak)
8:54 AM D Dan Clark masonf: One of your requirements was not passing styles through multiple layers?
8:54 AM → michael_warren joined (~michael_warren@9d40a032.publics.cloak)
8:54 AM D Dan Clark kurt: Yes, this would have that issue.
8:54 AM M<michael_warren> for posterity from zoom:
8:54 AM imo the question of whether or not @sheet is the right approach is a big one for any sort of “add styles to shadow roots” approach
8:54 AM J @sheet doesn't work
8:54 AM D Dan Clark @@@: To make sure I understand, you're looking for hot-linking but in different medium?
8:54 AM kurt: Want it to be pure markup
8:55 AM J Jeffrey Yasskin s/@@@/OwenBuckley/
8:55 AM → miriam and obuckley joined
8:56 AM D Dan Clark justinf: Pointing out some options. Key use case is SSR. Often or all the time with SSR don't know ahead of time what components you will emit. So declaring styles above and then using them later is not enough. Need to be able to emit style deep in a component and have it be usable later.
8:56 AM → Romain joined (~Romain@9d40a032.publics.cloak)
8:56 AM D Dan Clark kurt: ID-based solutions don't work because it's not global
8:56 AM J there's an existing problem with JS modules of sharing inline modules with imported modules. Maybe you want to inline a polyfill and import it later when loading the main JS bundle, without duplication
8:57 AM so a specifier-based solution could apply to all modules, regardless of type
8:57 AM D Dan Clark kurt: CSS module scripts can be used with adoptedStyleSheets. Extension to script-based adoptedStyleSheets.
8:57 AM ...: It's elegant, CSS module syntax is powerful
8:57 AM ...: Can imagine declarative version of this.
8:58 AM ...: Define CSS module in <script> tag. Put the specifier in attribute to apply it to shadow.
8:58 AM O wouldn't you lose syntax highlighting? how come not a style tag but with similar API?
8:58 AM D Dan Clark ...: This is the solution we want to look into. Meets the requirements we listed.
8:58 AM J why would you need syntax highlighting?
8:59 AM B— bkardell_ who remembers using this before :)
8:59 AM J Jeffrey Yasskin This doesn't immediately meet Justin's requirement that the server-side renderer can discover its shared stylesheets as it runs, right?
8:59 AM O isn't syntax highlighting nice? not a deal breaker, but most folks seem to value it in their IDE i guess
8:59 AM D Dan Clark ...: Is markup-based, scoping is global for the document
9:00 AM J you would most likely be writing your CSS in .css files
9:00 AM this is for SSR
9:00 AM J Jeffrey Yasskin q+
9:00 AM Z— Zakim sees jyasskin on the speaker queue
9:00 AM M<michael_warren> syntax highlighters could probably be updated to <script type="css-module"> as css instead of js...knowing the little i know of codemirror language parsers I think thats not terrible hard?
9:00 AM D Dan Clark ...: There's another session today
9:00 AM q+
9:00 AM Z— Zakim sees jyasskin, dandclark on the speaker queue
9:00 AM D Dan Clark masonf: It's in the module graph?
9:00 AM kurt: Yes
9:00 AM J no one is going to write in this format
9:00 AM just like people don't write SSR output by hand
9:00 AM J Jeffrey Yasskin Even if they do, editors can realize that type=css-module should be syntax-highlighted.
9:00 AM J sure
9:01 AM q+
9:01 AM Z— Zakim sees jyasskin, dandclark, justinf on the speaker queue
9:01 AM D Dan Clark kurt: We think this CSS-modules based solution is the best. What do others think?
9:01 AM W Westbrook Johnson q+
9:01 AM Z— Zakim sees jyasskin, dandclark, justinf, westbrook on the speaker queue
9:01 AM → emilio and Tien joined
9:01 AM D Dan Clark jyasskin: Justin mentioned SSR requrement. Script that's rendering discovers it needs a sheet, can use it later. Not sure if declarative CSS modules meet that.
9:01 AM O ok, i thought this was a <style> defined elsewhere like in a HTML page, and this was "hot linking" that to the template. so wouldn't the CSS likely be in something ending in .html?
9:01 AM D Dan Clark kurt: I agree
9:01 AM E q+
9:01 AM Z— Zakim sees jyasskin, dandclark, justinf, westbrook, emilio on the speaker queue
9:02 AM J Jeffrey Yasskin ack jyasskin
9:02 AM Z— Zakim sees dandclark, justinf, westbrook, emilio on the speaker queue
9:02 AM O i guess i was just curious why not use a style tag + the custom attribute is all
9:02 AM J because what it's really doing is defining a module script in the module graph
9:03 AM O but I guess it's a CSS "module" so more on the JS side
9:03 AM M Miriam Suzanne and a style element would apply the styles to the page by default
9:03 AM O got it, that makes sense
9:03 AM thanks
9:03 AM D Dan Clark dandclark: This should work for SSR case
9:03 AM K q+ mason
9:03 AM Z— Zakim sees dandclark, justinf, westbrook, emilio, mason on the speaker queue
9:03 AM S q?
9:03 AM K q+
9:03 AM Z— Zakim sees dandclark, justinf, westbrook, emilio, mason on the speaker queue
9:03 AM Z— Zakim sees dandclark, justinf, westbrook, emilio, mason, keithamus on the speaker queue
9:04 AM J <script> is more general
9:04 AM you could use the for JSON too
9:04 AM M<michael_warren> <style type="module">?
9:04 AM J then what do you do for JSON?
9:05 AM R +1 for using
9:05 AM J The <script> solution neatly solves many other problems too
9:05 AM M<michael_warren> yeah, that does feel a bit piecemeal whereas a more standardized specifier solution for modules of different kinds that current exist but is also extensible for new module types later on
9:05 AM M dandclark: let's decide if this is a good idea first, then we can bikeshed
9:05 AM q?
9:05 AM Z— Zakim sees dandclark, justinf, westbrook, emilio, mason, keithamus on the speaker queue
9:05 AM M ack dandclark
9:05 AM Z— Zakim sees justinf, westbrook, emilio, mason, keithamus on the speaker queue
9:05 AM M ack justin
9:05 AM Z— Zakim sees westbrook, emilio, mason, keithamus on the speaker queue
9:06 AM B<bkardell_> present+
9:06 AM D Dan Clark justinf: Editors can update to do syntax highlighting for this
9:06 AM J whatwg/html#7367
9:06 AM D Dan Clark justinf: I like this solution. There's lots of problems relating to modules this can solve. Want to import script early on, then use it later on when stuff loads. Set up your script then use it later from your app bundle.
9:06 AM O yeah, if it becomes a standard then yeah in theory all IDEs should adopt. in the meantime, will keep waiting for nesting highlighting in VSCode :)
9:07 AM D Dan Clark ...: Longstanding issue with module-related properties in script tag. Solves that as well. Want to get access to exports of a given script tag, can just import it.
9:07 AM M<michael_warren> q+
9:07 AM Z— Zakim sees westbrook, emilio, mason, keithamus, michael_warren on the speaker queue
9:08 AM D Dan Clark ...: Works with JSON, other module types that come in the future. This version is really powerful. Has a lot of open questions about module graph and timing though. Race conditions like you load easily and do SSR, have 2 competing things. One tries to define specifier and one loads it. One hits the network and one doesn't. What happens, do you abort fetch?
9:08 AM M<michael_warren> q-
9:08 AM Z— Zakim sees westbrook, emilio, mason, keithamus on the speaker queue
9:08 AM M q- mason
9:08 AM Z— Zakim sees westbrook, emilio, keithamus on the speaker queue
9:08 AM D Dan Clark kurt: Yes we need to think about these
9:09 AM justinf: Neeed to think about how this works with import maps
9:09 AM ...: Also includes integrity. Can think about these inline scripts telling browser something about module and also populating module map
9:09 AM ...: Can say this pattern for these types of paths are going to be inline.
9:10 AM M ack westbrook
9:10 AM Z— Zakim sees emilio, keithamus on the speaker queue
9:10 AM D Dan Clark westbrook: This all looks great. Let's investigate more deeply. You're already open to investigating other syntaxes. Use of script tag causes problems if JS is turned off. Talk about putting this into module graph.
9:11 AM K dandclark: in chromium, the point where we do those checks is when parsing a script tag, I can't think of a reason where you can't run that stuff with script turned off...
9:11 AM D Dan Clark kurt: Seems workable, not sure what haappens today. Good question.
9:11 AM J there's a similar question + answer for HTML modules
9:12 AM M ack emilio
9:12 AM Z— Zakim sees keithamus on the speaker queue
9:12 AM D Dan Clark ...: May or may not be issue, but it should be solvable
9:12 AM M<michael_warren> q+
9:12 AM Z— Zakim sees keithamus, michael_warren on the speaker queue
9:12 AM J <style> is the default solution for Lit SSR now
9:12 AM D Dan Clark emilio: I was surprised to not see mention of inline styles. If this is a thing for SSR that's the obvious thing. Causes duplication in DOM but not style engine. Is that intentional omission?
9:12 AM J it bloats the payload hugely
9:13 AM gzip helps a lot, but there's still parsing time
9:13 AM J— jyasskin justin, you can qq+ to respond directly
9:13 AM J ah, thanks
9:13 AM D Dan Clark kurt: I should have listed that. The engines will optimize.
9:13 AM masonf: Doesn't play well with adoptedStylesheets, they're copy on write
9:14 AM emilio: Generally the CSSWG has been against mutating CSSOM stuff. But yes, the semantics may not be what you want
9:14 AM justinf: You have to duplicate styles in your payload
9:14 AM K dandclark: that's similar to feedback we've gotten from developers internally ,want to avoid duplication of DOM & stylesheets
9:15 AM D Dan Clark emilio: Don't you have the declarative duplication in the DOM?
9:15 AM justinf: You want to be able to remove that
9:15 AM J Jeffrey Yasskin dandclark: And this proposal could generalize to deduplicating HTML structure.
9:16 AM bkardell_: That's an argument to use .
9:16 AM J <script ype="html">
9:16 AM ⇐ siye3 quit (~siye@9d40a032.publics.cloak)
9:17 AM J Jeffrey Yasskin ryosuke: <Script> won't run either, but it can't be nested.
9:17 AM D Dan Clark masonf: I am sympathetic to emilio's point. But in the DOM repeatd compoents are repeated, that's not necessarily the case for CSS
9:17 AM emilio: Not sure I get that.
9:17 AM masonf: Issue is people think why is it repeated, it shouldn't have to be
9:17 AM ...: If you have 3 components there are 3 in dom by definiiton
9:18 AM M q?
9:18 AM Z— Zakim sees keithamus, michael_warren on the speaker queue
9:18 AM D Dan Clark emilio: Before, people would innerHTML the whole tree. Not trying to say stop, just curious. Seemed like an omission
9:18 AM M ack keith
9:18 AM Z— Zakim sees michael_warren on the speaker queue
9:18 AM D Dan Clark kurt: Yes we should have included this
9:18 AM kcirkel: This doesn't include images?
9:18 AM kurt: Not yet
9:18 AM K s/kcirkel/keithamus/
9:18 AM D Dan Clark ...: But this could set up for that
9:19 AM keithamus: I'm concerned about timing of when these get declared.
9:20 AM ...: Potential new vector authors must consider for 3p components. They define a module, then their identifiers clobber mine. Could be incidental, could be malicious. 3p modules defines a bunch of these, with common names. And how does that work in terms of timing? I define, someone else defines, what happens?
9:20 AM kurt: Yes we need to explore this.
9:20 AM J qq+ WASM modules too
9:20 AM Z— Zakim justinf, you typed too many words without commas; I suspect you forgot to start with 'to ...'
9:21 AM D Dan Clark keithamus: Need to think through story of HTML module. Given that closing script tag is big footgun. Maybe be better. Can you have nested templates?
9:21 AM J Jeffrey Yasskin qq+ justinf
9:21 AM Z— Zakim sees justinf, michael_warren on the speaker queue
9:21 AM D Dan Clark rniwa: yes
9:21 AM J we should consider WASM modules too. Do people want to inline a WASM module, then import it into an inline JS module to kick it off?
9:21 AM D Dan Clark keithamus: I can see you wanting to have script tag in HTML module. Not allowed in script, but allows matching
9:21 AM rniwa: How does it work with prefetch?
9:21 AM S q?
9:21 AM Z— Zakim sees justinf, michael_warren on the speaker queue
9:22 AM M ack michael
9:22 AM Z— Zakim sees justinf on the speaker queue
9:22 AM M q+ rniwa
9:22 AM Z— Zakim sees justinf, rniwa on the speaker queue
9:22 AM J— jyasskin Sorry, q+ goes to the end of the queue; qq+ goes to the front to directly respond to a point.
9:22 AM J ah
9:23 AM K— keithamus I think you want q+ to talk about <blah>
9:23 AM J qq+ specifiers
9:23 AM Z— Zakim sees specifiers, justinf, rniwa on the speaker queue
9:23 AM K ack specifiers
9:23 AM Z Bridge daemon specifiers, you wanted to react to michael_warren
9:23 AM Z— Zakim sees justinf, rniwa on the speaker queue
9:23 AM J argh, I'm terrible at this
9:23 AM → rniwa joined (~rniwa@9d40a032.publics.cloak)
9:23 AM D Dan Clark michael_warren: I know this is baked into sharing with DSD. Can extend to JS- based components? Also, clarifying q about specifiers. They look like file paths but do they need to be? What if you identifier clobbers actual file?
9:23 AM K q+ justinf to talk about specifiers
9:23 AM Z— Zakim sees justinf, rniwa on the speaker queue
9:24 AM D Dan Clark q++ to talk about specifiers, collisions
9:24 AM Z— Zakim sees justinf, rniwa, + on the speaker queue
9:24 AM R q?
9:24 AM Z— Zakim sees justinf, rniwa, + on the speaker queue
9:24 AM M ack justin
9:24 AM Z Bridge daemon justinf, you wanted to react to keithamus and to talk about specifiers
9:24 AM Z— Zakim sees rniwa, + on the speaker queue
9:25 AM M q+ dandclark
9:25 AM Z— Zakim sees rniwa, +, dandclark on the speaker queue
9:25 AM M ack +
9:25 AM Z Bridge daemon +, you wanted to talk about specifiers, collisions
9:25 AM Z— Zakim sees rniwa, dandclark on the speaker queue
9:26 AM J Jeffrey Yasskin Dynamic import maps ( whatwg/html#10528) look related to the way this proposal extends the module map.
9:26 AM D Dan Clark justinf: This is the JS version. It is a DOM version of what exists. Not everyone uses existing version because not supported in all browsers. We would synthesize specifier, use that as a global ID until people shift to using this. Problem with imperative version is you have object sitting in JS heap, how do I serialize that to the DOM? I proposed global ID. Can treat specifiers like that.
9:26 AM kurt: that was xid?
9:26 AM justinf: yes
9:26 AM M ack rniwa
9:26 AM Z— Zakim sees dandclark on the speaker queue
9:26 AM M<michael_warren> would this solution also deal with styles/modules added dynamically? particularly in the imperative case?
9:27 AM D Dan Clark rniwa: Earlier point about prefetch -- if we do this in declarative, there will be delay between when sheet appears and browser fetches subresources.
9:27 AM M<michael_warren> i think thats one of the problems with the imperative approach right now...what happens when new sheets are added dynamically like light.css default and dark.css added once the user clicks the mode switch button etc
9:27 AM D Dan Clark ...: Need to solve how we'll get subresources in time
9:27 AM M ack dand
9:27 AM Z— Zakim sees no one on the speaker queue
9:27 AM J the sub-resource problem isn't any worse than the existing solutions, yeah?
9:28 AM <style>...</style> already has this?
9:28 AM M dandclark: on the prefetch thing, you can do module preload for external resources. You can inline the rest. We should talk more.
9:28 AM ⇐ rniwa quit (~rniwa@9d40a032.publics.cloak)
9:28 AM M dandclark: third party resource overwrite problem: you already have to worry about that with existing modules. When I import a third party module, they can put whatever they want into the graph anyway. Maybe this is not a new problem?
9:28 AM q?
9:28 AM Z— Zakim sees no one on the speaker queue
9:28 AM W Westbrook Johnson How can we support on going research?
9:29 AM J @import should be banned
9:29 AM it's banned in constructible stylesheets
9:29 AM M dandclark: about @import, not sure about this. We haven't solved this anyway, so we need to figure it out.
9:29 AM dandclark: we do the same thing we do today, which is failing the import. Or whatever we do.
9:29 AM q?
9:29 AM Z— Zakim sees no one on the speaker queue
9:30 AM D Dan Clark kurt: Please attend CSS modules session later today. Hopefully we agree this is the solution to pursue. Please raise issues.