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

A few points of feedback about the last few messages:

   1. While the encapsulation of the JS DOM side of the Shadow spec is not
   frozen, it has a ton of steam behind it and I feel like the right level of
   encapsulation. That's not to say the goal of stronger 'Types' of
   encapsulation (in the Maciej sense) are undesirable or something we
   shouldn't introduce later. There doesn't seem to be a blocking technical
   issue with adding provisions for stronger encapsulation in the future - is
   that accurate?
   2. I want to second what James Ross mentioned, something the folks who
   attended our meeting also hit on: a component author can still use classes
   and attributes to mark special elements within their component. I
   understand the argument that this does not represent an rigidly enforced
   API contract, but this is exactly how authors of jQuery/Dojo/etc
   plugins/widgets provide user 'APIs' for styling today. Open source
   widget/plugin developers will not have a problem with this, especially
   given the default is to block style leakage from random CSS rules (the
   developer must explicitly, knowingly modify the style of shadowed
   elements). If you scan Github, you'll notice many UI widgets where the
   developer simply explains the classes/attributes to use for styling special
   elements within their component - this is something that is and should be
   solved with a notation in a component's docs, not by taking a billy club to
   the component consumer's explicit style intentions. (heck, even special
   named tokens would require component author documentation to maximize
   consumer uptake)
   3. Closely related to #2: having directly worked on/with current
   plugin/widget libraries and ecosystems, the block-by-default,
   explicit-access model solves the overwhelming majority of issues for
   current plugin developers. IMHO, you will see more issues from enforcing,
   by default, a scheme that requires component authors to expose rigidly
   enforced contracts. The number of times the component author will forget or
   fail to mark the elements inside their component the component consumer
   needs to touch, will far, far outnumber the instances where a rigidly
   enforced API contract saves the day. <-- this is a good example of on-paper
   vs in-practice, we should cater to the 90% case with the least onerous,
   most-generative default, then add provisions for more restrictive
   behavior/contracts in the future.

Thoughts?

- Daniel

On Fri, Feb 7, 2014 at 1: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
>
>
>
>