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
(Created page with 'Here's a good starting point for learning about the component model spec, which is currently [https://github.com/dglazkov/component-model under development] (also see periodicall...') |
No edit summary |
||
| Line 1: | Line 1: | ||
Here's a good starting point for learning about the component model spec, which is currently [https://github.com/dglazkov/component-model under development] (also see periodically updating [http://dglazkov.github.com/component-model/ gh-pages]). | Here's a good starting point for learning about the component model spec, which is currently [https://github.com/dglazkov/component-model under development] (also see periodically updating [http://dglazkov.github.com/component-model/ gh-pages]). | ||
= | =Introduction= | ||
''TODO'' Populate with beautifully crafted words. | ''TODO'' Populate with beautifully crafted words. | ||
| Line 8: | Line 8: | ||
* [[Behavior_Attachment| Behavior Attachment]] | * [[Behavior_Attachment| Behavior Attachment]] | ||
= | =Overview= | ||
==Composability== | |||
==Consistency== | |||
==Desugaring== | |||
==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 <code><inherited></code> element anywhere in its shadow DOM subtree. The <code><inherited></code> is replaced with the parent shadow DOM subtree when rendering. | |||
For example, in [[Component_Model_Use_Cases#Rendering_Form_Controls_with_SVG | 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. | |||
== | ==Differences From Existing Specs== | ||
=Templates= | |||
=Events= | |||
=Attachment= | |||
=Styles= | |||
=Scripting API= | |||
[[Category:Proposals]] | [[Category:Proposals]] | ||
Revision as of 23:11, 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
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.