MicrosoftEdge / MicrosoftEdge/MSEdgeExplainers

[Declarative Shadow DOM Style Sharing] locator instead of specifier?

Open
#887 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

DeclarativeShadowDOMStyleSharing
Dominant language
HTML
Stars
1.4k
Forks
286
Avg merge
3d 1h
Merged PRs (30d)
8

Description

The proposal uses CSS module specifiers as a mechanism to identify CSS modules which are inlined into the page and which can then be referred to from the adoptedstylesheets attribute. This mechanism only works by using both attributes in combination.

Instead of exporting the module to the page as a CSS module specifier, what if it was exported using a locator (URL)?

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

This would then make this CSS module exist as if it was loaded from the locator (URL). In other words, it inlines a networked resource and announces the inlined resource to the page by its locator. The resource would behave as if it was loaded with a GET with response header Cache-Control: no-store, not affecting the browser's cache, and would only exist for the lifetime of the document. Any reference to that URL would load the CSS module that was provided inline:

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

Benefits:

  • Falls back to fetching the resource from the network in non-supporting browsers, allowing for faster adoption.
  • No need for the adoptedstylesheets attribute, link tags or @import can use this without blocking or FOUC because the resource is immediately available in the page without an additional network request.
  • Can be used anywhere that the stylesheet is referenced, more flexible.
  • Can still be combined with the adoptedstylesheets attribute if desired, or with loading CSS modules in JS.
  • Could develop into a generic mechanism for inlining external resources for other resource types.
  • In supporting browsers a resource does not actually have to be available on that network URL.

Downsides:

  • Larger impact on the page's networking behavior.
  • Harder to polyfill. Basically the only strategy would be a service worker, and this is likely not a perfect polyfill.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the proposal's treatment of CSS module specifiers and the adoptedstylesheets attribute, then compare it with the proposed script type="css-module" locator and link rel="stylesheet" references inside declarative shadow roots. Done means deciding whether locator-based sharing should replace or complement the current mechanism, including its networking, caching, fallback, and lifetime behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
css, html
Domain
frontend, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.