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

On Tue, Feb 4, 2014 at 8:08 PM, Sylvain Galineau <galineau@adobe.com> wrote:
> On Feb 4, 2014, at 6:47 PM, Tab Atkins Jr. <jackalmage@gmail.com>
>  wrote:
>> On Tue, Feb 4, 2014 at 6:35 PM, Sylvain Galineau <galineau@adobe.com> wrote:
>>> On Feb 4, 2014, at 5:33 PM, Edward O'Connor <eoconnor@apple.com> wrote:
>>>> 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.
>>>
>>> I would add that if Google does believe fast adoption will make some changes effectively impossible then there is no reason to expect ^^/::shadow's default level of access to the shadow tree to be any easier to change later on (defaulting to a loose model and changing to a strict one later is rarely a good time). Fast adoption makes 'fixing it later' way more expensive across the board, not just for syntax.
>>
>> We don't expect to change the default level of encapsulation, but
>> rather to allow components to opt into more restrictive barriers that
>> are harder to pierce.  The reason we're going for an easily-pierceable
>> barrier now is that it gets us out of the way of component authors, so
>> they can do their thing and innovate as they wish first.  Then we can
>> come along later and figure out what more restrictive methods would
>> work well.
>
> The issue is that you're not getting in the way of anyone deliberately hacking into components. Is there data suggesting deliberate styling of custom widgets is scarce?

It's not scarce, but neither is it super-common.  :host()/:ancestor()
let components offer their own themes, which luckily removes a lot of
the need, but there are a signfiicant number of "structural"
components in Polymer, Brick, et al that are intended to be fully
styled by the developer instead.

This is slightly misleading, though.  The major use-case for ^^ is to
style all components of a certain type in the page - you're using a
bunch of Polymer, and you want all the <polymer-button>s to look a
particular way, regardless of whether you put them in your page or
they're embedded deep in some component's shadow.  This *does* happen
a lot in practice, at least in the apps we've looked at, and it's
something that is *not* solved by any other approach so far.

>> If we try to be more restrictive *first*, it's extremely likely that
>> we'll get things wrong, and people will have to hack around our silly
>> limitations to achieve what they want.  I'd rather base the
>> restrictive models on data from actual usage than guesses about what's
>> good enough.  (And internal feedback from the Polymer team on our
>> previous attempts at more restrictive models shows that it's very easy
>> to get it wrong.)
>
> There is some gap between 'we may get it wrong' and 'nothing at all'. I agree there is significant risk in over-thinking it; we can see some of that on this very thread: "An attribute won't do, what if people want to expose most elements in their shadow tree?'. Well, maybe a lowly attribute is a fine escape hatch to start with before moving on to more elaborate solutions derived from real-world feedback?

It's not enough of an escape-hatch, as we've discovered.

A major problem is that ::part is an attractive nuisance.  It *looks*
great; even if you find some problems, it seems like they can be
patched.  However, it almost always only looks that way as long as
you're looking at things a *single* shadow tree deep.  As soon as you
start composing shadows, using components in the shadows of other
components, ::part starts creaking.  Further, components aren't only
used for the "big" things in your page - it can make sense to design
small components that just refactor parts of other components, and are
only ever used locally within that single component.  You quickly
build up way more nested trees than people naively imagine, and
dealing with ::part() and nested stuff and forwarding and all that
other crap suddenly becomes a *major* issue.

We tried it. It doesn't work.  We're not really interested in trying
it again; at least, not as a blocker.  We'd like to get stuff out in
the wild so we can see how people outside of the Polymer dev team
really use components, and *then* design restricted versions based on
that knowledge.

Remember that the status quo is everything mixed together.  We're
already winning a *ton* by setting up the shadow boundaries as they
currently exist.

Remember also that, while the status quo is terrible, it *also* kinda
works.  Not well - we can make the world much better - but it's not a
giant pit of failure either.  You can poke at everything in a jQuery
component, but they still get updated/etc without too much pain.  When
people break, they can choose to deal with it or just use an older
version of the component.  The same applies to Web Components, except
the *accidental* breakage should be effectively nil.

> So while I sympathize with your concern, my fear of picking a default we'll sorely regret later overrides it. I'd rather go the other way and start with full encapsulation; then validate various options to relax the model based on the real-world experience.

We know for a fact that full encapsulation is far too limiting in
practice already.  We tried it for months, then we relaxed it with a
few variants of ::part(), then we relaxed it further with ^ and ^^,
and that was finally enough to do useful work with.

Many cases don't need all that power, and could be served by a less
powerful piercing mechanism.  But *enough* cases need the full power
that it would be harmful to the feature, I believe, to prevent them
from getting it.  Let's do the least magical thing now, and focus on
figuring out more carefully constructed things when we have data.

>>> Choosing the right default here seems a rather fundamental issue that deserves wide consensus before shipping anywhere. I'd love to hear more from Google on how they intend to justify the current default to would-be component developers given that, as Roc pointed out, CSS access to custom components' internals is the default today and the whole point of shadow DOM was to fix that. Is the assumption that 'shadow nodes will never match existing selectors, only new ones with the ^^ combinator' represents 'enough' encapsulation 'for now'?
>>
>> Yes.  This already puts us in a far better position than the jQuery
>> status quo, where it's easy to accidentally spray the internals of a
>> component with your page styles.  It's impossible for the page to
>> touch a component's insides unless the page is doing so *on purpose*.
>> That's already a huge win in terms of compartmentalization.
>
> Fair point; accidental styling is eliminated. And maybe one could say 'well, people who deliberately ^^ into widgets are asking for it'. Except we can't really say that about the default behavior of a feature. So yes, it's a win, and a necessary one. I don't think it's sufficient though.

I kinda addressed this point up above, so I won't repeat myself. Just
didn't want to ignore it entirely.

~TJ

Received on Thursday, 6 February 2014 02:35:42 UTC