Re: [shadow-styling] alternative idea.

On Sun, Feb 9, 2014 at 9:56 AM, Sylvain Galineau <galineau@adobe.com> wrote:
>
> On Feb 9, 2014, at 9:13 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>
>>> On 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 {
>>>
>>>  :host > caption { ... }
>>>  :host > button { ... }
>>>  :host > popup-list { ... }
>>>  :host > popup-list > option { ... }
>>> ...
>>> }
>>>
>>> where :host is the element it is applied to. Essentially
>>> @shadow {} defines style set of sub-tree that is rooted to the host element.
>>>
>>> To apply that shadow styling to the element we can add something
>>> like 'shadow' property so this:
>>>
>>> select[size=1] {
>>> shadow: dropdown-select; /* name of style set */
>>> }
>>>
>>> will apply @shadow dropdown-select to the shadow three of matching
>>> <select> elements.
>>>
>>> This schema does not require any new entities or syntax constructs:
>>> we have @-rules already, so it is a matter of adding new property.
>>
>> That is actually the syntax I like best, especially if we can have a similar syntax with @region and @page (though I know @page would also require an extra block of braces or something to separate rules from the properties that already can be included directly within @page).
>
> I don't get why the host pseudo is necessary at all. If the rules within @shadow are meant to apply to a shadow tree, then just let :root do the job and map it to the shadow host when defined within @shadow.
>

Yes, :host in not needed, :root can be used instead as host element is
actually the root in this case.

> It also seems very brittle; I'll define my own @shadow rule and apply it using the shadow property only to discover I've overridden an entire other @shadow rule that came with the framework or library I use i.e. through the cascade, the shadow property will cause some surprises.
>

I've solved this by allowing [shadow] style sets to be inheritable  :)
, for example we can use
this notation:

@set dropdown-select { ... }
@set blue-theme-dropdown-select : dropdown-select { ... }
@set red-theme-dropdown-select : dropdown-select { ... }

This way blue-theme-dropdown-select style set includes dropdown-select rules and
ones defined by by blue-theme-dropdown-select by itself. OOP in action
to be short.

I am using[1] standard specificity rules inside that compound style set, and
this works quite well.

----
Slightly off, but while we are on this page...

Style sets can be used not only for shadow tree styling but also for
normal DOM styling:

section#A {  style-set:A;  }  /* rules for #A content */
section#B {  style-set:B;  }  /* rules for #B content */

In this case rules in set A and B have large specificity than normal styles.
So to override rule defined in style set you will need to use !important.

Another point about style-sets for normal DOM styling: they allow
to reduce computational complexity of style assignment:

all rules in style set A, for example, are even considered for the element
E only if it has style-set:A property defined (style-set is an
inheritable property).

This allows to overcome O( elements * rules  ) complexity of
style resolution process for the document.

[1] Sciter engine: http://www.terrainformatica.com/sciter/

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Sunday, 9 February 2014 20:31:22 UTC