Re: Shadow DOM: Hat and Cat -- if that's your real name.

Hi,

I wrote:

> I don't think host documents should be able to select arbitrary
> elements in the shadow DOM. A much better model, which IIRC was in one
> of your documents at one point, is to let the component author
> explicitly export certain shadow elements as pseudos.

I then provided a strawman proposal for one way to do this.

Tab identified three problems:

> For one, it requires explicit annotations on every element you want to
> expose to styling.

That particular strawman does, sure. I'm not wedded to that detail. I'm
sure we could come up with better ways for component authors to
explicitly identify the elements they want to expose.

> If you want to expose all or most of a component's internals, that's
> extremely annoying.

Same point—a more powerful mechanism for explicitly identifying exported
elements could make this easier.

> For two, the pseudo name is roughly a class analogue, and a class by
> itself is too weak of a mechanism for useful styling - you can't, for
> example, style based on an attribute on the element, or on
> :nth-child(), or anything else like that. (It's actually weaker than
> class as originally specified, since you can only provide one name per
> element. But that's obviously a detail that could be tweaked.)

Like Peter said, we could relax restrictions on pseudo-element selectors
in these cases.

> For three, it's only a rough analogue for hat ^, not cat ^^. If you
> only surface the pseudos that the given component defines, you can't
> style anything further down.

Peter covered this too.

> By exposing the structure directly via the shadow combinators, you do
> lose some of the benefits of encapsulation, but the usability wins are
> *enormous* over any other solution we've seen so far.

I don't think the convenience is worth the cost in terms of lost
encapsulation. We should be making a component model that's better,
encapsulation-wise, than what people can do today with things like
jQuery UI.

Peter wrote:

> I'm very much in favor of this approach on a conceptual level at
> least. We can work on the syntax to make it easier to use.

Good to hear. I'm very open to fiddling with the syntax; that was just
an off-the-cuff counterproposal.

> Piercing the shadow dom explicitly is a fundamental violation of the
> encapsulation that it's supposed to be providing. Having some kind of
> model for the component to export it's stylistic structure preserves
> the encapsulation and allows modification or substitution of
> components without breaking the styling (which is supposed to be
> separate to the best extent possible).

Exactly!

> Understood but there are several other ways the "style targets" (for
> want of a better term) within the component could be exposed that
> could reduce the annoyance.

Yes, and the right solution might even be to provide more than one of
them.

> For example, [Peter provides two examples.]

These are both interesting approaches worth investigating further.

> The whole reason that I proposed distinguishing pseudo-elements via
> '::' instead of ':' in the first place was to make it a
> user-extensible space to allow selecting arbitrary non-dom node
> "things" (originally extra CSS boxes but equally applicable to shadow
> dom nodes), let's leverage that.

Yes, let's.

Sylvain wrote:

> Letting anyone trivially select any component internals doesn't sound
> like an encapsulation/usability trade-off. It sounds more like letting
> CSS ignore encapsulation provided the component user is willing to add
> a two-char combinator to their selectors. As a result, if my component
> is successful I may quickly find that any change I make breaks ^^
> selectors all over the place.

Right, the convenience v. encapsulation cost/benefit here is way off.

> As a thought experiment, assume future browsers consider using Shadow
> DOM for built-in controls: is this level of styling access a desirable
> default?

It's not.

Roc wrote:

> An expedient approach would be to allow selectors to penetrate the
> shadow DOM by default[…]
>
> The only argument I can think of against that is that the default is
> "unsafe" for component authors, who will unexpectedly find themselves
> in a deep hole later when they can't change anything their component
> without breaking pages.

I think this is a really compelling argument.

> But that's not too bad; it's certainly no worse than the status quo,
> so at worst it's a missed opportunity.

The whole point of baking a component model into the platform is to do
better than the status quo.

Sylvain wrote:

> To over-simplify what I've heard for brevity:
> 1. The ^^ combinator is way more usable to component users then the
>    ::pseudo syntax…
> 2. Attributes are a sucky way for component authors to declare which
>    nodes are selectable…
> 3. …therefore, let us allow ^^ to select anything in the shadow tree.
>
> I think Tab has made a persuasive argument about 1 and 2; I do not
> think we have established 3. I think we need a better way to address
> #2 for component authors *and* make ^^ only select those nodes the
> component author made public using this improved mechanism.

I think we share the same goal here.

> And yes, they should be allowed to make their entire shadow tree
> public but that seems like a horrible default.

Yup.

Tab strangely made my argument for me:

> Encapsulation by default is absolutely necessary to avoid the pains of
> current jquery/etc components, the avoidance of which is the entire
> point of Shadow DOM.
[…]
> Piercing-by-default would render much of Shadow DOM's reason for
> existing moot.

Sylvain wrote:

> If you want to ship it once, wait for consensus. If you want to ship
> it now, be ready to change it. Trying to cattle-prod some kind of
> consensus with 'speak now or forever hold your peace' language is a
> rather off-putting way to try and make progress.
[…]
> Given f2f feedback and this very thread your expectation that this is
> merely a naming issue seems a little bit premature though
[…]
> Even if there was consensus on how to resolve this - which there does
> not really seem to be - I'm not sure the WG should or even could make
> this kind of commitment to Google at the moment.

Indeed.

Tab wrote:

> Lots of Shadow DOM can be tweaked post-shipping, and likely will for
> some time as we continue to tweak things based on experience in the
> wild and further input from others. CSS syntax probably can't, because
> that's how the world works.

All the more reason to not ship something when there's this level of
disagreement in the WG about what we're trying to do and how to go about
doing it.

Sylvain wrote:

> This thread suggests there is more to it than syntax.

Indeed, this is not bikeshedding. This feature is not a paint job away
from going into the production bike storage business.

> (And for the record I'm fine with ^ and ^^, fwiw; more worried about
> whether/how component authors can choose what ^^ can see).

Yeah. Similarly, I'm less concerned with the specific syntax and more
concerned with the opt-in export default.

Tab wrote:

> We've just figured out that, in the general case, we need full
> shadow-piercing. We'd like to explore more restricted methods of
> piercing that people can opt into in the future.

I think this is backwards. We should start with an opt-in mechanism and
allow authors to opt-in their entire shadow tree if they really want
that.


Ted

Received on Wednesday, 5 February 2014 01:33:12 UTC