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

On Feb 7, 2014, at 4:57 PM, Alex Russell <slightlyoff@google.com> wrote:

> 
> It seems the onus is on Type 2 proponents to define and then show demand for Type 2 vs. Type 1.

What would you accept as sufficient evidence of demand? Would a second-hand report from at least one team responsible for a nontrivial web app or JS framework be enough?

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

I'm not sure it can. For one thing if v1 becomes widely shipped and widely used, it becomes impossible to change the default without breaking compatibility. For another, if the parts of the system are not designed with both in mind, it is likely we'll end up with constructs that only work at all in Type 1 mode and have to be augmented with totally separate constructs for Type 2 mode.

> If so, can we agree to move forward with the Type 1 encapsulation that we both have defined API and customers for?

That depends on what "move forward" means. If it means Chrome shipping an implementation in product, well, I am not a decision-maker on that. Do what you think is right.

If you mean "move forward" on the specs in the sense of advancing them to a greater maturity level than Working Draft: I would be satisfied if both modes were defined and the Web Apps WG made an explicit WG decision which should be the default (or alternately, initially require an explicit extra token for each, to let the default be decided later based on demand).

Note that Shadow DOM originally provided something much closer to a Type 2 model. It was changed to expose shadowRoot (by default, with no opt-out) only in November, 2012. At the time there were objections, but Dmitri went ahead and made the change anyway. At the time he said he'd have a flag to pick either mode. Having both modes was also re-iterated in March 2013. If he reneges on that, then I would certainly object to moving the specs forward. The bug is here: <https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144>.

I am ok with defining hard security boundary encapsulation (Type 4) in separate specifications and possibly doing those later. However, it would be shame if everything about that kind of component worked 100% differently. So I would strongly prefer to consider whether we are building primitives that could be reused for that use case, even if they are not intended to fully address it.

Regards,
Maciej

Received on Saturday, 8 February 2014 01:59:25 UTC