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 - <script> vs <style> for defining modules #10710

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

Comments

@KurtCattiSchmidt
Copy link

KurtCattiSchmidt commented Oct 18, 2024

What is the issue with the HTML Standard?

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

Our original explainer (MSEdgeExplainers/ShadowDOM/explainer.md at main · MicrosoftEdge/MSEdgeExplainers) uses <script> tags to define Declarative CSS Modules, but consensus seems to be overwhelmingly in favor of using a <style> tag instead.

Specifically, this example:

<script type="css-module" specifier="/foo.css"> 
  #content { 
    color: red; 
  } 
</script>

Would change to this:

<style type="module" specifier="/foo.css"> 
  #content { 
    color: red; 
  } 
</style>

The type="module" attribute is necessary to prevent styles from applying to the main document by default (this was one of the reasons for using the <script> tag initially).

The HTML5 Specification explicitly only allows <script> tags to have a type attribute of either:

  1. No type attribute
  2. type="text/css"

See https://html.spec.whatwg.org/#update-a-style-block - this will need to be amended to include a stage for Declarative CSS Modules.

Pros for the <script> approach

  1. Alignment with HTML modules

Pros for the <style> approach

  1. Developer familiarity
  2. Tooling compatibility (e.g. syntax highlighting)

The TPAC breakout session had quite a bit of discussion on this.

The MSEdgeExplainer's GitHub also had a public comment advocating for <style> over <script> - MicrosoftEdge/MSEdgeExplainers#887 (comment)

My preference is to proceed with updating the explainer to use <style> instead of <script> unless there are any objections.

@Kaiido
Copy link
Member

Kaiido commented Oct 20, 2024

IMHO, the most important point would be which interface proposes the most suited API? Unless it is planned that most of said API would be disabled anyway?

At a glance it seems that indeed <style> and HTMLStyleElement would provide the most sensible API. But if some/all of it is disabled that might actually be even more surprising for authors.
For instance, should disabled and sheet do something? Would modifying the <style>'s textContent reparse and update its stylesheet? Should media work?
Even if I don't know what all the implications would be, as an author I'd certainly expect it to still work.

@robglidden
Copy link

<style> (see) seems to have the advantage that depending on the attribute it could be either:

  1. available to be adopted into a shadow DOM, without also applying to the light DOM, or
  2. available to both a shadow DOM and automatically applied to the light DOM (like a regular style tag).

So <style> (2) would support the use case:

"I just want my page style resets to apply to both the light DOM and to a shadow DOM."

<script> seems like it would support only 1), so for that use case it would require duplicating the style resets twice: once in a <script specifier="/foo.css"> and again in a regular style tag.

@robglidden
Copy link

When I try:

<style id="disabledStyle" disabled>
    body {
        border: 2px dashed green;
    }
</style>

<style id="moduleStyle" type="module">
    body {
        border: 2px dotted red;
    }
</style>

<script id="scriptStyle" type="css-module">
    body {
        border: 2px solid yellow;
    }
</script>

Only <style id="disabledStyle" disabled> has a sheet property, as expected.

Which says to me it might be the better choice for either a source for an inline module or a reference to a globally-id'd style element, because removing the disabled attribute would make it also apply in the light DOM, which would be a use case.

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