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).

Behavior Attachment: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 73: Line 73:
* HTC does not have the concept of shadow DOM, but the [http://msdn.microsoft.com/en-us/library/ms531018(v=vs.85).aspx specified behavior] is firmly an element behavior attachment.
* HTC does not have the concept of shadow DOM, but the [http://msdn.microsoft.com/en-us/library/ms531018(v=vs.85).aspx specified behavior] is firmly an element behavior attachment.


===What does sXBL do===
===What does sXBL do?===
* It appears that the spec is abandoned, but the gist is similar to XBL2, except there is only one shadow tree, direct access to [http://www.w3.org/TR/sXBL/#xblshadowtree shadow subtree], and a binding model that seems to indicate element behavior attachment, but using decorator API.
* It appears that the spec is abandoned, but the gist is similar to XBL2, except there is only one shadow tree, direct access to [http://www.w3.org/TR/sXBL/#xblshadowtree shadow subtree], and a binding model that seems to indicate element behavior attachment, but using decorator API.

Revision as of 23:05, 4 July 2011

WORK IN PROGRESS

  • element is DOM element.
  • content is DOM content.
  • document is HTML document
Comparison between the decorator and element behavior attachment.
Decorator Element
Purpose Give existing content new behavior and/or appearance. Create new content building blocks.
Paradigm Aspect-Oriented Programming Object-Oriented Programming
Compartmentalization and Reuse Vehicle Aspect Inheritance
Examples of Use
  • Add special UI treatment to all vcards in a document.
  • Create an extension to provide extra download options for certain types of links.
  • Implement built-in HTML controls: input/textarea, media, etc.
  • Define an element to represent a customizable calendar view.
  • Define a button row control with application-specific grouping logic (see GMail button bars).
Identity Does not change the identity of the element. Creates a new type of element.
Lifetime Transient, added and removed dynamically. Permanent, originates with the element’s creation and exists through the lifetime.
Environment Foreign document or limited control of content. Full control of content.
Defining Traits
  • Unobtrusive
  • Dynamic
  • Composable
  • Interoperable
Shadow Tree Each decorator must have its own shadow subtree, and the aggregate shadow tree of an element is composed out of these subtrees. Only one tree, initialized as the element is created. Inherited shadow trees can be reused, nested in the element's tree.
DOM API Should avoid adding any extra methods or properties to the DOM element that’s being decorated. Explicitly interested in exposing methods or properties on the DOM element as its API.

What does XBL2 do?

  • There are two ways to bind: using binding element (inline or via external document) and using CSS. The former somewhat matches the notion to be element behavior, and the latter is the decorator behavior. However, there is no distinct difference in the attachment mechanism.
  • Inheritance is entirely self-contained, using “extends” attribute. However, the prototype chain of the implementation object is fixed up to match inheritance
  • There is a fair bit of machinery specified to marry the aspect and inheritance concepts seamlessly.

What does XBL1 do?

What does HTC do?

  • HTC does not have the concept of shadow DOM, but the specified behavior is firmly an element behavior attachment.

What does sXBL do?

  • It appears that the spec is abandoned, but the gist is similar to XBL2, except there is only one shadow tree, direct access to shadow subtree, and a binding model that seems to indicate element behavior attachment, but using decorator API.