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

On Fri, Feb 7, 2014 at 3:58 PM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On Feb 7, 2014, at 2:26 PM, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:
>
> > On 2/7/14 5:10 PM, Sylvain Galineau wrote:
> >> Not to belabor the point but I think the pushback reflects some
> members’ belief this should *not* be added later i.e. both Type 1 and Type
> 2 encapsulation should be supported.
> >
> > OK.  Could we please step back for a second and define exactly what Type
> 2 would cover, in terms of CSS?  My understanding of Type 2 is that it
> doesn't try to protect against various convoluted things like redefining
> standard prototype objects or whatnot but tries to protect against exposing
> API to touch the shadow DOM directly, right?
> >
> > If that understanding is correctly, where do we draw the boundary
> between these two?  .shadowRoot seems like Type 2 would rule it out.
> Overriding Node.appendChild with a function that leaks the thisobj and
> argument to the the page seems like something Type 2 is not aiming to
> protect against.  Agreed so far?
>
> Generally yes. (We could have a form of Type 2 that implies a separate
> global object, which would protect against this but not against, for
> instance, calling exposed component methods with maliciously constructed
> arguments, but it's a judgment call whether that is a net benefit in the
> model.)
>
> >
> > It seems to me that querySelector("foo ^ bar") lies somewhere between
> those two extremes.  Would Type 2 rule it out or not?
>
> In my opinion yes, because it's trivially equivalent to .shadowRoot,
> especially if "^" is the only way to achieve styling, so there isn't even a
> convention against breaking the model.
>
> > Actually clearly defining what Type 2 _means_ is a nontrivial exercise.
>  Much more so than Type 1 or Type 4... :(
>
> I agree that defining it is potentially tricky since there are judgment
> calls involved. I expect it would not be very hard to spec and implement
> given a set of decisions about the various access points.
>

It seems the onus is on Type 2 proponents to define and then show demand
for Type 2 vs. Type 1. Daniel seems to be saying that Type 1 solves most of
their needs. That is backed up by the experience of the Polymer team and
our experiences with Dojo and Closure.

Do you agree that a form of Type 2 (or stronger) can be added in v2? If so,
can we agree to move forward with the Type 1 encapsulation that we both
have defined API and customers for?

Regards