Re: [cssom] Make CSSStyleSheet constructable

On Fri, Oct 19, 2012 at 5:32 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 10/19/12 6:05 PM, Dimitri Glazkov wrote:
>>
>> Let me back up a bit. With Web Components, we want to provide a way to
>> load a whole library of components from a declaration file
>
> ...
>
>> For example, all instances of all declared elements (x-panel,
>> x-tabbox) in the example above get the "dark-and-stormy-night.css"
>> stylesheet as part of the shadow root stylesheets
>
>
> OK, I'm with you so far.  So we want to have a way to link to stylesheets
> from this declaration file and say "this stylesheet applies to all
> components defined in this file".  Which could be as simple as "this <link>
> is in <head>" or whatnot, right?

Yup.

>
>
>> In the former case, the stylesheet has a slightly different meaning.
>> For example, if a script changes the href attribute, it seems logical
>> that all of the stylesheets in all instances of all elements change as
>> well. Similarly, changes to the stylesheet text would be reflected
>> everywhere.
>
>
> OK.
>
>
>> Now, while we have a way to specify this shared stylesheet
>> declaratively, there's no way to accomplish this imperatively.
>
>
> Are you able to run script against the DOM of this declaration file?

Yes. When the script runs during element declaration initialization,
you get the element's instance as "this"
(http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#the-element-element),
so you could presumable walk up to any content in the declaration doc.
Unless of course we prevent it explicitly.

>
>
>> For example, in frameworks where components are dynamically loaded (or
>> generated), their developers will use document.register
>>
>> (http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-document-register)
>> to register them with the document. As such, they would have no way to
>> specify a shared stylesheet. And that seems bad.
>
>
> Ah, so in this case there is no declaration file at all?

Right.

>
>
>> I chose to use rule-twiddling because of encapsulation: the state of
>> the tab manager is stored completely inside of the component. Had I
>> put a class on the tab, I would've leaked that state onto the children
>> of the tab manager.
>
>
> Don't you leak it all anyway once we have the methods to get the set of
> matched CSS rules people keep asking for?

Yes, but at some point the information it has to get there somehow :)
I guess it comes down to where you draw the "model" vs. "view" line.
With rule-twiddling, I was happy that I left DOM (the model) alone and
wasn't worried too much about encapsulation in the view.

>
> -Boris
>

Received on Saturday, 20 October 2012 03:16:50 UTC