Support fragment references in the <link> tag's href attribute
#11019
Comments
KurtCattiSchmidt
changed the title
sheet attribute to the <link> tag's for CSS @sheet support<link> tag's href attribute
past
added
stage: 1
|
This feature could tie neatly into "declarative adopted stylesheets" (as an alternative to #10673). Since the whole purpose of adopted stylesheets is to reference the original stylesheet instance, it makes sense to me that a Example code using a new <style id="inline_styles">
p { color: blue; }
</style>
<p>Outside Shadow DOM</p>
<template shadowrootmode="open">
- <link rel="stylesheet" href="#inline_styles">
+ <link rel="adopted-stylesheet" href="#inline_styles">
<p>Inside Shadow DOM</p>
</template>(This would prepopulate Keeping in mind that the "constructed" limitation on adopted stylesheets is likely going to be lifted (w3c/csswg-drafts#10013), does this sound feasible? Using adopted stylesheets would be more performant and also avoid some of the harder questions such as "what happens when the original stylesheet contents change?" (changes propagate automatically). This does not yet solve the problem of wanting to "disable" a stylesheet in light DOM, but that's a slightly different use-case, and |
|
Can someone remind me why the I also don't think it's a good idea to mix URLs and same-document references due to base URLs and such. It's rather messy. |
@annevk - do you mean duplicating
I agree that base URL's add some complexity here. This is a great call out. I can think of a few ways to solve this. One option is to use a different attribute than |
@mayank99, this could be another good option. I have a few thoughts here:
|
When would a base element cause a need in the first place to disambiguate an existing URL use case from a (now-unsupported) reference to a document element? <base href="http://a-url/" />
<style id="inline_styles">
/* ... */
</style>
<!-- ... -->
<link rel="stylesheet" href="#inline_styles" />now just produces an error: Refused to apply style from 'http://a-url/#inline_styles'
because its MIME type ('text/html') is not a supported
stylesheet MIME type, and strict MIME checking is enabled.If there is a need to disambiguate an element reference, perhaps a new link type attribute, say like "element"?: <link rel="stylesheet element" href="#inline_styles" /> |
|
I don't think this can work with a new An alternate proposal for this could be to use a new URL scheme, similar to <style id="root-bundle">...</style>
<link rel=stylesheet href="element:root-bundle">
<my-element>
<template shadowrootmode=open>
<style id=inner-theme>...</style>
<link rel=stylesheet="element:/root-bundle">
<!-- or -->
<link rel=stylesheet="element:../root-bundle">
<link rel=stylesheet="element:inner-theme">
</template>
</my-element>Regarding mutability, I think this should work the same way as links and imports today and not change their semantics - once the URL is imported, it's immutable and doesn't track changes. To have an imported thing that tracks changes is something that needs to be done with JS, as it's done today. |
<style id="root-bundle">...</style>
<link rel=stylesheet href="element:root-bundle">
<my-element>
<template shadowrootmode=open>
<style id=inner-theme>...</style>
<link rel=stylesheet="element:/root-bundle">
<!-- or -->
<link rel=stylesheet="element:../root-bundle">
<link rel=stylesheet="element:inner-theme">
</template>
</my-element>I can see how walking up the shadow ancestry to find a style element in a parent shadow (or if not found there, in the light DOM) could be an often-requested capability. Perhaps a CSS inheritance-like walk up the shadow ancestry by identically-named style ids would be simpler and less fragile to changes in the DOM layout: <style id="inline_style">...</style>
<my-container>
<template shadowrootmode=open>
<style id="inline_style">...</style>
<section>
<my-container-item>
<template shadowrootmode=open>
<link rel=stylesheet
href="#inline_style" />
</template>
</my-container-item>
</section>
</template>
</my-container>The first style id of "#inline_style" found walking up the shadow ancestry would be used. This would be analogous to how CSS inheritance works, but would not require the use of a special URL scheme. Alternatively, an even simpler, but less capable, approach would be to look only in the current shadow, and if not found then look in the light DOM. After all, in server-side rendering, it might not be that difficult to emit all shared styles in the light DOM. Any of these ways seem more useful to me than referencing styles in sibling shadows and their parents and ancestors or accessing sheets declared in shadow DOM from light DOM. I assume shadows in slots would "inherit", i.e. look for, style element references in the light DOM (?). |
<style id="root-bundle">...</style> <style id=inner-theme>...</style> I can see how walking up the shadow ancestry to find a style element in a parent shadow (or if not found there, in the light DOM) could be an often-requested capability. This wouldn't solve the problem that the new URL scheme tries to address, as in older browsers it would load the entire document and treat it as the stylesheet. |
|
It might be mixing two features in a way that doesn't quite work, but The bit that this and other proposals miss, is preventing the styles applying in the light DOM. |
<style>
@layer(detached) my-styles {
/* styles */
}
</style>
<my-container>
<template shadowrootmode="open">
<style>@adopt my-styles;</style>
<!-- markup -->
</template>
</my-container>The |
<style> @layer(detached) my-styles { /* styles */ } </style> <style>@adopt my-styles;</style> The `(detached)` part of `@layer` is just something I made up, so it doesn't apply to the light DOM. `@adopt` would attach it. There was a lot of CSSWG discussion about whether |
|
It's sad that |
|
I don't see how this addresses the SSR use case, since it relies on IDs which are scoped. Is there some change to idrefs being proposed too? This is an example of the case that needs addressing: multiple instances of a component sharing a stylesheet emitted by the first instance appearing in the document: <my-element>
<template shadowrootmode="open">
<style id="inline_styles">
p { color: blue; }
</style>
<p>Inside Shadow DOM</p>
</template>
</my-element>
<my-element>
<template shadowrootmode="open">
<link rel="stylesheet" href="#inline_styles">
<p>Inside Shadow DOM</p>
</template>
</my-element> |
|
@mayank99 very good point about potentially populating adopted stylesheets. It would be ideal for us if we could reconstruct the input to our SSR pipeline. Depending on how the author writes the component, they might use adoptedStyleSheets, inline |
|
@justinfagnani Wouldn't the SSR emit the style tag in the light DOM (inside an |
|
@aluhrs13 no, in streaming SSR systems we don't know what elements will be emitted ahead of time, since elements can render conditionally. We emit styles along with the element instances, and the change we want to make is just to not repeat styles after we've emitted them once. Emitting all the styles up front is not feasible. The only way we could emit styles in the top-level light DOM is to emit them at the end of the page, which could lead to a massive FOUC. This is one of the requirements I listed in WICG/webcomponents#939 and I've tried to reiterate this need in every meeting and discussion I've been a part of on this issue. It would be really good to get feedback and validation from the various declarative shadow DOM using SSR system maintainers to see if this proposal would actually solve our use cases. Without cross-scope references to styles, this doesn't for us. Also, would emitting to the light DOM even work? Presumably you mean the top-level document light DOM, not just any outer scope? Are these idrefs special in that they are always scoped to the document scope no matter if they're in a shadow root, or so that they inherit down the tree of scopes? That would be very different from idref resolution today, and I don't see any discussion in the explainer about changes to idref resolution, other than a section that says IDs are still scoped, which would seem to break the entire proposal. |
|
@justinfagnani, @sorvell, re streaming SSR, cross-shadow sharing, and xid:
Agreed. (At least) 3 parallel, overlapping, potentially converging proposals (WICG #939, WhatWG/HTML #10673 and CSSWG #11509 / this proposal as enabling offshoot) have very similar style-sharing goals and all need a purpose-fit scoping mechanism for referencing a source element. Questions:
<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> |
|
@annevk - I wanted to understand your issue regarding
...the Re: @noamr - you might have some context on this issue as well |
However, I think that we can find a solution to these issues, e.g. by one of the following:
Alternatively we can determine that this backwards compat issue is OK and unsupported browsers would try to load a whole document as a style and then fail to apply it. |
|
With Chrome intent to prototype lrlr-polyfill wpt updates the polyfill to correctly handle multiple style rules. lrlr-polyfill-nested-shadows wpt updates the polyfill to handle nested shadows. lrlr-polyfill-find-style-elements-in-shadows wpt updates the polyfill to find style elements both in light DOM and in shadow DOMs, to potentially address if ultimately desireable the streaming ssr use case discussed here. Also, the example streaming-server.js shows using the polyfill in the streaming SSR use case, i.e. in contrast to classic ssr, using HTTP Transfer-Encoding: chunked to streaming-emit shadow components without prior knowledge of the styles to be used in them. |
|
Considering the WHATNOT discussion in #11233 about links to links:
lrlr-polyfill-link-to-link wpt here updates the polyfill to use as a resource a link element in addition to a style element. The benefit of also supporting a link reference to a link element in addition to a style element is that the styles can be loaded from a network resource in addition to a style element, while eliminating the FOUC caused by unspecified and unreliable cache behavior and the duplicated instances that result from multiple link elements all pointing to the same network resource. For example: styles.css: .test-blue {
color: blue;
}lrlr-polyfill-link-to-link.html: <head>
<link rel="stylesheet" href="styles.css" id="style_tag" />
</head>
<body>
<div>
<template shadowrootmode="open">
<link rel="stylesheet" href="#style_tag" />
<span class="test-blue">Blue text</span>
</template>
</div> |
|
The CSS Working Group just discussed The full IRC log of that discussion<dandclark> kurt: Working on getting this to stage 2 in whatwg.<dandclark> ...want to get some of the concerns worked out in joint call <astearns> related: https://github.com//issues/11286 <dandclark> ...Noam filed https://github.com//issues/11286 <dandclark> ...seems like the biggest blocking issue. Seems to have been resolved in thread <dandclark> ...spec already covers it <dandclark> ...are there other concerns? <dandclark> ...before stage 2? <dandclark> annevk: Not sure it's resolved. Haven't seen Olli reply <dandclark> ...I think Domenic thinks current situation is OK. Would be good to discuss with him <dandclark> ...maybe Noam too <dandclark> kurt: Makes sense to set up one-off session with them? <dandclark> annevk: Yes, also good to have Tab, he created the local references thing <dandclark> ...Treating URL starting with `#` differently <dandclark> ...Doesn't have the issue of re-fetching the same document <dandclark> ...Not sure it's actually implemented for CSS <dandclark> ...seems like a useful thing <dandclark> ...It's more intentonal. Very clear that it will always be treated as local reference, not affected by stuff like `<base>` <dandclark> emilio: Gecko imlements local reference concept. I assume other engines do so in a more or less semi-consistent way <dandclark> ...need to handle that kind of stuff for SVG <dandclark> annevk: Do you end up fetching even if URL matches but doesn't start with fragment ID? <dandclark> emilio: Need to double-check that. <dandclark> annevk: I can make test case <dandclark> emilio: Should be easy to test <dandclark> astearns: Having specific session on this with the right people sounds good <dandclark> kurt: I can set up |
|
Re-iterating the first concern here: Doesn't this feature require the shared style to apply to the main document and therefore break Shadow DOM style encapsulation? <style id="x_foo_styles">
p { color: blue; }
</style>
<p>Outside Shadow DOM... should not be blue but is?!?</p>
<x-foo>
<template shadowrootmode="open">
<link rel="stylesheet" href="#x_foo_styles">
<p>Inside Shadow DOM</p>
</template>
</x-foo> |
|
@sorvell - as-is, yes, this feature requires styles to be applied in the main document as well. However, the See @janechu's example in #11019 (comment) for an example of what this would look like. |
|
The idea Justin has proposed is that sheets could be globally referenceable, therefore that problem could be avoided something like this contrived example (which is not doable for aforementioned reasons): <p>Outside Shadow DOM... is not blue</p>
<x-foo>
<template shadowrootmode="open">
<!-- this style gets written on the first occurrence of x-foo during SSR streaming -->
<style id="x_foo_styles">
p { color: blue; }
</style>
<link rel="stylesheet" href="#x_foo_styles">
<p>Inside Shadow DOM is blue</p>
</template>
</x-foo>
<x-foo>
<template shadowrootmode="open">
<!-- SSR streaming does not write the style sheet here on following occurrences. -->
<link rel="stylesheet" href="#x_foo_styles">
<p>Inside Shadow DOM is blue</p>
</template>
</x-foo>But Justin proposed using a new attribute like gid= instead of link href= if the global behavior would be too different for link href. TLDRUnless style link href hash tag will search in ShadowRoots, it is not useful when the styles need to be inside ShadowDOM only, but is only useful when it is ok for the styles to be applied outside of ShadowDOM too. |
|
@smaug---- @tabatkins @noamr @annevk - the discussion from this morning suggested doing a one-off sync with all of us to discuss the remaining issues. Are you all available next week? I realize the time zones will be a challenge, but I am flexible. I'll start with Tuesday, May 20th at 8AM - does that work for everyone? |
|
Why add multiple ways to do things? Why not just go with CSS Modules and specifiers as in In other words, instead of giving end web developers two methods of writing shared styles, why not give them only one? That single method would be the one that cleanly solves streaming SSR at the same time (CSS Modules and specifiers). Just curious why we need anything else more than that. Maybe someone can explain a good reason to do both. Or can we update link href so that it can both:
? This would make it then a target for serializing JS adoptedStyleSheets. It could look something like this: <p>Outside Shadow DOM... is not blue</p>
<x-foo>
<template shadowrootmode="open">
<!-- this style gets written on the first occurrence of x-foo during SSR streaming -->
<style id="x_foo_styles">
p { color: blue; }
</style>
<link rel="stylesheet" href="global:#x_foo_styles" adopted>
<p>Inside Shadow DOM is blue</p>
</template>
</x-foo>
<x-foo>
<template shadowrootmode="open">
<!-- SSR streaming does not write the style sheet here on following occurrences. -->
<link rel="stylesheet" href="global:#x_foo_styles" adopted>
<p>Inside Shadow DOM is blue</p>
</template>
</x-foo>However the ideas proposed in this comment seem much more useful overall: It could solve the needs here and there plus also make other things possible, all via the URL standard (or other types of specifiers if importmaps are involved). |
|
@KurtCattiSchmidt re #11019 (comment)
Ok that would satisfy the need. IMO, that seems a bit convoluted compared to some of the other options. Couple more questions. What happens to <style media="not all" id="x_foo_styles">
p { color: blue; }
</style>
<p>Outside Shadow DOM... should not be blue but is?!?</p>
<x-foo>
<template shadowrootmode="open">
<link rel="stylesheet" href="#x_foo_styles">
<p>Inside Shadow DOM</p>
</template>
</x-foo>Would this change apply and if so how? I believe the style element creates a new stylesheet when this happens. Ideally the adoptedstyle is replaced with it, maybe? x_foo_styles.textContent = `p {color: red;}`; |
There isn't an adopted stylesheet in this scenario, just a regular link/rel-stylesheet element that happens to reference an internal resource. |
But what if there was (using a new |
The question is still relevant in that case. What happens when the referenced style's sheet changes or is replaced? |
Of course, I very much advocate for a way to serialize and deserialize This goes back to the original requirements I listed in WICG/webcomponents#939.
|
|
@sorvell raised an excellent point that I wanted to address:
This is probably the most significant open question in the explainer, and I would definitely appreciate some discussion. As I see it, here are the pros/cons of reference vs copy: Copy
Cons
Reference
Cons
|
|
Concerning this con:
I don't think I understand this exactly. Do you mean:
As to 1), isn't that just how Javascript works? You can always reach outside the host's shadow tree. If 2) I'd say yes, the changes should be reflected in all the Even though, as discussed here at least as to CSS import, "When the same style sheet is imported or linked to a document in multiple places, user agents must process (or act as though they do) each link as though the link were to an independent style sheet". To me, that logic doesn't seem to apply to a source As to 3), how would that work? Isn't the sheet property on I'd note that xlink:href, the original inspiration of |
If the sheet is shared, then the link inside the shadowRoot's |
This is how constructible stylesheets work, but not how I think this feature makes more sense if we stop thinking about it as a way to share stylesheets between declarative shadow roots for SSR, since it does not work for serializing |
To me, this suggests this feature may be the wrong solution for the stated problem. In It seems like we should endeavor to create a declarative mechanism for using that system. This helps give context for how to solve problems specific to the solution such that they support and mirror the imperative system. Instead, we're designing a new system with similar, in spirit, capabilities. It has its own unique set of issues and problems, this one possibly thorniest among them. It's a more general system and therefore might warrant new semantics. But, afaict, no one is asking for anything more general than satisfying the declarative Shadow DOM use case. This said, WICG/webcomponents#939 is perhaps a better starting point? |
Yes, this is exactly the concern I was referring to. @robglidden - some responses:
|
I guess I was not clear. What I do not understand is why is this (conceivably allowing 2 ways to reach the
Sure, I think my comment assumed that could be an intuitive way for link.sheet to work when pointing to an singleton internal reference rather than an instanced network reference, but why would this be a negative.
Using a
Sure, as a general computing principle, a pointer is different from the thing pointed to. But no, that is not how SVG
But that adoptStyles approach would apparently also allow 2 ways to reach the Perhaps a 939 explainer would help, fleshing out how |
|
@justinfagnani / @sorvell - I'm sending you an email right now to try to find time to make sure that we understand your concerns here. In the meantime - Can we keep this thread focused on additions or changes the proposal at hand, and keep the CSS modules conversations on the threads about it? If someone wants to pursue that while we look down this path, I'm happy to help where I can. |
Uh oh!
There was an error while loading. Please reload this page.
What is the issue with the HTML Standard?
The problem
There are currently several options for sharing styles with Declarative Shadow DOM, but all of them rely on external files or dataURI's:
<link rel="stylesheet" href="foo.css">this requires an external file.<link rel="stylesheet" href="data:text/css;...">this is not technically an inline style definition, but it doesn't generate a network request, so it's as close as you can get to an inline style today. This must be re-parsed and duplicated in memory for each instance, and the dataURI syntax has poor developer ergonomics.adoptedStyleSheetsvia Javascript - using Javascript somewhat defeats the purpose of Declarative Shadow DOM, and this approach still only supports entire files (or a dataURI).Use cases
@sheet- this will enable CSS@sheetto work with inline CSS. CSS@sheetwill only work in external CSS files unless there's a mechanism for referencing inline style blocks as mentioned in this proposal. For more details (including examples), see this @sheet explainer.Proposed Solution
Allow the
<link>tag'shrefattribute to support same-document references to corresponding fragment identifiers for<style>tags.Prior Art
xlink:hrefsyntax is very similar, although it allows cross-document references. For HTML, this might not be desirable.The text was updated successfully, but these errors were encountered: