Re: [shadow-styling] alternative idea.

On Mon, Feb 10, 2014 at 2:47 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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.

Correct, and that's the idea. Shadow DOMs are sort of sub-documents or
sub-trees that are kind of independent from the rest. It is
better to treat them this way if we want to have at least some isolation.

Otherwise I see no point in shadow DOM "problem" at all.

Currently you can declare something like
<x-input type="calendar" />  in your markup.
And populate it from JS and provide styling for inner content.

Current shadow DOM styling solution is not anyhow different
from normal content styling. I can do it right now simply as:

   x-input[type="calendar] > table td.today { background:blue; }

and you propose it to do as

   x-input[type="calendar] ^ table td.today { background:blue; }

these two are conceptually the same in my opinion.

The only principal difference is that some other normal rule:

  table td.today { background:blue; }

will not match accidentally content inside that x-input[type="calendar]

But with current state of affairs that is easily solvable by using
custom elements instead of shadow DOM:

   x-input[type="calendar] > x-table x-td.today { background:blue; }

So is the question: what in principle that shadow DOM is a
solution for? What problems it tries to solve?

If we want to have something simple then I believe it
is enough to add special methods to the script to
populate shadow DOM and say that all elements
added this way will have for example :shadow state flag.
So in CSS you we can use for example this

   x-input[type="calendar] table:shadow td:shadow.today
    { background:blue; }

Shadow elements are only accessible if they
use :shadow pseudo-class. So to treat such elements
as belonging to special :shadow namespace.

I mean shadow elements are not normally visible for
CSS without :shadow "pseudo namespace" specifier.

So it is a matter of adding :shadow pseudo class, right?

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

Ideally shadow DOM solution should cover all shadow incarnations
in the same way. Adding some other mechanism for intrinsic
elements styling will move CSS specs one step closer to
deterministic chaos.


-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Tuesday, 11 February 2014 21:58:09 UTC