14:50:17 <RRSAgent> RRSAgent has joined #share-styles
14:50:21 <RRSAgent> logging to https://www.w3.org/2024/09/25-share-styles-irc
14:50:21 <tpac-breakout-bot> RRSAgent, do not leave
14:50:22 <tpac-breakout-bot> RRSAgent, make logs public
14:50:24 <tpac-breakout-bot> Meeting: Sharing styles with Declarative Shadow DOM
14:50:24 <tpac-breakout-bot> Chair: Kurt Catti-Schmidt
14:50:24 <tpac-breakout-bot> Agenda: https://github.com/w3c/tpac2024-breakouts/issues/31
14:50:24 <Zakim> Zakim has joined #share-styles
14:50:24 <tpac-breakout-bot> Zakim, clear agenda
14:50:24 <Zakim> agenda cleared
14:50:24 <tpac-breakout-bot> Zakim, agenda+ Pick a scribe
14:50:25 <Zakim> agendum 1 added
14:50:25 <tpac-breakout-bot> Zakim, agenda+ Reminders: code of conduct, health policies, recorded session policy
14:50:25 <Zakim> agendum 2 added
14:50:25 <tpac-breakout-bot> Zakim, agenda+ Goal of this session
14:50:27 <Zakim> agendum 3 added
14:50:27 <tpac-breakout-bot> Zakim, agenda+ Discussion
14:50:27 <Zakim> agendum 4 added
14:50:27 <tpac-breakout-bot> Zakim, agenda+ Next steps / where discussion continues
14:50:28 <Zakim> agendum 5 added
14:50:28 <tpac-breakout-bot> tpac-breakout-bot has left #share-styles
15:30:09 <JRJurman> JRJurman has joined #share-styles
15:33:11 <westbrook> westbrook has joined #share-styles
15:34:12 <keithamus> keithamus has joined #share-styles
15:34:17 <jyasskin> jyasskin has joined #share-styles
15:34:25 <masonf> masonf has joined #share-styles
15:34:33 <masonf> present+
15:34:45 <jyasskin> present+
15:35:07 <alisonmaher> alisonmaher has joined #share-styles
15:35:12 <dandclark> dandclark has joined #share-styles
15:35:53 <siye> siye has joined #share-styles
15:35:54 <astearns> astearns has joined #share-styles
15:35:59 <ethanjv> ethanjv has joined #share-styles
15:36:30 <siye1> siye1 has joined #share-styles
15:36:50 <keithamus> present+
15:37:04 <ethanjv> present+
15:37:05 <siye3> siye3 has joined #share-styles
15:37:44 <alisonmaher> Slides: https://docs.google.com/presentation/d/1GfFzROUKWqUde300qDDzi9ydKdpjuOVX9L7kGLyZcpA/edit?usp=sharing
15:37:48 <kbabbitt> kbabbitt has joined #share-styles
15:37:50 <JRJurman> present+
15:37:55 <sanketj> sanketj has joined #share-styles
15:37:56 <kbabbitt> present+
15:38:07 <sanketj> present+
15:38:21 <alisonmaher> explainer: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ShadowDOM/explainer.md
15:38:24 <alisonmaher> present+
15:39:02 <kizu> kizu has joined #share-styles
15:39:34 <dandclark> present+
15:39:38 <dandclark> scribe: dandclark
15:39:46 <dandclark> kurt: <presents slides linked above>
15:39:57 <kizu> present+
15:39:58 <dandclark> ...: Style sharing in declarative shadow dom is unsolved problem
15:40:43 <dandclark> ...: adoptedStyleSheets allows you to have styles that don't apply to root doc, and shadow roots can opt in
15:40:50 <dandclark> ...: Can plug in mutliple sheets
15:41:09 <dandclark> ...: Shouldn't have to compromise with markup-based version
15:41:26 <dandclark> ...: DSD doesn't have this yet.
15:41:37 <dandclark> ...: DSD has advantages. Perf, developer friendly.
15:41:55 <dandclark> ...: No JS, SEO friendly
15:42:27 <dandclark> ...: You can use JS adoptedStylesheets with DSD, but that requires script. Can have FOUC. Ergonomics are worse.
15:42:52 <dandclark> ...: Doesn't work with script disabled
15:42:52 <robglidden> robglidden has joined #share-styles
15:43:25 <dandclark> ...: Using <link rel> in <template> is a workaround solving lots of these problems. Why do we still need another solution?
15:43:41 <dandclark> ...: Because we don't always want to use an external file. Sometimes prefer inline styles.
15:43:58 <dandclark> ...: Parsing and applying other stylesheet can come after FCP
15:44:21 <dandclark> ...: DataURI needs to be parsed separately for each instance. Dev ergonomics not good.
15:45:06 <dandclark> ...: Only one stylesheet per link tag. Not good if your styles are modular; the issues get multipled per sheet.
15:46:35 <dandclark> ...: Ideal solution is all markup-based, supports inline styles, aligns with script-based adoptedStyleSheets, can define style without applying them.
15:47:08 <dandclark> ...: Should be forward-looking towards other resource types.
15:48:30 <dandclark> ...: 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.
15:48:54 <dandclark> Justin: (In other chat?) These solve a different problem.
15:49:36 <dandclark> kurt: Currently not a notion of defining a stylesheet in markup and not applying it to main document.
15:49:47 <bkardell_> bkardell_ has joined #share-styles
15:49:58 <dandclark> ...: Imperative adoptedStylesheets must be constructed. This requirement has been loosened in spec but not implemented yet.
15:50:28 <dandclark> ...: Proposal @layer and adoptStyles, supported in Chromium
15:50:41 <dandclark> (Many people): Everyone supports
15:50:54 <dandclark> kurt: Can selectively inherit styles, rename them
15:51:49 <dandclark> ...: 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.
15:52:35 <dandclark> ...: 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.
15:52:43 <dandclark> ntim: It's not standardized.
15:53:05 <dandclark> bkardell: What do you mean it's not extensible?
15:53:36 <dandclark> kurt: Devs might want to share other types of resources. E.g. Images
15:53:41 <dandclark> dandclark: Particularly HTML
15:53:42 <justinf> justinf has joined #share-styles
15:54:03 <dandclark> masonf: One of your requirements was not passing styles through multiple layers?
15:54:06 <michael_warren> michael_warren has joined #share-styles
15:54:08 <dandclark> kurt: Yes, this would have that issue.
15:54:23 <michael_warren> for posterity from zoom:
15:54:23 <michael_warren> 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
15:54:32 <justinf> @sheet doesn't work
15:54:44 <dandclark> @@@: To make sure I understand, you're looking for hot-linking but in different medium?
15:54:56 <dandclark> kurt: Want it to be pure markup
15:55:00 <jyasskin> s/@@@/OwenBuckley/
15:55:46 <miriam> miriam has joined #share-styles
15:56:12 <obuckley> obuckley has joined #share-styles
15:56:22 <dandclark> 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.
15:56:33 <Romain> Romain has joined #share-styles
15:56:44 <dandclark> kurt: ID-based solutions don't work because it's not global
15:56:55 <justinf> 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
15:57:11 <justinf> so a specifier-based solution could apply to _all_ modules, regardless of type
15:57:36 <dandclark> kurt: CSS module scripts can be used with adoptedStyleSheets. Extension to script-based adoptedStyleSheets.
15:57:50 <dandclark> ...: It's elegant, CSS module syntax is powerful
15:57:58 <dandclark> ...: Can imagine declarative version of this.
15:58:33 <dandclark> ...: Define CSS module in <script> tag. Put the specifier in <template adoptedstylesheets> attribute to apply it to shadow.
15:58:44 <obuckley> wouldn't you lose syntax highlighting?  how come not a style tag but with similar API?
15:58:48 <dandclark> ...: This is the solution we want to look into. Meets the requirements we listed.
15:58:56 <justinf> why would you need syntax highlighting?
15:59:37 <jyasskin> This doesn't immediately meet Justin's requirement that the server-side renderer can discover its shared stylesheets as it runs, right?
15:59:44 <obuckley> isn't syntax highlighting nice?  not a deal breaker, but most folks seem to value it in their IDE i guess
15:59:53 <dandclark> ...: Is markup-based, scoping is global for the document
15:59:59 <justinf> you would most likely be writing your CSS in .css files
16:00:02 <justinf> this is for SSR
16:00:04 <jyasskin> q+
16:00:08 <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?
16:00:09 <dandclark> ...: There's another session today
16:00:11 <dandclark> q+
16:00:19 <dandclark> masonf: It's in the module graph?
16:00:20 <dandclark> kurt: Yes
16:00:21 <justinf> no one is going to write in this format
16:00:35 <justinf> just like people don't write SSR output by hand
16:00:45 <jyasskin> Even if they do, editors can realize that `type=css-module` should be syntax-highlighted.
16:00:50 <justinf> sure
16:01:06 <justinf> q+
16:01:06 <dandclark> kurt: We think this CSS-modules based solution is the best. What do others think?
16:01:07 <westbrook> q+
16:01:16 <emilio> emilio has joined #share-styles
16:01:19 <Tien> Tien has joined #share-styles
16:01:39 <dandclark> 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.
16:01:45 <obuckley> 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?
16:01:47 <dandclark> kurt: I agree
16:01:53 <emilio> q+
16:02:22 <jyasskin> ack jyasskin
16:02:29 <obuckley> i guess i was just curious why not use a style tag + the custom attribute is all
16:02:47 <justinf> because what it's really doing is defining a module script in the module graph
16:03:06 <obuckley> but I guess it's a CSS "module" so more on the JS side
16:03:09 <miriam> and a style element would apply the styles to the page by default
16:03:23 <obuckley> got it, that makes sense
16:03:24 <obuckley> thanks
16:03:34 <dandclark> dandclark: This should work for SSR case
16:03:35 <keithamus> q+ mason
16:03:35 <sanketj> q?
16:03:36 <keithamus> q+
16:04:04 <justinf> <script> is more general
16:04:10 <justinf> you could use the for JSON too
16:04:15 <michael_warren> <style type="module">?
16:04:28 <justinf> then what do you do for JSON?
16:05:03 <Romain> +1 for using <template>
16:05:04 <justinf> The <script> solution neatly solves many other problems too
16:05:14 <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
16:05:20 <masonf> dandclark: let's decide if this is a good idea first, then we can bikeshed
16:05:51 <masonf> q?
16:05:55 <masonf> ack dandclark
16:05:58 <masonf> ack justin
16:06:01 <bkardell_> present+
16:06:05 <dandclark> justinf: Editors can update to do syntax highlighting for this
16:06:44 <justinf> https://github.com/whatwg/html/issues/7367
16:06:48 <dandclark> 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.
16:06:48 <obuckley> 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 :)
16:07:14 <dandclark> ...: 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.
16:07:40 <michael_warren> q+
16:08:14 <dandclark> ...: 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?
16:08:48 <michael_warren> q-
16:08:48 <masonf> q- mason
16:08:54 <dandclark> kurt: Yes we need to think about these
16:09:03 <dandclark> justinf: Neeed to think about how this works with import maps
16:09:31 <dandclark> ...: Also includes integrity. Can think about these inline scripts telling browser something about module and also populating module map
16:09:46 <dandclark> ...: Can say this pattern for these types of paths are going to be inline.
16:10:00 <masonf> ack westbrook
16:10:42 <dandclark> 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.
16:11:16 <kbabbitt> 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...
16:11:31 <dandclark> kurt: Seems workable, not sure what haappens today. Good question.
16:11:54 <justinf> there's a similar question + answer for HTML modules
16:12:00 <masonf> ack emilio
16:12:04 <dandclark> ...: May or may not be issue, but it should be solvable
16:12:38 <michael_warren> q+
16:12:46 <justinf> <style> is the default solution for Lit SSR now
16:12:52 <dandclark> 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?
16:12:53 <justinf> it bloats the payload hugely
16:13:10 <justinf> gzip helps a lot, but there's still parsing time
16:13:28 <justinf> ah, thanks
16:13:36 <dandclark> kurt: I should have listed that. The engines will optimize.
16:13:48 <dandclark> masonf: Doesn't play well with adoptedStylesheets, they're copy on write
16:14:07 <dandclark> emilio: Generally the CSSWG has been against mutating CSSOM stuff. But yes, the semantics may not be what you want
16:14:19 <dandclark> justinf: You have to duplicate styles in your payload
16:14:40 <kbabbitt> dandclark: that's similar to feedback we've gotten from developers internally ,want to avoid duplication of DOM & stylesheets
16:15:01 <dandclark> emilio: Don't you have the declarative duplication in the DOM?
16:15:08 <dandclark> justinf: You want to be able to remove that
16:15:56 <jyasskin> dandclark: And this proposal could generalize to deduplicating HTML structure.
16:16:22 <jyasskin> bkardell_: That's an argument to use <template>.
16:16:24 <justinf> <script ype="html">
16:16:59 <jyasskin> ryosuke: <Script> won't run either, but it can't be nested.
16:17:21 <dandclark> masonf: I am sympathetic to emilio's point. But in the DOM repeatd compoents are repeated, that's not necessarily the case for CSS
16:17:28 <dandclark> emilio: Not sure I get that.
16:17:42 <dandclark> masonf: Issue is people think why is it repeated, it shouldn't have to be
16:17:53 <dandclark> ...: If you have 3 components there are 3 in dom by definiiton
16:18:10 <masonf> q?
16:18:24 <dandclark> emilio: Before, people would innerHTML the whole tree. Not trying to say stop, just curious. Seemed like an omission
16:18:33 <masonf> ack keith
16:18:34 <dandclark> kurt: Yes we should have included this
16:18:46 <dandclark> kcirkel: This doesn't include images?
16:18:49 <dandclark> kurt: Not yet
16:18:56 <kbabbitt> s/kcirkel/keithamus/
16:18:57 <dandclark> ...: But this could set up for that
16:19:18 <dandclark> keithamus: I'm concerned about timing of when these get declared.
16:20:24 <dandclark> ...: 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?
16:20:29 <dandclark> kurt: Yes we need to explore this.
16:20:53 <justinf> qq+ WASM modules too
16:21:08 <dandclark> keithamus: Need to think through story of HTML module. Given that closing script tag is big footgun. Maybe <template> be better. Can you have nested templates?
16:21:10 <jyasskin> qq+ justinf
16:21:14 <dandclark> rniwa: yes
16:21:29 <justinf> 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?
16:21:39 <dandclark> keithamus: I can see you wanting to have script tag in HTML module. Not allowed in script, but <template> allows matching
16:21:48 <dandclark> rniwa: How does it work with prefetch?
16:21:51 <sanketj> q?
16:22:02 <masonf> ack michael
16:22:22 <masonf> q+ rniwa
16:22:40 <justinf> ah
16:23:15 <justinf> qq+ specifiers
16:23:24 <keithamus> ack specifiers
16:23:25 <Zakim> specifiers, you wanted to react to michael_warren
16:23:26 <justinf> argh, I'm terrible at this
16:23:27 <rniwa> rniwa has joined #share-styles
16:23:34 <dandclark> 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?
16:23:34 <keithamus> q+ justinf to talk about specifiers
16:24:21 <dandclark> q++ to talk about specifiers, collisions
16:24:36 <rniwa> q?
16:24:51 <masonf> ack justin
16:24:51 <Zakim> justinf, you wanted to react to keithamus and to talk about specifiers
16:25:01 <masonf> q+ dandclark
16:25:03 <masonf> ack +
16:25:03 <Zakim> +, you wanted to talk about specifiers, collisions
16:26:24 <jyasskin> Dynamic import maps (https://github.com/whatwg/html/pull/10528) look related to the way this proposal extends the module map.
16:26:25 <dandclark> 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.
16:26:30 <dandclark> kurt: that was xid?
16:26:32 <dandclark> justinf: yes
16:26:34 <masonf> ack rniwa
16:26:54 <michael_warren> would this solution also deal with styles/modules added dynamically? particularly in the imperative case?
16:27:14 <dandclark> rniwa: Earlier point about prefetch -- if we do this in declarative, there will be delay between when sheet appears and browser fetches subresources.
16:27:30 <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
16:27:36 <dandclark> ...: Need to solve how we'll get subresources in time
16:27:38 <masonf> ack dand
16:27:46 <justinf> the sub-resource problem isn't any worse than the existing solutions, yeah?
16:28:00 <justinf> <style>...</style> already has this?
16:28:01 <masonf> dandclark: on the prefetch thing, you can do module preload for external resources. You can inline the rest. We should talk more.
16:28:39 <masonf> 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?
16:28:47 <masonf> q?
16:28:57 <westbrook> How can we support on going research?
16:29:04 <justinf> @import should be banned
16:29:14 <justinf> it's banned in constructible stylesheets
16:29:25 <masonf> dandclark: about @import, not sure about this. We haven't solved this anyway, so we need to figure it out.
16:29:48 <masonf> dandclark: we do the same thing we do today, which is failing the import. Or whatever we do.
16:29:53 <masonf> q?
16:30:37 <dandclark> kurt: Please attend CSS modules session later today. Hopefully we agree this is the solution to pursue. Please raise issues.
16:53:26 <robglidden7> robglidden7 has joined #share-styles
18:01:01 <kizu> kizu has left #share-styles
20:25:43 <sabidussi_marco> sabidussi_marco has joined #share-styles
23:07:41 <jyasskin> jyasskin has left #share-styles