CSS Modules

[rniwa]

Session description

Session to discuss CSS modules and how they work with declarative shadow DOM:
https://github.com/WICG/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md

Session goal

Concrete proposal for CSS Module MVP

Additional session chairs (Optional)

No response

Who can attend

Anyone may attend (Default)

IRC channel (Optional)

#webcomponents

Other sessions where we should avoid scheduling conflicts (Optional)

No response

Instructions for meeting planners (Optional)

No response

Agenda for the meeting.

No response

Links to calendar

• 2024-09-25, 14:45 - 15:45

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.

[ianbjacobs]

Hi @rniwa, thanks for proposing these sessions. There is no need to say "avoid conflicts" with other sessions proposed by the same person. We take that into account automatically. (I will update our template to make that clearer.)

[thescientist13]

Hi @rniwa

Just wanted to get some thoughts on this session's description and goal (I'm part of the WCCG)

Session to discuss CSS modules and how they work with declarative shadow DOM: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md

Concrete proposal for CSS Module MVP

To my knowledge, CSS Module Scripts are already accepted as a web standard, building on top of Import Attributes and already implemented in Chrome, and having positive positions from both Webkit and Firefox.

I was wondering if this session could have two goals?

1. Get implementor consensus on getting CSS Module Scripts (including Import Attributes) to the next available browser's baseline commitment (2025 🤞 )
2. With remaining time, explore the role of CSS Module Scripts in Declarative Shadow DOM (or any other relevant topics)

I think advancing CSS Module Scripts would be an extremely valuable addition to the platform across all browsers, as managing CSS otherwise is often a pain point, often requiring some sort of build tooling to inline CSS into <style> tags within the <template> of the Shadow Root or some other form of scripting to "adopt" <link> tags into the <template>.

With CSS Module Scripts, at least for first party code, developers would have a standards compatible way to not only import CSS into their Web Components, but also to share styles across the Shadow and Light DOM.

I made a little demo repo you can check out if it helps, hosted here, which basically showcases a custom element importing a global "theme.css" in addition to its own component styles, highlighting the style sharing opportunities between light and shadow DOM.

import themeSheet from './theme.css' with { type: 'css' };
import componentSheet from './component.css' with { type: 'css' };

const template = document.createElement('template');

template.innerHTML = `
  <h2>This should be blue and centered (theme.css)</h2>
  <h3>This should be red and centered (component.css)</h3>
`;

export default class SomeComponent extends HTMLElement {

  connectedCallback() {
    if (!this.shadowRoot) {
      this.attachShadow({ mode: 'open' });
      this.shadowRoot.appendChild(template.content.cloneNode(true));
    }

    this.shadowRoot.adoptedStyleSheets = [themeSheet, componentSheet];
  }
}

customElements.define('some-component', SomeComponent);

Hope this can be a consideration for all browser vendors! ✌️

[dandclark]

Expand for the minutes of the Sept 25 TPAC breakout session

rniwa set the topic: "CSS Modules"
2:46 PM
→ kschmi, annevk and alisonmaher joined
2:46 PM
present+
2:46 PM
→ ethanjv and kouhei joined
2:46 PM
rniwa: dan, can you summarize the state of the proposal?
2:46 PM Westbrook Johnson
present+
2:47 PM
q+
2:47 PM
— Zakim sees westbrook on the speaker queue
2:47 PM
dandclark: I can try to summarize the current state after this morning's discussion
2:47 PM
https://github.com/WICG/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md
2:47 PM
dandclark: css modules allow you to import your styles from CSS and then apply them dynamically with adopted stylesheets
2:48 PM
... I can have just one stylesheet and I can apply it to all those different shadow trees
2:48 PM
... that all works quite nicely
2:48 PM
... with declarative shadow dom this isn't the full story
2:48 PM
⇐ Jamie quit (~uid280157@9b5cb9fd.public.cloak) "Connection closed for inactivity"
2:48 PM
... because I don't want to need script to do this
2:48 PM
... we can look at other solutions to apply styles to declarative shadow trees
2:49 PM
... inline styles are not great and duplicate stuff
2:49 PM
... css modules might be the best way of dealing with this
2:49 PM
kschmi: I think something like this (slide 5) is the best way to go
2:49 PM
... we had some discussion about <script> vs.
2:49 PM
... all of them have pros and cons
2:50 PM
... <style> would apply to the light dom which we don't want
2:50 PM
annevk: <style type=module> won't right?
2:50 PM
kschmi: older browsers will apply it
2:50 PM
annevk: they shouldn't right?
2:51 PM
... <style type=module> doesn't style the page now
2:51 PM
kschmi: seems it'd be an option then
2:51 PM
q?
2:51 PM
— Zakim sees westbrook on the speaker queue
2:51 PM
rniwa: <style> seems the more natural thing to do
2:51 PM Alan Stearns
ack westbrook
2:51 PM
— Zakim sees no one on the speaker queue
2:51 PM
q+
2:51 PM
— Zakim sees annevk on the speaker queue
2:51 PM
→ justinf joined (~justinf@9d40a032.publics.cloak)
2:51 PM
... that way we can do for html, <script> for script, and <style> for style
2:51 PM
q+
2:51 PM
— Zakim sees annevk, justinf on the speaker queue
2:52 PM
westbrook: right now import with syntax is blink-only
2:52 PM
... are other browsers opposed to something like that?
2:52 PM
→ hiroshige joined (~hiroshige@9d40a032.publics.cloak)
2:52 PM Owen Buckley
there's an interop proposal for Import attributes (+ CSS / JSON)
2:52 PM
web-platform-tests/interop#733
2:52 PM
ack anne
2:52 PM
— Zakim sees justinf on the speaker queue
2:52 PM
annevk: we do support import with generally
2:52 PM
... might not support css yet
2:52 PM
... wonder if all browsers handle CSP around that correctly
2:53 PM
assert was removed from Chrome
2:53 PM
... there's also the big syntax change from assert to with
2:53 PM
... we're generally supportive
2:53 PM Alan Stearns
"official" support: WebKit/standards-positions#77
2:53 PM
I don't think Chrome has implemented the fetch destination yet
2:53 PM
emilio: for what it's worth, same here. Only blocking thing is time to implement it.
2:53 PM
q?
2:53 PM
— Zakim sees justinf on the speaker queue
2:53 PM
emilio: same, on Mozilla's side, send patches? :)
2:53 PM
annevk: can I ask something else?
2:53 PM
q+
2:53 PM
— Zakim sees justinf on the speaker queue
2:54 PM
... how the specified thing relates to the content
2:54 PM
... specifier=/foo.css in the slide
2:54 PM
kschmi: it's putting it into the module map with that specifier being the key
2:54 PM
... it's effectively an identifier
2:54 PM Sanket Joshi
q+
2:54 PM
— Zakim sees justinf, sanketj on the speaker queue
2:54 PM
ack justin
2:54 PM
— Zakim sees sanketj on the speaker queue
2:54 PM
annevk: does script support that?
2:55 PM
justinf: I think it's a great idea to use the script tag
2:55 PM
... because this approach applies to anything in the module map
2:55 PM
... you want to inline a JS module but still be able to import it from other JS modules
2:56 PM
annevk: would you want it to execute it in today's browsers or not?
2:56 PM
justinf: Maybe we add another type
2:56 PM
... but you might want this for WASM as well right?
2:56 PM
... I think putting this in script is really powerful
2:56 PM
annevk: isn't WASM effectively a byte sequence? How would that work inline?
2:56 PM
justinf: dunno, but we have the module graph
2:57 PM
q?
2:57 PM
— Zakim sees sanketj on the speaker queue
2:57 PM
... if we do it in a way that's potentially compatible with other things in the module graph then it's great
2:57 PM
rniwa: but <script> can't be nested
2:57 PM
justinf: you can escape it right?
2:57 PM
annevk: you can escape the end tag, it's very ugly
2:58 PM
... like if you have a backslash before the closing tag
2:58 PM
q+
2:58 PM
— Zakim sees sanketj, hiroshige on the speaker queue
2:58 PM
https://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cscript%3E%0Aw(%22%3Cscript%3E%3C%5C%2Fscript%3E%22)%0A%3C%2Fscript%3E
2:58 PM
justinf: I think it's potentially very powerful and it works beyond CSS
2:58 PM
ack sanket
2:58 PM
— Zakim sees hiroshige on the speaker queue
2:59 PM
sanketj: two things seems separate: (1) what elements we use. (2) how does the attribute work
2:59 PM
... might be separate discussions, can we scope to one of them?
2:59 PM
ack hiroshige
2:59 PM
— Zakim sees no one on the speaker queue
2:59 PM
hiroshige: same feeling
3:00 PM
... re how it works, module maps are URL-keyed
3:00 PM
... but this is equivalent to specifying the URL
3:00 PM
... anyways I think there's ways of making the things consistently work
3:01 PM
... if we are to specify an URL, it might also be an option given importmap has a similar ability
3:01 PM
q?
3:01 PM
— Zakim sees no one on the speaker queue
3:01 PM
... here we specify the url in the inline script but is similar to intercept the url request
3:01 PM
q+
3:01 PM
— Zakim sees emilio on the speaker queue
3:02 PM
rniwa: so you're seing specifier is like a url, then what
3:02 PM
hiroshige: then it looks like intercepting the request
3:02 PM Westbrook Johnson
q+
3:02 PM
— Zakim sees emilio, westbrook on the speaker queue
3:02 PM
... instead of actually requesting the thing
3:02 PM Sanket Joshi
q+
3:02 PM
— Zakim sees emilio, westbrook, sanketj on the speaker queue
3:02 PM Dan Clark
q+ to talk about multiple imports
3:02 PM
— Zakim sees emilio, westbrook, sanketj, dandclark on the speaker queue
3:03 PM
→ JaseW joined (~uid294981@2bef0590.public.cloak)
3:03 PM
rniwa: so there's a conflict between this and the file that exists (foo.css)
3:03 PM
masonf: there are also timing issues here - if you use the URL/name before it's defined, that could result in a network request.
3:03 PM
In particular if a script does import "/foo.js" as well, what happens? There might be a race.
3:03 PM
the "conflict" is useful
3:04 PM
you want to dedupe between modules that import /foo.css and the inline
3:04 PM
emilio: what if you request foo.css synchronously and you haven't sent the script tag yet.
3:04 PM Jason
present+
3:04 PM
emilio: do JS modules have an answer for that? Or is this new?
3:04 PM
we need to break ties here
3:04 PM
annevk: I think you parse it and insert it in the module map
3:04 PM
emilio: but you might already have started a fetch
3:05 PM
q?
3:05 PM
— Zakim sees emilio, westbrook, sanketj, dandclark on the speaker queue
3:05 PM
dandclark: I think first one should win, and if we parse the inline one after we've tried to fetch we either ignore or fail
3:05 PM
annevk: either override or fail
3:05 PM Steve Orvell
q+
3:05 PM
— Zakim sees emilio, westbrook, sanketj, dandclark, sorvell on the speaker queue
3:05 PM
ack emilio
3:05 PM
— Zakim sees westbrook, sanketj, dandclark, sorvell on the speaker queue
3:05 PM Dan Clark
q-
3:05 PM
— Zakim sees westbrook, sanketj, sorvell on the speaker queue
3:05 PM
dandclark: don't think we want to override
3:05 PM
annevk: override and log to console?
3:06 PM
s/override/bail/
3:06 PM
ack westbrook
3:06 PM
— Zakim sees sanketj, sorvell on the speaker queue
3:06 PM
westbrook: 2 cents re. element names
3:06 PM
... really like the idea of different modules using specific elements
3:06 PM
present+
3:06 PM
... so <script> for script modules, for html, <style> for style
3:06 PM
+1
3:06 PM
... that opens the possibilities to normalize the attributes
3:07 PM
what about resources that don't have tags with them?
3:07 PM
... so type=module on <style> does the same for style as type=module for
3:07 PM

3:07 PM
... it has a ceiling which is where do you put the json module
3:07 PM
a new raw text element?
3:07 PM
... because it fails apart I wonder if it makes sense to use <script>
3:08 PM
ack sanket
3:08 PM
— Zakim sees sorvell on the speaker queue
3:08 PM Dan Clark
q+ To talk about <script> tags and no-JS
3:08 PM
— Zakim sees sorvell, dandclark on the speaker queue
3:08 PM
... but given that falls apart for ...
3:08 PM
I don't think <script> falls apart with
3:08 PM
sanketj: perhaps json and script modules should use <script>?
3:08 PM
... the other thing is that you can reuse the type
3:08 PM
ack sorvell
3:08 PM
— Zakim sees dandclark on the speaker queue
3:08 PM
... attribute
3:09 PM
sorvell: that throws me a little bit because it seems we need a solution for inline modules generally
3:09 PM
... even inline JS modules
3:09 PM
annevk: I think TC39 is working on stuff around that
3:09 PM
q?
3:09 PM
— Zakim sees dandclark on the speaker queue
3:09 PM
justinf: they're working on it with JS syntax
3:09 PM
annevk: but we duplicate it with script type=inline-module
3:10 PM
q?
3:10 PM
— Zakim sees dandclark on the speaker queue
3:10 PM
justinf: I don't think it is a duplicate of the module declaration proposal because that gives you an object, not an specifier
3:10 PM
sorvell: if we have <script> we have inline or out of line
3:10 PM
... but if we use <style>, we'd need for out of line styles
3:11 PM
emilio: you don't need out-of-line modules right? You'd import the url directly
3:12 PM
we want <script> to be able to load non-JS modules, right?
3:12 PM
dandclark: you'll be able to do import "myStyles.css" with { type: "style" }
3:12 PM
isn't that how HTML modules are supposed to work?
3:12 PM
annevk: what if you just have the <template> thing?
3:12 PM

<script type="html" src="/foo.html"></script>

3:12 PM
dandclark: we'd make the template either trigger the fetch
3:12 PM
... leaning not to do that
3:12 PM Alan Stearns
s/"style"/"css"/
3:13 PM
... I think it's clearer if the template attribute just pulls from the module map
3:13 PM
+1 to masonf
3:14 PM
q?
3:14 PM
— Zakim sees dandclark on the speaker queue
3:14 PM
q+ westbrook
3:14 PM
— Zakim sees dandclark, westbrook on the speaker queue
3:14 PM
q+
3:14 PM
— Zakim sees dandclark, westbrook, hiroshige on the speaker queue
3:14 PM
q+
3:14 PM
masonf: There are two different things, <script> adds to the module map, and template pulls from it or fetches
3:14 PM
— Zakim sees dandclark, westbrook, hiroshige, justinf on the speaker queue
3:14 PM
westbrook I added you to the queue
3:14 PM
emilio: why would you fetch instead of using <link>?
3:14 PM
westbrook: <link> doesn't add to the module map
3:14 PM
masonf: less typing too?
3:14 PM
ack dandclark
3:14 PM Bridge daemon
dandclark, you wanted to talk about <script> tags and no-JS
3:14 PM
— Zakim sees westbrook, hiroshige, justinf on the speaker queue
3:14 PM

dandclark: I agree these are two separate features
3:15 PM
... we can probably do <template adoptedstylesheets> consume from the module map
3:15 PM
... then figure out if that should do the fetch and add to the module map
3:15 PM
... we need to give it some thought
3:15 PM
q+
3:15 PM
— Zakim sees westbrook, hiroshige, justinf, emilio on the speaker queue
3:15 PM Steve Orvell
q+
3:15 PM
— Zakim sees westbrook, hiroshige, justinf, emilio, sorvell on the speaker queue
3:15 PM
q+
3:15 PM
q+
3:15 PM
— Zakim sees westbrook, hiroshige, justinf, emilio, sorvell, rniwa on the speaker queue
3:15 PM
— Zakim sees westbrook, hiroshige, justinf, emilio, sorvell, rniwa, kouhei on the speaker queue
3:15 PM
... feedback would be great
3:15 PM
ack westbrook
3:15 PM
— Zakim sees hiroshige, justinf, emilio, sorvell, rniwa, kouhei on the speaker queue
3:16 PM
westbrook: I really like the idea that adoptedstylesheets is the declarative syntax with import with type=css and then can be brought to have inline module declarations
3:16 PM
... I think that's valuable as a developer
3:16 PM
q-
3:16 PM
— Zakim sees justinf, emilio, sorvell, rniwa, kouhei on the speaker queue
3:16 PM
... not so much about <link>, links are not for styling custom elements
3:16 PM
emilio: you can
3:17 PM Alan Stearns
(disagreements on current reality)
3:17 PM
FYI as for how to name/import inline modules: previous discussions at whatwg/html#7367 whatwg/html#7415
3:18 PM Dan Clark
emilio: What's the difference between this and between requesting a URL in the module map?
3:18 PM Alan Stearns
s/in the module/not in the module/
3:18 PM
ack justin
3:18 PM
— Zakim sees emilio, sorvell, rniwa, kouhei on the speaker queue
3:18 PM
— astearns (I think)
3:18 PM
masonf: we're debating the less useful part of this proposal
3:18 PM
justinf: I want to reiterate that a huge part of the value is using the module map
3:18 PM
... we have CSS modules on the module graph
3:19 PM
... being able to deduplicate the styles via the module graph is a critical
3:19 PM
→ nidhi4 joined (~nidhi@9d40a032.publics.cloak)
3:20 PM Dan Clark
emilio: I agree with that, but what I was discussing was the difference between if foo.css is not in the module graph -- We were discussing whether this attribute could trigger a fetch. I don't think we want that. If you say adoptedstylesheets=foo.css triggers the fetch, isn't the behavior we have now with ?
3:20 PM
justinf: But doesn't put them in the module graph
3:20 PM
...We need it to populate the module graph
3:21 PM
q?
3:21 PM
— Zakim sees emilio, sorvell, rniwa, kouhei on the speaker queue
3:21 PM Dan Clark
...Seems OK that having it populate the module graph here is OK.
3:21 PM
annevk: Emilio is talking about the case where the module graph is not already populated
3:22 PM
justinf: It's the same. You can have race conditions
3:22 PM
...See the request before you have the script tag that defines it
3:22 PM
annevk: But then there is something in the module graph
3:22 PM
dandclark: you suspend and wait until the initial fetch comes back
3:23 PM
... you have an empty entry in the module map
3:23 PM
q+
3:23 PM
— Zakim sees emilio, sorvell, rniwa, kouhei, hiroshige on the speaker queue
3:24 PM Dan Clark
emilio: So I'm clear, the only difference between foo.css not being in module map, and whether we trigger fetch or not here. I want to make it clear that if you hit this, assuming we trigger a fetch, the whole point of that is maybe some JS eventually will import this as a CSS module and it's already there.
3:25 PM
...If you use a link the CSS is there in the browser cache but not the module map
3:25 PM
...And if you were to import it, would have 2 sheets technically
3:25 PM
ack emilio
3:25 PM
— Zakim sees sorvell, rniwa, kouhei, hiroshige on the speaker queue
3:25 PM Dan Clark
...Not opposed to triggering fetch but feels like duplicating a lot with link
3:25 PM
q+
3:25 PM
— Zakim sees sorvell, rniwa, kouhei, hiroshige, justinf on the speaker queue
3:25 PM Sanket Joshi
q+
3:25 PM
— Zakim sees sorvell, rniwa, kouhei, hiroshige, justinf, sanketj on the speaker queue
3:26 PM
ack sorvell
3:26 PM
— Zakim sees rniwa, kouhei, hiroshige, justinf, sanketj on the speaker queue
3:26 PM
sorvell: just a point of understanding, is there a difference with <link> with the browser cache? Is that different from the JS module graphi
3:27 PM Dan Clark
emilio: It shouldn't trigger fetch
3:27 PM
emilio: the browser cache exists, but if you disable you most likely don't trigger multiple fetches
3:27 PM
ack rniwa
3:27 PM
— Zakim sees kouhei, hiroshige, justinf, sanketj on the speaker queue
3:27 PM
sorvell: agree this is the less interesting bit but should be supported
3:28 PM
rniwa: I wonder if we could use a # at the beginning
3:28 PM
... so that you'd use specifier="[#foo](https://www.irccloud.com/irc/w3.org/channel/foo)"
3:28 PM
qq+
3:28 PM
— Zakim sees justinf, kouhei, hiroshige, justinf, sanketj on the speaker queue
3:29 PM Dan Clark
emilio: But I thought we were saying that you should be able to trigger a regular fetch if the entry isn't there already.
3:29 PM
q+
3:29 PM
— Zakim sees justinf, kouhei, hiroshige, justinf, sanketj, dandclark on the speaker queue
3:29 PM
justinf: it's a feature, not a bug, that it uses the same url map as js modules
3:29 PM
ack justinf
3:29 PM Bridge daemon
justinf, you wanted to react to rniwa
3:30 PM
— Zakim sees kouhei, hiroshige, justinf, sanketj, dandclark on the speaker queue
3:30 PM
... when we do SSR we want to not pull the css if we've sent it already
3:30 PM
rniwa: wdym with sending the css?
3:30 PM
→ kschmi0 joined (~kschmi@9d40a032.publics.cloak)
3:30 PM
justinf: you have a module map with mixed css and js
3:31 PM
... your server code loads this and tracks the URL and outputs the declarative CSS module using the same specifier as your JS modules use
3:31 PM Westbrook Johnson
q+
3:31 PM
— Zakim sees kouhei, hiroshige, justinf, sanketj, dandclark, westbrook on the speaker queue
3:31 PM
... that way if you send the JS module to the client it's already in the module map
3:31 PM
rniwa: that doesn't affect whether you can use a prefix right?
3:31 PM
justinf: in JS you wouldn't import with a prefix
3:31 PM
annevk: what's the point of the prefix
3:32 PM
rniwa: the point is to avoid the confusion between actual files
3:32 PM
... and the inline things
3:32 PM
importmaps let you use bare specifiers
3:32 PM
q?
3:32 PM
— Zakim sees kouhei, hiroshige, justinf, sanketj, dandclark, westbrook on the speaker queue
3:32 PM
justinf: but it's not a confusion, it's a feature
3:32 PM
FYI as for how to name/import inline modules: previous discussions at whatwg/html#7367 whatwg/html#7415
3:32 PM
dandclark: do we want to allow random module specifiers like external domains or something?
3:32 PM
emilio: should probably be same origin
3:33 PM
JS imports don't have to be same origin
3:33 PM
hiroshige: previously has been proposed to use a : or some other special URL to separate inline modules
3:33 PM
⇐ annevk quit (~annevk@9d40a032.publics.cloak)
3:33 PM
q?
3:33 PM
— Zakim sees kouhei, hiroshige, justinf, sanketj, dandclark, westbrook on the speaker queue
3:33 PM
q-
3:33 PM
— Zakim sees kouhei, justinf, sanketj, dandclark, westbrook on the speaker queue
3:33 PM
ack kouhei
3:33 PM
— Zakim sees justinf, sanketj, dandclark, westbrook on the speaker queue
3:33 PM
rniwa: I see arguments for both, maybe the overriding with the inline thing is an anti-feature and we don't want that
3:34 PM
kouhei: was going to say the same thing
3:34 PM Steve Orvell
q+
3:34 PM
— Zakim sees justinf, sanketj, dandclark, westbrook, sorvell on the speaker queue
3:34 PM
→ annevk joined (~annevk@9d40a032.publics.cloak)
3:34 PM
... we generally don't want to mix inline modules from fetch modules
3:34 PM
ack justin
3:34 PM
— Zakim sees sanketj, dandclark, westbrook, sorvell on the speaker queue
3:34 PM
justinf: in the use cases we have nobody is writing this by hand
3:34 PM
... you have an implementation of web components in js
3:34 PM
... which have css imports
3:34 PM
This seems like it would be the first time we have specifiers in markup, right? It does seem a little confusing.
3:35 PM
... so SSR would use this feature and eventually it will be pulled into the JS
3:36 PM
q+
3:36 PM
— Zakim sees sanketj, dandclark, westbrook, sorvell, rniwa on the speaker queue
3:36 PM
In JS:
3:36 PM

3:36 PM
import styles from './styles.css';
3:36 PM
class MyElement extends HTMLElement {
3:36 PM
q+
3:36 PM
— Zakim sees sanketj, dandclark, westbrook, sorvell, rniwa, kouhei on the speaker queue
3:36 PM
argh... I won't try write code here
3:36 PM
sorvell: So I have an SSRd component and a non-SSRd one you want to use the non-SSRd one independently of whether you've SSRd a component before
3:36 PM
— annevk Note that we only have about 9 minutes left. If there's something else to discuss we better get to it.
3:37 PM
hiroshige: but you could use the prefixed specifier in inline and SSR case if you set up the module map correctly
3:38 PM
... you can set it to look the local specified and then the network, or just inline then fail
3:38 PM
... same specifier can be used anywhere within a document
3:38 PM
zakim, close the queue
3:38 PM Bridge daemon
ok, masonf, the speaker queue is closed
3:38 PM
q?
3:38 PM
— Zakim sees sanketj, dandclark, westbrook, sorvell, rniwa, kouhei on the speaker queue
3:38 PM
ack sanketj
3:38 PM
— Zakim sees dandclark, westbrook, sorvell, rniwa, kouhei on the speaker queue
3:38 PM
— astearns came to see how CSS modules might work with declarative shadow dom, leaving unclear about how anything works
3:38 PM
sanketj: this new specifier (name tbd) is something that we can use to solve declarative modules in general
3:39 PM
... specifier should go in <script> / <style> / , and you could use it to put stuff declaratively in the module map
3:39 PM
... is that correct?
3:39 PM
(yes)
3:39 PM
ack dandclark
3:39 PM
— Zakim sees westbrook, sorvell, rniwa, kouhei on the speaker queue
3:39 PM
ack westbrook
3:39 PM
— Zakim sees sorvell, rniwa, kouhei on the speaker queue
3:40 PM
westbrook: having listened to the questions, could a link tag be aumented to inject the content in the module graph?
3:40 PM Steve Orvell
https://github.com/tc39/proposal-module-declarations specifies module name {...} in JS so this doesn't really work for CSS.
3:40 PM
ack sorvell
3:40 PM
— Zakim sees rniwa, kouhei on the speaker queue
3:40 PM
So here's an example of JS importing CSS: https://lit.dev/playground/#gist=9ffa049eb690b710ba9e39504c07f931 When we SSR that we want to emit the styles as a declarative CSS module, but when we later load the JS, we want that to load the same CSS module instance.
3:40 PM
sorvell: I agree this seems like a general module inlining problem
3:40 PM
ack rniwa
3:40 PM
— Zakim sees kouhei on the speaker queue
3:40 PM Dan Clark
Re: westrbrook, is that ? https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/modulepreload
3:40 PM
... linked above the JS proposal, it's within JS so doesn't work for us
3:41 PM
q?
3:41 PM
— Zakim sees kouhei on the speaker queue
3:41 PM
q+
3:41 PM
— Zakim whispers to justinf that the speaker queue has been closed
3:41 PM
rniwa: the idea that we want to share namespace to solve the general namespace inlining it seems like reinventing importmaps
3:41 PM
ack kouhei
3:41 PM
— Zakim sees no one on the speaker queue
3:41 PM
ack kouhei
3:41 PM
— Zakim sees no one on the speaker queue
3:41 PM
q?
3:41 PM
— Zakim sees no one on the speaker queue
3:41 PM
zakim, open the queue
3:41 PM Bridge daemon
ok, masonf, the speaker queue is open
3:42 PM
justinf: this is similar to import maps in the sense that it can populate the module graph
3:42 PM
... but there's a bit difference because it's also inlining the contents
3:42 PM
... but also it doesn't have to come at the top of the file
3:42 PM
... which is an important use case because you don't know what elements you're going to render
3:43 PM
... so they make them uniquely different from importmaps
3:43 PM
hiroshige: because of that the importmap is has complex implications
3:43 PM
q?
3:43 PM
— Zakim sees no one on the speaker queue
3:43 PM
q+
3:43 PM
— Zakim sees annevk on the speaker queue
3:43 PM
q+
3:43 PM
— Zakim sees annevk, kouhei on the speaker queue
3:43 PM
ack anne
3:43 PM
— Zakim sees kouhei on the speaker queue
3:44 PM
annevk: afaict we don't have any attrs that have module specifiers
3:44 PM Dan Clark
q+
3:44 PM
— Zakim sees kouhei, dandclark on the speaker queue
3:44 PM
... and it's confusing that it looks a lot like a URL but isn't a URL
3:44 PM
as part of the import map proposal, we used to talk about the import: prefix for specifiers in HTML
3:44 PM
... I understand why JS did that but from HTML perspective it's much less clear
3:44 PM
q+
3:44 PM
— Zakim sees kouhei, dandclark, emilio on the speaker queue
3:44 PM
ack kouhei
3:44 PM
— Zakim sees dandclark, emilio on the speaker queue
3:44 PM
... naive assumption would be that you'd just resolve /foo.css and start loading
3:45 PM
so you could do
3:45 PM
kouhei: implementation wise this looks complex
3:45 PM
... specially re. failure cases
3:45 PM
ack dan
3:45 PM
— Zakim sees emilio on the speaker queue
3:45 PM
dandclark: next steps, we have explainers r/n, we want to put it through WHATWG stages
3:46 PM
... trying to get those filed and tag people
3:46 PM
ack emilio
3:46 PM
— Zakim sees no one on the speaker queue
3:46 PM

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ShadowDOM/explainer.md
3:46 PM
ack emilio
3:46 PM
— Zakim sees no one on the speaker queue
3:46 PM
⇐ ethanjv, nidhi4, alisonmaher, kouhei, kschmi, kschmi0, spectranaut_, hiroshige, rniwa, kizu6 and annevk quit ↔ masonf and sorvell nipped out