Re: [shadow-styling] alternative idea.

On Mon, Feb 10, 2014 at 2:18 PM, Andrew Fedoniouk
<news@terrainformatica.com> wrote:
> On Mon, Feb 10, 2014 at 10:52 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Sun, Feb 9, 2014 at 7:09 PM, Andrew Fedoniouk
>> <news@terrainformatica.com> wrote:
>>> 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.
>>
>> As further justification for rejecting this, the WG as a whole has
>> moved away from using at-rules as a selector context-switcher.
>> @region was an early attempt at this as well, and we decided not to do
>> it.
>
> I am not sure I understand how "using at-rules as a selector context-switcher"
> is applicable in this case. I do not see any switch there.

You use one selector in the at-rule prelude, "dropdown-select".  This
establishes a new context which you evaluate the contained selectors
in, rather than evaluating them against the document like normal.

> Let's imagine that
>
> <select size=1><option>1</option>..</select>
>
> is using this template under the hood:
>
> <template id="dropdown-select">
>   <caption>current value</caption>
>   <button>show popup</button>
>   <popup-list>
>      <content><!-- <option>s will go here --></content>
>   </popup-list>
> </template>
>
> Then by saying
>
>    select[size=1] { shadow: my-theme-dropdown-select; }
>
> I'll be able to redefine its style as a whole.
> And by defining this:
>
>    select[size=1] { shadow: intrinsic; }
>
> I am switching the select back to UA's intrinsic styling.
>
> Ideally shadow styling solution shall allow to style as
> intrinsic input elements as custom components.

You're imagining something like Decorators (shadow trees that can be
added or removed by CSS or other "transient" mechanisms), which we're
explicitly not handling yet.  Right now, shadow trees are attached
permanently via JS APIs (or, after a JS API registers things
appropriately, attached by the parser itself).

>>>> 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.
>>
>> Yes, many/most uses of Shadow DOM are within the context of Web
>> Components, or custom libraries doing similar things.
>>
>>> 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.
>>
>> Not at all.  It absolutely makes sense to update small bits of a
>> component rather than all of them at once.
>
> Let's imagine that your component has <button> in shadow.
> In general you cannot update just its color for example.
> You will need to redefine its background too. And
> do it for all its states. In practice (see bootstrap styles for
> example) you will end up with redefining whole set.
>
> Component by its UI sense is a system of tightly
> bound parts that usually shall not be styled independently.
>
> In fact we should answer on the question: whom this
> shadow feature is primarily for?
>
> My perception is that it is mostly for professionals
> who do component sets/frameworks. For them
> ability to redefine their carefully crafted styles by
> normal document rules is far from being beneficial.

It's for lots of people, from component library authors to individual
page authors who just want to organize their pages a little better.

The component library team we have on staff has discovered that it
makes tons of sense to do tweaks to styles of things in shadow trees,
so trying to differentiate this feature based on audience doesn't give
you much.

>>> 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.
>>
>> Shadow DOM specificity is similar to how scoped style specificity works.
>
> I think that statement of yours means the following: create anonymous
> style set that contains all shadow rules for the element and apply
> it as a whole after all non-shadow rules.
>
> Is this close to what you have in mind?

I meant what I said - go look at how scoped rules work in Cascade:
<http://dev.w3.org/csswg/css-cascade/#cascade-scope>

Shadow trees work similarly.  (It's not exactly identical, but very close.)

> If "yes" then it is exactly what style-sets are about.
>
> But instead of spreading shadow rules across multiple
> CSS sources the style-set (@set) mandates all such
> rules to be defined in single @set block (and its ancestors, if any).
> So component author will always know that this particular
> combination of styles in his/her @set will be applied as a whole.

That's not at all how shadow tree styling works, or is intended to work.

>>> 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 }
>>> ...
>>
>> I have no idea what these mean.  Are you using some weird custom
>> syntax?  Is "->" supposed to mean "/shadow-all" or something?
>
> Yes, I am using '->' here as a short form /shadow-all or '^^' or whatever.
>
> So read it as:
> body[theme=blue] input[type=date] /shadow-all table td.today { background:blue }

Okay, then yes, rules like that might appear in the future.  What of it?

~TJ

Received on Monday, 10 February 2014 22:48:42 UTC