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

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.

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

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

~TJ

Received on Wednesday, 5 February 2014 02:48:36 UTC