Re: [cssom] Make CSSStyleSheet constructable

On Fri, Oct 19, 2012 at 2:01 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 10/19/12 4:50 PM, Dimitri Glazkov wrote:
>>
>> As Tab mentioned, I want (at least I think I do?) to have an explicit
>> indication of whether the stylesheets are shared partly because it
>> allows the script to know if it's a good idea to tweak this stylesheet
>> (which clearly it is not).
>
> If we really want to just have read-only stylesheets, seems like we could
> just do that, with a declarative way to say that they're read-only.  Again,
> that's if we want that.


>
>
>> Another reason to think about this is a low-level hook for the
>> stylesheets, declared for more than one element. In a file that
>> declares multiple components, an external stylesheet is applied to all
>> of the declarations:
>>
>> <link rel="stylesheet" href="x-tags/css/themes/dark-and-stormy-night.css"
>> ...
>> <element name="x-panel" ...
>>      <template ...
>> <element name="x-tabbox" ...
>>   ...
>>
>>  From the perspective of Shadow DOM in each individual component, the
>> "dark-and-stormy-night.css" is something that just magically appears
>> as a member in styleSheets
>> (http://www.w3.org/TR/shadow-dom/#api-shadow-root-style-sheets). That
>> seems sub-optimal, because it's not possible to implement without
>> magic (like, for a browser that only supports Shadow DOM or some
>> alternative implementation that doesn't use custom DOM elements).
>
>
> I'm not sure I follow.  What sort of "magic" are we trying to avoid and why
> is adding new APIs that force script to address a common use case that seems
> like it should be addressable declaratively the way to avoid it?  ;)

Here's a bit more context in the bug:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15818

Adding Tony, since he was one of the peeps who came up with the idea.

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, using
<link rel="components" ...>
(http://www.w3.org/TR/components-intro/#external-custom-elements-and-decorators).
While it looks and is parsed like HTML, it is processed differently
than when loading a typical HTML 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
(http://www.w3.org/TR/shadow-dom/#dfn-shadow-root-style-sheets) for
their respective shadow DOM subtrees -- the stylesheets are scoped to
the subtrees, etc. (see spec for details)

Another way to do this: just add
<link rel="stylesheet"
href="x-tags/css/themes/dark-and-stormy-night.css"> to each component
declaration, but that seems way too verbose.

Also, in the latter case, we should totally employ copy-on-write
semantics for sharing the stylesheet.

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.

Now, while we have a way to specify this shared stylesheet
declaratively, there's no way to accomplish this imperatively.

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.

>
>
>> I am happy to hear any cool/awesome suggestions.
>
>
> I'm still trying to understand the problem(s) we're trying to solve.
>
>
>> I am not sure if this will happen a lot in the wild, but in the very
>> first sample code I wrote for Web Components, I needed tweaking
>> stylesheets to apply styles to the currently selected tab:
>>
>>
>> https://github.com/dglazkov/Web-Components-Polyfill/blob/master/samples/tabs/tabs-component.html#L221
>
>
> Er, I don't follow that at all.  Normally one would have fixed rules and
> then change a class on a node to make it match the rule you want, right?
> Why was that not an option here?

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.

:DG<

>
> -Boris
>

Received on Friday, 19 October 2012 22:06:10 UTC