Re: [shadow-styling] alternative idea.

On Sun, Feb 9, 2014 at 4:14 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Sat, Feb 8, 2014 at 3:37 PM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>> (as an alternative to this: http://dev.w3.org/csswg/shadow-styling/)
>>
>> Let's imagine that we have @-rule named @shadow that defines block of
>> rules applied to the shadow tree of some element:
>>
>> @shadow dropdown-select {
>
> This was actually the very first thing we tried with Shadow DOM
> styling, at least two years ago.  At-rules seemed like the the most
> natural context-switcher.
>
> It ended up being *super* confusing to actually use, particularly when
> you needed to switch contexts again into the <content>-distributed
> stuff.

Not clear, could you elaborate more on that? What does it mean
"switch contexts again into the <content>-distributed stuff"?

Is it close to
select[size=1] { shadow: intrinsic; /*or something like that*/  }
?

>
> Just using normal selectors ends up working way better; it just makes
> more *sense* to people in practice, we've found.
>

Here are my assumptions I used before implementing style sets :

1. Most of the time shadow DOM styling is about widgets
    like input[various],select,etc.

2. Most of the time set of shadow styles  needs to be applied
    as a whole: either all rules or none of them. E.g. changing
    style of select -> caption without updating select -> button
    does not really work. Those styles are tightly bound.

3. Any form of shadow DOM styling shall not increase
    complexity of overall style resolution.

4. Selector specificity on shadow DOM is different
    from normal flat CSS rule space.

As soon as you will allow shadow dom styling expect
bunch of rules like these:

body[theme=blue] input[type=date] -> table th.weekday { color:blue }
body[theme=blue] input[type=date] -> table td.today { background:blue }
body[theme=blue] input[type=date]:focus -> table td.today { background:red }
...

Such rules are not exposed at the moment (applied natively by UA) but
as soon as we will enable them each, for example bootstrap installation,
will include them for sure. That will create additional load for style resolver.
Some obvious optimization will be to split shadow/normal rules to different
*internal* style sets. But that will be exactly what I've explained -
style sets.

Just for information, here is stylesheet I am using for styling
intrinsic input elements:
http://www.terrainformatica.com/wiki/h-smile/built-in-behaviors/master_style_sheet
That document is quite outdated ( circa 2006 ) but I believe we should expect
something at least not less than that.

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Monday, 10 February 2014 03:10:18 UTC