Re: [shadow-styling] alternative idea.

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.

>
>>> 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"?
>
> Are you very familiar with Shadow DOM?  If not, go check it out:
> <http://w3c.github.io/webcomponents/explainer/#insertion-points>
>
>> Is it close to
>> select[size=1] { shadow: intrinsic; /*or something like that*/  }
>> ?
>
> No, it's nothing like that, because I have no idea what this is
> supposed to mean. ^_^

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.

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

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

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.

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

--
Andrew Fedoniouk.

http://terrainformatica.com

Received on Monday, 10 February 2014 22:18:45 UTC