On Mon, Sep 26, 2011 at 8:28 AM, Anne van Kesteren <ann...@opera.com> wrote:
> On Thu, 22 Sep 2011 20:30:24 +0200, Dimitri Glazkov <dglaz...@chromium.org>
> wrote:
>>
>> Further, instead of packaging Web Components into one omnibus
>> offering, we will likely end up with several free-standing specs or
>> spec addendums:
>>
>> 1) Shadow DOM, the largest bag of with XBL2's donated organs --
>> probably its own spec;
>> 2) Constructible and extensible DOM objects which should probably
>> just be part of DOM Core and HTML;
>> 3) Declarative syntax for gluing the first 2 parts together -- HTML
>> spec seems like a good fit; and
>> 4) Confinement primitives, which is platformization of the lessons
>> learned from Caja (http://code.google.com/p/google-caja/), integrated
>> with element registration.
>
> It's still not very clear to me what any of this means and how it will fit
> together.
While Dimitri works on the wiki version (pending his vacation), let me
lay them out in a slightly different order (2, 3, 1, 4):
- Today's DOM is actively hostile to idiomatic use in JavaScript. The
current WebIDL draft fixes some of this (yay for real prototypes!) but
not all. What we're suggesting is that, at least for HTML, we should
close the circuit on this as a matter of hygiene if nothing else.
Practically speaking, that means: giving HTML element types *real*
constructors (e.g. today's "new Image()", not just create* factories),
allowing them to be subclassed in the same idiomatic way everything
else in JS can, and giving them meaningful prototypes (handled by
WebIDL). Combined, these give us a way to think about "building new
elements" but without any connection to markup. They're just new JS
types that just happen to be DOM nodes. The fact that we think of them
differently today is *A BUG*, and one that we can fix. Best of all,
this is exactly the sort of thing that UI libraries like JQuery UI,
Dojo, Closure, YUI, etc, etc. do all day long but without
infrastructure to *really* participate in DOM.
- Declarative syntax is sugar that makes all this programmatic stuff
amenable to tooling and web developers who are more comfortable with
HTML than JS
- Once we've got custom element types, it sure would be handy to be
able to hide away your UI implementation. Shadow DOM, a concept
cribbed from XBL and friends, can provide this. Once you can have a
scriptable shadow which hides its elements away from regular
traversal, your element's API becomes more useful since your guts
aren't spilling out for the world to view. We've already refactored
many WebKit internal element implementations to use Shadow DOM to
great effect, so the value is clear. Exposing it to content authors is
the next obvious step.
- Describing all of what happens above in terms of the fewest number
of primitive APIs keeps us honest. Small, orthogonal APIs instead of
one monolithic thing help us drive consistency through the platform.
The less that's described as spec magic, the more we have to lean on
the generative composition of things web developers already know. For
instance, being able to subclass "plain old JS types" from DOM makes
it possible to define all of this stuff as though you'd just written
out something like:
function MyElementType(attrs) {
HTMLElement.call(this); // superclass ctor call, needed for
mixin properties
this.shadow = new ShadowRoot(this); // not magic, just new-ing
up this element's shadow root
// custom ctor behavior here
}
// delegate to the plain-old prototype chain.
MyElementType.prototype = Object.create(HTMLElement.prototype, { ... });
This might not look right to a spec author's eyes, but trust me, this
is how idiomatic JS subclassing of DOM *should* look. A version of
this component model built out of small primitives allows us to make
DOM work with it's environment, not against it, a principle that I
think should be a primary goal in all of our designs.
> Having either a specification or examples to shoot at would be
> helpful. Once it is more clear what each of these parts is going to look
> like, it might be easier for me to comment on how you suggest we split them.
>
>
>> Why split it like this? Several reasons:
>>
>> a) they are independently moving parts. For example, just shadow DOM,
>> all by itself, is already a useful tool in the hands of Web
>> developers. It's our job as spec developers to ensure that these bits
>> comprise a coherent whole, but from implementation perspective, they
>> don't need to block one another.
>
> How do you construct a shadow DOM though declaratively without a component?
>
>
>> b) each belongs in the right place. For example, making DOM objects
>> extensible is a concern inside of the DOM Core spec. Declarative
>> syntax really needs to live in HTML. Also...
>>
>> c) some parts are too small to be their own spec.
>> Constructible/extensible DOM objects bit does not even have an API
>> surface.
>>
>> d) And finally, every bit has potential of solving problems that are
>> more general than just about components. We shouldn't require making a
>> component if all developer wants is some shadow DOM. Similarly, lack
>> of needing a component shouldn't preclude the use of confinement
>> primitives.
>>
>> Just to recap: XBL2 is dead, exploding into a pretty rainbow. I am a
>> pop tart cat in front of the rainbow.
>
> :-)
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
>
