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

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

From: Daniel Buchner <daniel@mozilla.com>
Date: Fri, 7 Feb 2014 15:39:55 -0800
Message-ID: <CAHZ6zJErurX5Wf5fo=0W2UJ_a=DNwAOKKeFWvOpU_ZV8EkNcnw@mail.gmail.com>
To: "Linss, Peter" <peter.linss@hp.com>
Cc: www-style list <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>
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
Received on Friday, 7 February 2014 23:40:56 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:19 UTC