- From: Jonathan Kingston <jonathan@jooped.co.uk>
- Date: Thu, 19 Mar 2015 22:46:30 +0000
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: www-style list <www-style@w3.org>
- Message-ID: <CA+EVJMXmyCOhx4NWoRqoz+uN99Hi_gpBVLPJSQ5z_2BaYRTzDw@mail.gmail.com>
When you mention moreStyleSheets that is a list within the normal stylesheet list? So document.styleSheets[document.styleSheets.length -1] would be moreStyleSheets? Or are you thinking once the name has been decided it would be a named key rather than indexed? For me, the most interesting use case here is the "Applying Styles In All Contexts" section. Adding a new origin type makes the most sense to me - especially where you have chosen it in the order. Would it make sense for an author to want something similar to "override" which overrides author origin styles? Much in the same way that not all native page elements can be styled; a company may decide that some of their components are 'final' and be unable to be styled. Perhaps however in this case a component author would just declare the stylesheet with the author origin. Long term I was expecting a similar way to specify essentially a '<link>' element within the component markup rather than injecting '<style>' elements like you mention is an issue. I was thinking this would get around the deduping issue mentioned here and also would fit nicely into the same concept as using http://www.w3.org/TR/web-packaging/ to bundle components. On 18 March 2015 at 22:30, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > Draft spec: http://tabatkins.github.io/specs/construct-stylesheets/ > > When dealing with Shadow DOM-related things, we've found that the > existing ways to style a component are somewhat suboptimal. In > particular, the standard way to style a component is to insert a > <style> element into its shadow tree during initialization. If you > create a bunch of instances of this component, though, that means you > have a bunch of identical <style> elements cluttering up your DOM and > making things more expensive. > > Browsers have deduping heuristics to help this somewhat and avoid > storing duplicate style data, but they're not 100% reliable, and even > if they work, you can't avoid the duplicate *elements* and all their > duplicated text cluttering up the DOM. It would be great if there was > a more explicit way to share styles across instances of a component. > > To address this, I've started a draft spec for adding a constructor to > the CSSStyleSheet interface (linked above), plus an interface for > adding a constructed stylesheet to a TreeScope (a document or shadow > tree). This way, the first instance of the component to be > initialized can create a stylesheet, add it to itself, and then stash > it away someplace later instances can find it. Since they're all using > the same stylesheet, deduping should happen automatically within the > style system, and the text of the stylesheet is only stored once, in > the one instance of the object. > > This also opens up possibilities for more controls on stylesheets. In > the document, I've outlined one such case, where we can solve one of > the "incorrect" uses of >>> (basically, providing "user-agent" level > styles for custom elements) in a more direct and meaningful way. > > Thoughts? > > ~TJ > >
Received on Thursday, 19 March 2015 22:47:01 UTC