shadowrootadoptedstylesheets on <template>#12339
Conversation
|
From an initial look this seems to be on the right track. I need to spend some time on the details though. |
|
Right now all of the |
Note that the current properties of So I think it might be nice to include it in the init dictionary but I could also see why it's not necessary. |
Agreed with @noamr's response here - since there's already an Think of |
emilio
left a comment
emilio
left a comment
There was a problem hiding this comment.
Question, might be me misunderstanding CSS modules, but I'd figure I'd ask...
| </template> | ||
| </div> | ||
| <div id="host_shadowrootadoptedstylesheets_attribute"> | ||
| <template shadowrootmode="open" shadowrootadoptedstylesheets="foo"> |
There was a problem hiding this comment.
So how is this example guaranteed to work? The modulemap uses fetch, right? And that's asynchronous per spec. What guarantees that the data: uri is available by the time the adoption happens?
There was a problem hiding this comment.
From what I read, the modulemap marks the module as "fetching", adopts an empty stylesheet, and calls the equivalent of replaceSync on the adopted empty stylesheet when the stylesheet response arrives.
There was a problem hiding this comment.
Ok, so there is a (very unlikely) chance of FOUC, but no chance of it not working right? Makes sense, might be worth a note?
There was a problem hiding this comment.
Added a note to the example, thanks for looking @emilio!
<p class="note">Note that these two examples are functionally equivalent, but the example with
<span data-x="attr-template-shadowrootadoptedstylesheets">shadowrootadoptedstylesheets</span>
might initially render without styles applied.</p>
…rializable, and failed fetch behavior
|
|
||
| <li> | ||
| <p>Let <var>result</var> be <span>ParseJSONModule</span>(<var>source</var>).</p> | ||
| <p>Run the steps to <span>synchronously replace the rules of a <code>CSSStyleSheet</code></span> | ||
| on <var>sheet</var> given <var>source</var>.</p> | ||
|
|
||
| <p>If this throws an exception, catch it, and set <var>script</var>'s <span |
There was a problem hiding this comment.
Double "and", this is probably better as a set of steps.
| empty, then return.</p></li> | ||
| <li><p>Let <var>adoptedStyleSheets</var> be an empty array.</p></li> | ||
|
|
||
| <li><p>For each <span>ordered set of unique space-separated tokens</span> <var>specifier</var> in |
There was a problem hiding this comment.
I don't understand this line. Is the specifier an ordered set? I think this can just be "For each specifier" maybe?
This change updates the fetch behavior to match whatwg/html#12339. Note that this modifies the code for existing import, import(), and modulepreload for consistency, but the existing behavior for these API's does *not* change in any circumstance. The only observable change is in the shadowrootadoptedstylesheets fetching behavior. By modifying the CSS module fetching to first create the CSSStyleSheet before fetching and calling replaceSync upon completion, we are able to remove the placeholder stylesheets that were being inserted for shadowrootadoptedstylesheets. This simplifies the logic considerably and will be more performant. Unlike the other API's for fetching a CSS Module Script, shadowrootadoptedstylesheets will leave behind an empty CSSStyleSheet in adoptedStyleSheets if the fetch fails. This simplifies the logic and seems like a reasonable trade off for a rare condition. Earlier versions of this CL removed it upon failure, but the implementation was considerably more complex and had other side effects. Change-Id: If00445458983f5062a1ca2d83ed0253cc171d1ff Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7709812 Reviewed-by: Dan Clark <[email protected]> Commit-Queue: Kurt Catti-Schmidt <[email protected]> Cr-Commit-Position: refs/heads/main@{#1629010}
This change updates the fetch behavior to match whatwg/html#12339. Note that this modifies the code for existing import, import(), and modulepreload for consistency, but the existing behavior for these API's does *not* change in any circumstance. The only observable change is in the shadowrootadoptedstylesheets fetching behavior. By modifying the CSS module fetching to first create the CSSStyleSheet before fetching and calling replaceSync upon completion, we are able to remove the placeholder stylesheets that were being inserted for shadowrootadoptedstylesheets. This simplifies the logic considerably and will be more performant. Unlike the other API's for fetching a CSS Module Script, shadowrootadoptedstylesheets will leave behind an empty CSSStyleSheet in adoptedStyleSheets if the fetch fails. This simplifies the logic and seems like a reasonable trade off for a rare condition. Earlier versions of this CL removed it upon failure, but the implementation was considerably more complex and had other side effects. Change-Id: If00445458983f5062a1ca2d83ed0253cc171d1ff Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7709812 Reviewed-by: Dan Clark <[email protected]> Commit-Queue: Kurt Catti-Schmidt <[email protected]> Cr-Commit-Position: refs/heads/main@{#1629010}
This change updates the fetch behavior to match whatwg/html#12339. Note that this modifies the code for existing import, import(), and modulepreload for consistency, but the existing behavior for these API's does *not* change in any circumstance. The only observable change is in the shadowrootadoptedstylesheets fetching behavior. By modifying the CSS module fetching to first create the CSSStyleSheet before fetching and calling replaceSync upon completion, we are able to remove the placeholder stylesheets that were being inserted for shadowrootadoptedstylesheets. This simplifies the logic considerably and will be more performant. Unlike the other API's for fetching a CSS Module Script, shadowrootadoptedstylesheets will leave behind an empty CSSStyleSheet in adoptedStyleSheets if the fetch fails. This simplifies the logic and seems like a reasonable trade off for a rare condition. Earlier versions of this CL removed it upon failure, but the implementation was considerably more complex and had other side effects. Change-Id: If00445458983f5062a1ca2d83ed0253cc171d1ff Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7709812 Reviewed-by: Dan Clark <[email protected]> Commit-Queue: Kurt Catti-Schmidt <[email protected]> Cr-Commit-Position: refs/heads/main@{#1629010}
…a=testonly Automatic update from web-platform-tests [CSS Modules] Update fetching strategy This change updates the fetch behavior to match whatwg/html#12339. Note that this modifies the code for existing import, import(), and modulepreload for consistency, but the existing behavior for these API's does *not* change in any circumstance. The only observable change is in the shadowrootadoptedstylesheets fetching behavior. By modifying the CSS module fetching to first create the CSSStyleSheet before fetching and calling replaceSync upon completion, we are able to remove the placeholder stylesheets that were being inserted for shadowrootadoptedstylesheets. This simplifies the logic considerably and will be more performant. Unlike the other API's for fetching a CSS Module Script, shadowrootadoptedstylesheets will leave behind an empty CSSStyleSheet in adoptedStyleSheets if the fetch fails. This simplifies the logic and seems like a reasonable trade off for a rare condition. Earlier versions of this CL removed it upon failure, but the implementation was considerably more complex and had other side effects. Change-Id: If00445458983f5062a1ca2d83ed0253cc171d1ff Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7709812 Reviewed-by: Dan Clark <[email protected]> Commit-Queue: Kurt Catti-Schmidt <[email protected]> Cr-Commit-Position: refs/heads/main@{#1629010} -- wpt-commits: e564867fbfe3cc70cc8d43ddac392b7b848bc7e4 wpt-pr: 59805
5 participants
Adds support for
shadowrootadoptedstylesheetsonHTMLTemplateElement.<style type="module">support is added in this PR: #11687(See WHATWG Working Mode: Changes for more details.)
Addresses #10673
/indices.html ( diff )
/infrastructure.html ( diff )
/parsing.html ( diff )
/scripting.html ( diff )
/webappapis.html ( diff )