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

On Fri, 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:
>
>
> Sure it's a tad long - but you're a champ, you'll deal.
>
> Yesterday a group of folks from this thread convened for a face-to-face
> meeting. I'd like to summarize the discussion, review our options, and
> present why I believe the proposal we zeroed in on during our meeting is
> the correct one:
>
> A little history from the other side of the shadow coin --> the JS DOM. A
> long time ago in a galaxy far away, there was a feeling we should
> security-encapsulate Shadow DOM - it was a noble pursuit, a courageous
> endeavor. After a few cycles with the specs it became imminently clear that
> security-encapsulation of Shadow DOM is fraught with significant problems,
> and the added constraints only made possible a small number of all total
> use-cases. As a result, the decision was made to instead provide a flavor
> of encapsulation that shielded non-explicit Shadow DOM access and style
> overwriting. This form of encapsulation covers the vast majority of
> use-cases - primarily the desire for devs to create custom elements that
> provide a stable interface/render that isn't corrupted by unintended DOM
> manipulation and style leakage. However, an important allowance was the
> ability for component consumers to explicitly access the Shadow DOM via the *shadowRoot
> *property. This provided a way for developers to knowingly, explicitly
> reach into a component and manipulate its DOM - something that is often
> essential for consumers of third-party code.
>
> Why talk about the JavaScript interface portion of Shadow DOM in a debate
> over a style issue? Because new web platform technologies that introduce
> APIs across layers of the stack are usually at their best when they are
> *symmetrical*, *predictable*, and *familiar*.
>
> Let's take a look at the three proposals for styling elements in the
> Shadow DOM --> ::part, cat/hat (^^/^), and an extensible combinator +
> *shadow* token (/shadow)
>
>  *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:
>
>    1. 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.
>

It's not opt-out if you block explicit attempts to style by CSS selector
instead of author-named token. If your point is that it can be opt-out
because we could do both...then...err..agreed? (I don't personally care if
we enable both, as long as we don't block component consumers from
explicitly applying styles to unnamed/tokenized shadowed elements)


>
>    1. 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?
>

::part requires you to understand the whole ::part system, find the token
names, and use the right ones for each component - cat/hat or / +
*shadow *requires
you to know one token that permits explicit access, and from there you need
only open your developer console to find what to style.

>
>    1. 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.
>

That's true, this is precisely what the default barrier requires the
component consumer to explicitly intend to style the shadowed elements of a
thing (this is symmetrically to the JS DOM side - blocked by default, with
a requirement for explicit consumer action to access)

>
>    1. In real world use, shadowed element tokens become numerous,
>    verbose, and crufty.
>
> Citation needed.
>

Not really, take a look a the long list of token names already in-play for
things like form controls. To this you may reply: "Well look, it's working
for those elements, that's a great reason to use them!", to which I will
reply: "Those elements were debated by hundreds (if not thousands) of
people, and the exposed shadowed elements they contained were painstakingly
codified into token names - does anyone honestly believe web-at-large
component authors are going to spend literally *years* to ensure they offer
just the right elements to be styled?"


>
> Assessment: this proposal requires writing selectors that are *not
> familiar*, using tokens that are *unpredictable*, and it is certainly *not
> symmetrical *to the JS DOM encapsulation paradigm.
>
>
> I don't see how this assessment follows from the facts.
>

Using the same CSS selector/rule concepts you're used to (plus 1 combinator
token), is far more *familiar *to current web developers than a rigidly
enforced system featuring a
better-hope-the-author-thought-to-name-it-for-you constraint and a
component-specific named token DSL.

>
>
> *2)** Hats ^, and cats ^^, and bears - oh my!*
>
> Cat-hats are on the right track. This idea turns (correctly) toward a more
> open and permissive model. Moving to a known combinator allows component
> consumers to explicitly, with intention, style anything in the Shadow DOM.
> This means component consumers are no longer left to hope that authors
> provide the styling hooks they need. It also removes the need to litter CSS
> code with shadow element tokens. In addition, component consumers are still
> able to style shadowed elements in a more familiar way. Awesome, problem
> solved!...close, but no cigar. Here's what this option leaves to be desired:
>
>    1. It introduces YAACs (Yet Another ASCII Character) - pretty soon
>    we'll need a periodic table to remember them all
>    2. YAACs are as good as klingon to novice developers - shouldn't we be
>    more obvious if we can?
>
> This also requires educating authors about just what it means to pierce a
> shadow boundary (including what a shadow boundary _is_). This may seem
> familiar and obvious to people who have been living with the internals of
> shadow dom for years, it is something _entirely_ new to the general web
> author who just wants to make part of a widget blue.
>

Sure, but with /shadow, only once. After they know how to access the
shadowed elements, developers will read the docs for the component they are
using (which will tell them about friendly class/attribute-tagged
elements), or simply style shadowed elements in accordance with their
needs. In many cases, the author's class/attribute tagging will be enough,
but for many other component consumers, it won't - let's not tarnish the
latter to polish the former.

>
>
> Assessment: this proposal is pretty darn close - it allows the use of
> *familiar* looking selectors, it's *predictable* once you understand the
> combinator, and *symmetrical* to the JS DOM encapsulation paradigm.
>
> Example: *x-foo ^ div*
>
>
> *3)** /shadow games FTW!*
>
> An extensible combinator is the gift that keeps on giving. With an
> extensible combinator (ex: / + a token) we can define tokens like *shadow*,
> and *shadow-all, *to enable the styling of shadowed elements*.* The best
> part is we can introduce other tokens in the future without YAACing on our
> shoes. This proposal brings with it all the positives that hat-wearing cats
> deliver, without the downside of two new, non-obvious, ASCII combinators
> that are hard-bound to a specific DOM API. The only negative I can think of
> currently:
>
>    1. */shadow *is longer than *^*
>
> Assessment: this proposal hits on all cylinders - it allows users to write
> *familiar* selectors without knowing one-off token names,
>
>
> The internal names and structure of the components are still one-offs,
> aren't they? by definition? I don't see how selecting the internals of
> something just invented can be considered familiar.
>

Technically yes - but under this proposal you need not understand a ::part
system to distinguish which elements you have access to, you need only
inspect the shadowed elements and use 'normal' CSS selectors (with /shadow
in your selector string) to style target elements.

- Daniel