W3C home > Mailing lists > Public > www-style@w3.org > February 2014

Re: ::Parts of cats and hats everywhere, slashed by shadow

From: James Craig <jcraig@apple.com>
Date: Fri, 28 Feb 2014 00:22:22 -0800
Cc: Daniel Buchner <daniel@mozilla.com>, www-style@w3.org, Tab Atkins <tabatkins@google.com>, Dimitri Glazkov <dglazkov@google.com>, Alex Russell <slightlyoff@google.com>, David Baron <dbaron@mozilla.com>, Potch <potch@mozilla.com>, Angelina Fabbro <angelina@mozilla.com>, Scott Miles <sjmiles@google.com>
Message-id: <81E84457-EE3D-4471-BA56-AB5CD9D7415A@apple.com>
To: "Linss, Peter" <peter.linss@hp.com>
On Feb 7, 2014, at 2:31 PM, Linss, Peter <peter.linss@hp.com> wrote:

> On Feb 7, 2014, at 9:43 AM, Daniel Buchner wrote:
> 
>> 1) We should ::part ways
>> 
>> On its face, the notion of hoisting specific elements into CSS user-space seems like a good idea. You give component developers an explicit API for exposing named pieces of encapsulated shadow elements, and users get meaningful names to use in styling those elements. Unfortunately, this idea introduces a few major issues:
>> 
>> ē The component author is tasked with explicitly marking elements within their component they wish to expose for styling
> 
> This system could just as easily be opt-in vs. opt-out.
> 
>> ē As a component consumer, you must know and use the special name for each element the component author marks
> 
> The component consumer always has to know the names and structure of the internal elements of a component in order to style them, no? What's the difference if those are pseudo-element names or actual element names?
> 
>> ē If the component developer forgets or fails to provide a token for a particular shadowed element, third-party developers are left without any easy path to accomplish their styling goals
> 
> There's also the counter view that a component developer may have a very good reason for _not_ allowing styling of a particular element. And that applying external styles can just as easily break components in any case.

+1 to this counterpoint view and the consideration for component developers to opt-in/opt-out of styling from the shadow root document.

Apologies if this has already been covered in previous discussions, but I didnít find it via searching and as someone pointed out, the previous meeting was by invitation only. Iím curious if anyone has considered limiting the shadow boundary selectors to those explicitly exposed by the component author via ::part(), or otherwise allowing all shadow elements (via the ^/^^ selectors) *only* if the component author does not explicitly expose any part tokens.

Iím not particular to the syntax/attrs/selectors used below. Itís just a straw man to convey the idea if it hasnít been discussed before.

 <x-slider>
   #shadow
     <div class="unselectable"><!-- not selectable from the shadowRoot context --></div>
     <div part="track"></div>
     <div part="thumb" role="slider" tabindex="0" Ö ><span></span></div>
   /#shadow
 </x-slider>

Explicitly allowed styling of ::parts:

 x-slider::part(track) { }
 x-slider::part(thumb) { }

But then disallowing access to say, the elements that werenít explicitly exposed via ::part().

 x-slider ^ .unselectable { /* this block could be ignored if any part tokens were exposed */ }

But it would work if the shadow DOM had no explicit part tokens:

 <x-slider>
   #shadow
     <div class="selectable"><!ó now selectable from the shadowRoot context --></div>
     <div class="track"></div>
     <div class="thumb" role="slider" tabindex="0" Ö ><span></span></div>
   /#shadow
 </x-slider>

 x-slider ^ .selectable { /* cat/hats would work if no ::parts available */ }
Received on Friday, 28 February 2014 08:23:01 UTC

This archive was generated by hypermail 2.3.1 : Friday, 28 February 2014 08:23:01 UTC