Exploration of exposing stylesheets across scopes

[KurtCattiSchmidt]

What is the issue with the HTML Standard?

During the discussion of #11019 at Thursday's sync, it was suggested that we discuss some potential proposals for global ID references and how they might work with this feature. Here are a few starting points. This is intended to be an open discussion, so please feel free to add more ideas!

1. Referencetarget inspired solution on <template>

This proposal would allow for elements to list identifiers that are made accessible to their parent tree scope.

<template exportids="foo"><!-- Exports 'foo' to the light DOM -->
  <template exportids="foo, bar">
    <style id="foo">
     ...
    </style>
  </template>
  <link rel="stylesheet" href="#bar"> <!-- 'bar' is in scope due to `exportids` -->
</template>
<link rel="stylesheet" href="#foo"><!-- 'foo' is in the global scope, reference matched -->
<link rel="stylesheet" href="#bar"><!-- 'bar' is not in scope, reference not matched -->

This works nicely for style sharing, however it doesn't address the streaming SSR scenario where ID's may need to be exported from a deeply nested shadow root. This is because the parent <template> has already been emitted and may not have specified exportid's. This could be addressed with wildcard support on exportid's:

<template exportids="global-*"><!-- Exports any id's beginning with 'global-' to the light DOM -->
  <template exportids="global-*"><!-- Exports any id's beginning with 'global-' to the parent shadow root -->
    <style id="global-foo"><!-- Streaming SSR exports a global id -->
    ...
    </style>
  </template>
  <link rel="stylesheet" href="#global-foo"> <!-- 'global-foo' is in scope due to wildcard `exportids` -->
</template>
<link rel="stylesheet" href="#global-foo"> <!-- 'global-foo' is in scope due to wildcard `exportids` -->

This is my preferred solution because it's not limited to style sharing. I would expect that the exported ID's from shadow roots would work everywhere ID's can be referenced in HTML, including in-page anchor references, <link rel="blocking">, and even SVG xlink:href references.

2. XID (WICG/webcomponents#939 (comment))

This proposal would be a GUID (or MD5 hash) of the style contents. I assume that some sort of prefix before the XID will be required where it's referenced, so as not to collide with existing valid identifiers.

<template shadowroot="open">
  <style type="adopted-css" xid="x61h8cys"> <!-- xid identifiers are global -->
   ...
  </style>
</template>

<template shadowroot="open" adopted-styles="">
  <link rel="stylesheet" href="xid:x61h8cys"> <!-- references global xid -->
</template>

Since this proposal expects a hash, there is a question as to what happens if the referenced object changes (in this case, the shared styles being modified). This could be addressed by either requiring that the styles referenced are static (which differs the conclusion we came to on Thursday about how style sharing should work), or perhaps the hash could dynamically update all existing references if the target is updated.

3. Global prefix on idrefs

The idref definition could be updated to support some sort of special global prefix:

<template>
  <template>
    <style id="foo">
    ...
    </style>
  </template>
  <link rel="stylesheet" href="global:#foo">
</template>

The specific global prefix is open to suggestions. A double-octothorpe (##) could be an intuitive alternative. The definition for identifiers allows for any ASCII character, so any option is a potential compatibility-breaking change: https://dom.spec.whatwg.org/#concept-id

This would work nicely with the style sharing scenario, but I have some concerns from an implementation standpoint. This has additional costs of either 1) doing a traversal of all shadow roots to query the element ID or 2) Always storing elements-by-id twice, once in their own tree scope and again globally, even if global references aren't used anywhere.

[justinfagnani]

Thanks Kurt!

I want to point out what I think is a critical detail: we already have cross-scope style sharing in the form of adoptedStyleSheets. What we're looking for is a way to serialize and deserialize adoptedStyleSheets to and from HTML without JavaScript.

[robglidden]

To me, a key question to answer is how would any algorithm -- 1, 2, 3 or probably any other -- handle duplicate identifiers.

It is hand-wavy to say that duplicate identifiers are just not allowed so it does not matter, because users can still and will still do it. There is no way to stop this. In case of a duplicate identifier, some resolution (or complete failure) must be specified.

For example: what colors "win" below (modify for preferred syntax)? And why?

<style id="shared_styles">
  p { color: red; }
</style>
<my-container>
  <template shadowrootmode="open">
    <style id="shared_styles">
      p { color: blue; }
    </style>
    <my-element>
      <template shadowrootmode="open">
        <style id="shared_styles">
          p { color: green; }
        </style>
        <link rel="stylesheet" href="#shared_styles" >
        <p>what color am I/</p>
      </template>
    </my-element>
    <link rel="stylesheet" href="#shared_styles" >
    <p>what color am I/</p>
  </template>
</my-container>
<link rel="stylesheet" href="#shared_styles" >
<p>what color am I/</p>

One obvious way among others is that first in document order (expanded to include shadow trees) wins. This is the way in essence that HTML and CSS handle duplicate IDs now (within the current document scope and minus shadow trees of course).

Also, I note that some ideas are not polyfillable and only support declarative shadow DOM.

[robglidden]

I would say "red red red" is the best answer above, i.e. first <style id> in tree order expanded to include shadow trees.

Advantages:

• fully supports streaming SSR (HTTP Transfer-Encoding: chunked)
• does not require a UUID or hash (both problematic for several reasons under Web Platform Principles) or a new identifier attribute
• logically extends the long standing "first element, in tree order, within this’s descendants" resolution algorithm
• no backwards compatibility issue, since local references to style elements are now undefined, and this is a different algorithm and element for a different purpose than exisitng id-attribute-using algorithms
• extensible to other element types, like SVG <use href>
• works with "3. Global prefix on idrefs" if is desired to have an opt-in-to-global for either <style>s and/or <link>s in shadow trees (I personally prefer "##" as a global prefix on <link>)
• could also be used to provide a DOM API method to actually globally find the id'ed <style> element (see getElementByGlobalId() below)
• could provide a CSS supports capability if concurrently implemented for SVG <use href>: CSS.supports("clip-path: ##") could return true instead of false as it does now.

3. Global prefix on idrefs ... This would work nicely with the style sharing scenario, but I have some concerns from an implementation standpoint. This has additional costs of either 1) doing a traversal of all shadow roots to query the element ID or 2) Always storing elements-by-id twice, once in their own tree scope and again globally, even if global references aren't used anywhere.

Would recursive traversal into shadow trees really be so additionally costly? Even already and necessarily for regular old light DOM, "[i]n tree order is preorder, depth-first traversal of a tree", so any map optimization still needs to be in tree order.

This polyfill implements a short recursion-wrapped DOM TreeWalker. It extends the algorithm for getElementById(elementId):

"The getElementById(elementId) method steps are to return the first element, in tree order, within this’s descendants, whose ID is elementId; otherwise, if there is no such element, null."

to getElementById(elementId, global = false, elementType = null).

[robglidden]

I want to point out what I think is a critical detail: we already have cross-scope style sharing in the form of adoptedStyleSheets. What we're looking for is a way to serialize and deserialize adoptedStyleSheets to and from HTML without JavaScript.

Adopted or linked, wouldn't first <style id> in tree order expanded to include shadow trees would work equally?

Also a link supports more CSS cascade use cases (adoptedStyleSheets come after).

And link is polyfillable, whereas an adopting attribute on a declarative shadow DOM template is not.