Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Declarative CSS Modules - should they initiate a fetch? #10711

Open
KurtCattiSchmidt opened this issue Oct 18, 2024 · 3 comments
Open

Declarative CSS Modules - should they initiate a fetch? #10711

KurtCattiSchmidt opened this issue Oct 18, 2024 · 3 comments

Comments

@KurtCattiSchmidt
Copy link

What is the issue with the HTML Standard?

This topic is for discussion of #10673, which is a Stage 1 proposal.

The current explainer uses URL-like module syntax to define a module identifier. The TPAC breakout session had some discussion around initiating a network fetch for the given module name if one hasn't been defined declaratively.

Specifically, this would mean that specifying the following markup:

<my-element> 
  <template shadowrootmode="open" adoptedstylesheets="/foo.css"> 
    <!-- ... --> 
  </template> 
</my-element>

without an existing definition of foo.css in the module graph would:

  1. Initiate a fetch for foo.css
  2. Validate the MIME type of "foo.css" returned
  3. Upon load complete of the fetch from step 1
    1. Add "foo.css" to the module graph
    2. Parse the content of foo.css as a CSS style sheet
    3. Apply the contents of "foo.css" from the prior step as adoptedStyleSheets in the provided <template> element

This would essentially be a markup-equivalent of https://web.dev/articles/css-module-scripts

Is this something that is desired by developers? If so, there are a number of follow-up issues to clarify, but I want to determine fetching in general makes sense with this feature.

@domenic
Copy link
Member

domenic commented Oct 19, 2024

This seems related to my objections in #10673. Ideally you would not be using the module map infrastructure at all, and instead using pure URLs. Then #fragment URLs could reference inline style sheets identified by id="".

@robglidden
Copy link

Fetching seems to have the benefit that:

<my-element> 
  <template shadowrootmode="open" adoptedstylesheets="/foo.css"> 
    <!-- ... --> 
  </template> 
</my-element>

Would behave like:

<my-element> 
  <template shadowrootmode="open"> 
	<link rel="stylesheet" href="/foo.css" />
    <!-- ... --> 
  </template> 
</my-element>

In that /foo.css would only be network-loaded once, even if referenced in multiple shadow roots (assuming that is how link rel in a declarative shadow DOM always works?).

The difference would be that under the hood the attribute adoptedstylesheets would become adoptedStyleSheets on the shadow root, rather than a link rel.

@robglidden
Copy link

What if we assumed that adoptedstylesheets="/foo.css" was instead a reference to a genuine, regular (CSS) module, and that modules in general were extended to also support inline modules, which I take as potentially implied by this comment?

<my-element> 
  <template shadowrootmode="open" adoptcssmodule="(a module specifier)"> 
    <!-- ... --> 
  </template> 
</my-element>

Then both an inline module and a network-resourced module would be referenceable, by definition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants