A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

Component Model: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
No edit summary
Line 65: Line 65:
==Composability==
==Composability==


Being DOM objects, components fit naturally into the document DOM tree and support all of its composition properties. In addition, the <code>content</code> element allows controlling interaction between shadow and document DOM trees. A <code>content</code> element in the shadow DOM tree specifies places where immediate document DOM tree children of the component are rendered. For example, a <code>DockLayoutPanel</code> component could be used like this in the document DOM tree:
Being DOM objects, components fit naturally into the document DOM tree and support all of its composition properties. In addition, the <code>content</code> element allows controlling interaction between shadow and document DOM trees. A <code>content</code> element specifies places where immediate document tree children of the component are rendered ''inside'' the shadow tree. For example, a <code>DockLayoutPanel</code> component could be used like this in the document DOM tree:
<code>
<code>
<pre>
<pre>

Revision as of 19:10, 18 August 2011

Here's a good starting point for learning about the component model spec, which is currently under development (also see periodically updating gh-pages).

Introduction

TODO Populate with beautifully crafted words.

Overview

Extensibility

The component model must enable creation of new types of DOM elements by allowing the use of existing DOM elements in Javascript prototype chain. For example, here's how you might create a new sub-type of HTMLElement:

function LayoutManagerPanel() {
    HTMLElement.call(this);
}

LayoutManagerPanel.prototype = Object.create(HTMLElement.prototype);

// ...

// 1) Will not be able to add instances of LayoutManagerPanel to document without this call.
// 2) First parameter specifies the tagName of the element being registered and must be a string prefixed with "x-".
Element.register("x-layout-manager-panel", LayoutManagerPanel);

// ...

var panel = new LayoutManagerPanel();
document.body.appendChild(panel);
// or
document.body.innerHTML = "<x-layout-manager-panel></x-layout-manager-panel>";

The resulting panel instance is a Javascript object that is a valid DOM element, which can be added to the DOM tree. You can then extend this object using standard Javascript prototype inheritance.

Needs implementing

  • Make calling constructors of DOM elements possible.
  • Implement Element.register.

Consistency

Because components are just DOM objects, they inherently share the same traversal and manipulation APIs, as defined by the DOM Core. The authors of components can extend these APIs by adding custom methods and properties on DOM objects, using standard Javascript inheritance:

Widget.prototype = Object.create(HTMLElement.prototype, {
    update: {
        value: function() { /* ... */ }
    },
    value: {
        get: function() { /* ... */ },
        set: function() { /* ... */ }
    },
   // ...
});

The common API surface and the ability to extend it serves as a natural API boundary for framework authors, enabling interoperability.

Encapsulation

Composability

Being DOM objects, components fit naturally into the document DOM tree and support all of its composition properties. In addition, the content element allows controlling interaction between shadow and document DOM trees. A content element specifies places where immediate document tree children of the component are rendered inside the shadow tree. For example, a DockLayoutPanel component could be used like this in the document DOM tree:

<x-dock-layout-panel>
    <h1 class="north">On Gardens</h1>
    <ul class="west">
        <li>Automatic Gardens</li>
        <li>Gardening on minefields</li>
    </ul>
    <p>I love gardening.</p>
    <div class="south">Written by Avid Gardener.</div>
</x-dock-layout-panel>

Provided that its shadow DOM tree looks like this:

<#shadow-root>
    <div class="north">
        <content includes=".north">
    </div>
    <div>
        <div class="west">
            <content includes=".west">
        </div>
        <div class="east">
            <content>
        </div>
    </div>
    <div class="south">
        <content includes=".east">
    </div>
<#shadow-root>

The document DOM tree children on of x-dock-layout-panel will be rendered as if composed from this tree:

<x-dock-layout-panel>
    <div class="north">
        <h1 class="north">On Gardens</h1>
    </div>
    <div>
        <div class="west">
            <ul class="west">
                <li>Automatic Gardens</li>
                <li>Gardening on minefields</li>
            </ul>
        </div>
        <div class="east">
            <p>I love gardening.</p>
        </div>
    </div>
    <div class="south">
        <div class="south">Written by Avid Gardener.</div>
    </div>
</x-dock-layout-panel>

Needs Implementing

  • content element.

Isolation

Brainstorming page

Desugaring

Differences From Existing Specs

Templates

Events

Attachment

Styles

<style scoped> is a natural way to limit style sheets to only affect the shadow tree of a component. The component model follows the implementation suggested in this www-style thread. That is, a selector is only matched up to, and including, the scoping element - i.e., the parent element of <style scoped> - but not further. The exceptions are:

  • the selector contains the :root pseudo-class (note that this will fail if not used within the first selector sequence), or
  • the selector contains the :scope pseudo-class

CSS4: care must be taken that the subject of a selector is the scoping element or a descendant thereof.

[TODO: notes on crossing the boundary from/into the shadow tree]

Scripting API