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

Brian: Tab talked about providing a /shadow and /shadow-all <-- I believe
this provides the functionality you seek, correct?

- Daniel

On Fri, Feb 7, 2014 at 1:35 PM, Brian Kardell <> wrote:

> On Fri, Feb 7, 2014 at 4:07 PM, Maciej Stachowiak <> wrote:
>> On Feb 7, 2014, at 12:52 PM, James Ross <> wrote:
>> > From:
>> > Date: Fri, 7 Feb 2014 12:16:23 -0800
>> >
>> >> 1) You did not address one of the biggest negatives of both 2 and 3:
>> it locks in the shadow DOM structure of a component as part of the
>> component's API contract, making it impossible to ever change it without
>> breaking compatibility once a component is published. If a component
>> consumer can use arbitrary selector paths into the component, and this is
>> in fact the only API for styling parts of the component that is offered,
>> then it is impossible for even a conscientious component consumer to avoid
>> depending on details of the shadow DOM structure. Can you address this? Are
>> we ok with components being locked into their exact shadow DOM structure
>> forever?
>> >
>> > How about recommending that component authors provide classes on
>> parts/elements they expect (or find from experience) to most commonly need
>> external styling? As far as I can see, it needs nothing beyond the
>> shadow-piercing combinator, and you could do something like:
>> >
>> >    super-control ^ .text-label
>> >
>> > To select a specific part of a component.
>> That would be an improvement over no convention. This is using "^ ." as a
>> rough equivalent to a "::"-based part syntax. However, it still has some
>> disadvantages:
>> - Components may want some elements to have classes for purely internal
>> use of the component. With this approach, you mix your chosen styling hooks
>> with internal-use classes in the same namespace.
>> - It's not design-wise compatible with some components closing down their
>> shadow DOM and exposing *only* named parts.
>> - It's not clear what selectors you can use besides just the named
>> classes, so it's very easy to depend unintentionally on other parts of the
>> structure.
>> However, this brings up another possibility. What if we designated
>> "/token" to be a named part combinator (where "token") can be any string?
>> Then we could have the following:
>> - "/shadow" or "/root" could provide styling access to the full shadow
>> DOM for open components (allowing the possibility that it does not match
>> anything for closed components, once those are supported).
>> - "/whatever" could access a component's named part called "/whatever".
>> We can use one of the many alternatives discussed for exposing an element
>> or subtree of a component as a named part.
>> - Built-in elements with styleable sub-parts could also expose named
>> parts instead of pseudo-elements, thus making them consistent with
>> components and allowing shadow DOM to explain the styleable sub-part aspect
>> of many built-in form controls (currently not standardized but de facto
>> present in most/all browser engines).
>> Regards,
>> Maciej
> In what you propose, would /shadow would work at one level only, or "all
> the way down"?
> Also would /whatever's be exposed via their parents?
> In my document, I'd like to style the exposed x-bar across the site... can
> I? How?  I think somehow we need illustrations of tree constructions and
> selector use cases to explain what we think should be accomplishable.. I'm
> not entirely sure how to do that...
> In other words given some structure like below in which your document
> contains an <x-foo> which exposes an x-bar (I'm using a pipe to
> differentiate something exposed below and parens to indicate something
> hidden, because... how can you draw this in ascii):
> <div>
>     <x-foo>
>         |x-bar|
>             <x-foo>
>                  |x-bar|
>         (x-you-cant-see-me)
>              <x-foo>
>                  |x-bar|
> As an author of CSS, I'd like to style the exposed x-bar across the
> site... can I?
> Can you show some examples of /shadow && /whatever with some kind of
> tree-like explanation to show what they accomplish?
> --
> Brian Kardell :: @briankardell ::
> PS - Sylvan, drink up.

Received on Friday, 7 February 2014 21:43:15 UTC