> On Jul 1, 2014, at 3:26 PM, Domenic Denicola <dome...@domenicdenicola.com> > wrote: > > From: Maciej Stachowiak <m...@apple.com> > >> Web Components as currently designed cannot explain the behavior of any >> built-in elements (except maybe those which can be explained with CSS alone). > > Unfortunately this is a hard problem that nobody has even sketched a solution > to.
I have sketched a solution to it (including publicly in the last Web Apps WG meeting). I believe the following set of primitives would be sufficient for implementing built-in elements or their close equivalents: (1) “closed” or “Type 2 Encapsulation” mode for the Shadow DOM as I have advocated it (i.e. no access to get into or style the Shadow DOM when in this mode). (2) Ability to have the script associated with the component run in a separate “world” (3) A two-way membrane at the API layer between a component and a script; approximately, this would be the Structured Clone algorithm, but extended to also translate references to DOM objects between the worlds. (4) An import mechanism that loads some script to run in a separate world, and allows importing custom element definitions from it. (5) Custom elements with the ability to work with the membrane from (3) and the script world from (2). With this in place, the only “magic” of built-in elements would be access to platform capabilities that some built-in elements have (which could be exported as lower-level specific APIs, e.g. participation in form submission for form controls), and the fact that they come pre-imported. Unfortunately, Shadow DOM doesn’t provide (1) and HTML Imports doesn’t provide (4). Thus, merely adding (2) and (3) won’t be enough; we’ll need to create parallels to API that Google has already shipped and frozen without addressing this problem. Thus, when you say the following: On Jul 1, 2014, at 5:34 PM, Domenic Denicola <dome...@domenicdenicola.com> wrote: > From: Edward O'Connor [mailto:eocon...@apple.com] > >>> But soft encapsulation is just as useless for explaining the platform >>> as no encapsulation at all. >> >> I think "just as useless" overstates your case. Type 2 allows you to hide >> implementation details of your component from authors better than Type 1 >> does. Yes, it's not isolation for security purposes, so it doesn't get you >> the whole way, but like Brendan said, we shouldn't let the perfect be the >> enemy of the good. > > Well, but *for explaining the platform* it is just as useless. It may be > useful independently for authors who wish to protect against interference by > people who are afraid of feeling bad, but it is not useful for explaining the > platform. > > My personal perspective is that it is already a shame we are on track to have > two versions (in some sense) of web components: the existing one, and one > that explains the platform. It would be a shame to have a third in between > those two, that is unlike the existing one but also does not explain the > platform. So I guess along this axis I would strongly prefer "perfect" to > "good," I suppose because I think what we have already is "good." I believe you are wrong. DOM-level encapsulation can be used as-is in combination with scripting encapsulation to provide a secure platform for untrusted components, and a way to explain built-in elements. Shadow DOM without DOM-level encapsulation cannot be used in combination with other primitives. Thus, if we’d built Shadow DOM with DOM-level encapsulation in the first place, we could add the right other primitives to it and be able to explain built-in elements. But the way it was actually done can’t explain anything built-in. I would really like to build a system that can provide security for mutually distrusting components and embedders, and that can explain the platform. However, I feel that my efforts to give feedback, both to nudge in this direction and otherwise, have been rejected and stonewalled. With Google controlling editorship of all the Web Components specs, shipping the only implementation so far -- unprefixed, freezing said implementation, and not being very open to non-Google input, and making all decisions in private via “consensus within Google”, it is hard to see how to meaningfully participate. If there is any possibility of some of those factors changing, I think it’s not too late to end up with a better component model and I’d be interested in helping. Regards, Maciej P.S. Due to the factors stated in the last paragraph, I’m going to try to limit my participation in this thread as much as possible for the sake of my own mental equilibrium.
