Component Model Should Use DOM Object Inheritance

Summary: There is no need to build another type of inheritance into
the component model, since all DOM already has an inheritance
mechanism.

Another set of thoughts around use cases
(http://wiki.whatwg.org/wiki/Component_Model_Use_Cases)

A large part of complexity of the current XBL2 draft comes from
dealing with inheritance: from implicit/explicit inheritance chain
(http://dev.w3.org/2006/xbl2/Overview.html#binding-inheritance), to
the final flattened tree
(http://dev.w3.org/2006/xbl2/Overview.html#the-final-flattened-tree),
to multi-step matching of scoped stylesheets
(http://dev.w3.org/2006/xbl2/Overview.html#binding-style-sheets).

I think that we can jettison the entire concept of binding inheritance
from the spec and instead rely on ye good olde DOM object inheritance
to do the dirty work. Consider this strawman:

1) Each component inherits from a DOM object, directly or indirectly.
This of course means that a component is-a DOM object.

2) Whenever the shadow tree needs to be constructed, the component's
"createShadowSubtree" method is called. This method constructs a
shadow DOM subtree (details omitted for simplicity).

So, for the imperative API, if a component wants to build a shadow DOM
that's different than its prototype/superclass, it overrides the
method.

function MyButton() {
}

MyButton.prototype = {
    __proto__: HTMLDivElement,
    createShadowSubtree: function(DOMScope)
    {
        // where DOMScope is a bit made-up, please accept as pseudocode.
        DOMScope.appendChild(document.createElement("img")).src = "foo.png";
    }
}

Similarly, a declaratively-defined component is wired to use the
"createShadowSubtree" method to clone the contents of the <template>
element. Thus the equivalent to above definition would be:

<!-- rough pseudocode -->
<element name="MyButton" extends="HTMLDivElement">
    <template>
        <img src="foo.png">
    </template>
</element>

This of course means that we must rely on composition to emulate
functionality, provided by the <inherited> element from the current
XBL2 draft, but I believe this is an acceptable feature/simplicity
compromise. In fact, composition seems like a nice path from status
quo, where the frameworks
(http://wiki.whatwg.org/index.php?title=Component_Model_Use_Cases#Custom_Widget_System)
are doing just that with HTML elements.

:DG<

Received on Friday, 11 March 2011 05:16:42 UTC