- From: Sylvain Galineau <galineau@adobe.com>
- Date: Sat, 8 Feb 2014 20:45:39 +0000
- To: Maciej Stachowiak <mjs@apple.com>
- CC: Alex Russell <slightlyoff@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, "<www-style@w3.org>" <www-style@w3.org>
On Feb 7, 2014, at 5:58 PM, Maciej Stachowiak <mjs@apple.com> wrote: > >> 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. > I wonder if there is a possible intermediate step between today’s proposal and one that supports a Type 2 model, namely enabling the author to lock down his component i.e. we leave to later the mechanism by which the components’ public interface is defined but, in the meantime, allow either fully public or fully private components as a first step. We’d still have to agree on which is the right default - and this may be hard enough to warrant making an attempt at a Type 2 definition - but could this be a workable compromise?
Received on Saturday, 8 February 2014 20:46:11 UTC