Re: [cssom] Constructable Stylesheets

I didn't really make my mail clear before, the spec mentions the key
'moreStyleSheets' will this be a named key of document.styleSheets, an
indexed key or a totally separate top level key?

document.styleSheets = styleSheets{
1:{}, 2: {}, 3: moreStyleSheets{}};

document.styleSheets = styleSheets{
1:{}, 2: {}, moreStyleSheets: moreStyleSheets{}};

document.moreStyleSheets = moreStyleSheets{}};



On 19 March 2015 at 22:46, Jonathan Kingston <jonathan@jooped.co.uk> wrote:

> 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
>>
>>
>