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
Line 15: Line 15:


==Desugaring==
==Desugaring==
From component model's perspective, all native form controls or elements with non-trivial behavior are also sub-classes of more primitive DOM elements with shadow DOM subtrees and behaviors attached. Thus, you can extend them and override shadow DOM subtrees just like you would with any component.


==Encapsulation==
==Encapsulation==

Revision as of 23:30, 28 July 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

Composability

Consistency

Desugaring

From component model's perspective, all native form controls or elements with non-trivial behavior are also sub-classes of more primitive DOM elements with shadow DOM subtrees and behaviors attached. Thus, you can extend them and override shadow DOM subtrees just like you would with any component.

Encapsulation

Extensibility

New element types are created by extending DOM elements. Each descendant can create its own shadow DOM subtree. If the descendant chooses to do so, the parent shadow DOM subtree becomes inaccessible and invisible. It's still there (to ensure that the code written to exercise it doesn't freak out), but it isn't rendered -- it's a ghost tree. A child may return this tree back to life by using <inherited> element anywhere in its shadow DOM subtree. The <inherited> is replaced with the parent shadow DOM subtree when rendering.

For example, in Rendering Form Controls with SVG use case, this allows the engineer to override appearance of a form element completely or to reuse it and supplement it with extra bits of appearance.

The essential mechanics of this behavior are probably as follows:

  • when initializing element, walk up to the prototype chain until top
  • walking down, for each member of the prototype chain, create shadow DOM subtree
  • render only the tree at the bottom of the chain.

Every instance also gets an opportunity to create its own shadow DOM subtree by using the shadow property. If the property is set, the newly blessed shadow DOM subtree behaves as if it was stuck at the bottom of the prototype chain, turning its prototype shadow DOM subtree into a ghost.

Differences From Existing Specs

Templates

Events

Attachment

Styles

Scripting API