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

On Fri, Feb 7, 2014 at 4:07 PM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On Feb 7, 2014, at 12:52 PM, James Ross <james@james-ross.co.uk> wrote:
>
> > From: mjs@apple.com
> > 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 :: hitchjs.com


PS - Sylvan, drink up.