Join GitHub today
[Shadow]: Consider a notion of shared stylesheet (bugzilla: 15818) #99
Title: [Shadow]: Consider a notion of shared stylesheet (bugzilla: 15818)
Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15818
Having scoped styles is cool, but having a designated stylesheet that's shared among a set of shadow DOM subtrees has more potential for better performance and ease of use.
There's a similar problem when using shadow DOM to implement widgets--the shadow DOM of all instances of the widget need to be populated with a copy of the same DOM structure.
So it seems like there is overlap: Implementations could implement a lightweight copy-on-write clone of <style scoped> and handle the styling with the cloning of the rest of the widget DOM.
The benefit of the shared stylesheet would be that it would be possible to share a stylesheet for different kinds of widgets (buttons and sliders, etc.)
Would it be crazy to make style resolution for shadow DOM follow where these DOMs were defined? e.g. in the case of some future "custom element" spec:
Here's what I am thinking.
At Shadow DOM spec level, we add a new, simple API to add a stylesheet to ShadowRoot. This stylesheet will be explicitly read-only (no CSSOM):
Maybe it's a Map of some read-only CSSStyleSheet objects?
This will allow authors pretty nice level of control over shared stylesheets.
At the Custom Element spec level, we will need to come up with some sort of syntax to specify these shared stylesheets as URLs. Maybe:
or something along the lines of Dominic's idea.
Travis, Tony, Anne (as the former CSSOM editor) -- what do you think?
(Replying for Tony as he just had a new baby :)
I think this is definately a step in the right direction as compared with <style scoped>.
It gives the component author a chance to exclusively share stylesheet objects, which is great, and the implementation a chance to optimize around that shared instance (rather than having multiple copies of a scoped stylesheet hanging around).
There may be some room to further refine this, but as mentioned, this is definately a step up.
I decided to punt this to post-first WD.
I'd prefer to keep the read-write nature of the CSS OM here if we can. That way a component author can apply tweaks to the core stylesheet dynamically which affect all shadow DOM subtrees referencing that stylesheet.
Also rather than passing an URL, what about passing a reference to an actual or <style> element? This aligns more closely with the proposal for custom elements while providing a bit more flexibility for dynamic generation (e.g. if a framework wanted to inline all CSS as part of their JS file, then build out a <style> element at runtime).
(In reply to comment #5)
Yes, I am leaning toward this as well.
Ok, what do you think? http://dvcs.w3.org/hg/webcomponents/rev/1456fe73dfb0
Please reopen if you feel the API is bad or file new bugs to tweak it.
Reopening this bug because the proposed edit to the spec to contain addStyleSheet is not currently in the spec.
What happened to it? Was it abandoned in favor of another idea?
They were removed in bug 21923. Do we need them?
I think there are 2 issues here that still need consideration. Perhaps we need a separate bug for the second one?
(In reply to comment #11)
Also adding wchen, mrbkap, who are working on this at Mozilla.
Bug for loading stylesheets via link rel="stylesheet":
Closing, given that we have http://tabatkins.github.io/specs/construct-stylesheets/.