The purpose of this document is provide a general overview of the behavior attachment problem in the Web.
HTML, as exists today, does not provide an organized way of attaching behavior to a DOM element. While you can add individual scripting methods, properties and event handlers to it, there is no way to do this atomically and with proper encapsulation.
In order to effectively provide encapsulation, a behavior attachment method should provide the following properties:
- DOM encapsulation, typically using shadow DOM. Shadow DOM refers to the ability of the browser to include a subtree of DOM elements into the rendering of a document, but not into the main document DOM tree.
- Style encapsulation, or a way to manage expectations of styles outside of the behavior affecting it, and conversely, styles of the behavior affecting the outside.
- Event encapsulation, which is a way to ensure that events, firing inside of the behavior’s DOM elements do not accidentally expose behavior’s implementation details.
Examples in the Wild
|Library||Behavior Attachment Implementation|
|Dijit (Dojo's UI Library)||Creates a parallel object hierarchy to create illusion of homogenous object space, with full wrappers around DOM objects. Relies on inheritance-style approach by assigning each DOM element a dojoType attribute in markup, then traversing DOM and attaching corresponding behavior.|
|Google Web Toolkit||Also uses parallel object hierarchy to shield the user from behavior attachment deficiency, relying on inheritance for compartmentalization and reuse.|
|JQuery UI||A good balance of insulation from DOM objects with just-in-time wrapping. Progressive enhancement is the adopted technique of applying behavior. The behavior is transient and often an API is provide to detach it. It's interesting that the API is very late-bound and based on passing strings as method names.|
|Prototype||Uses prototype inheritance chain to bestow new properties/methods on a DOM element. The changes are purely additive and imply permanent change in context of document’s lifetime.|
Two interesting symptoms emerge after analysis of the approaches:
- Dynamic-sounding techniques for permanently attaching behavior. In the absence of a way to instantiate a DOM element with a new behavior attached, many frameworks use decoration/mixin-like patterns in its place. However the semantics and effect of application is one-way in most cases, indicating that the actual intent is to attach behavior as close to element instantiation as possible.
Behavior attachment is also used by browser extensions, where an extension script, running in the context of the document, may attach extra behavior (including UI), to give the user more functionality within a document. Typical examples of such extensions are:
The main challenge for these extensions is to add and remove behavior to DOM elements (including extra DOM elements) to an existing document with least disruption, preferably in a way where the scripts of the document aren’t ever aware of these behavior attachments.
Built-in HTML Elements
Another example of behavior attachment can sometimes be found in the browser itself, where complex built-in controls are created using shadow DOM. Here are a few examples in WebKit:
videoelement. This one is interesting, because it's composed out of other HTML elements with attached behavior (like
This behavior attachment is singular and permanent, surviving throughout the lifetime of the element. Encapsulation is an important property for this behavior attachment, since the browser should never leak the implementation details of the HTML elements to the document.
Behavior Attachment Methods
To better understand the intent of behavior attachment, we can split these examples in the wild into two general groups:
- An element behavior attachment, where the behavior is permanently associated with the element and creates a new type of element; and
- A decorator behavior attachment, where transient behaviors are given to or taken away from an element, modifying aspects of its properties, but leave the identity of an element intact.
The table below provides a comprehensive comparison between the two methods:
|Purpose||Create new content building blocks.||Give existing content new behavior and/or appearance.|
|Paradigm||Object-Oriented Programming||Aspect-Oriented Programming|
|Compartmentalization and Reuse Vehicle||Inheritance||Aspect|
|Examples of Use||
|Identity||Creates a new type of element.||Does not change the identity of the element.|
|Lifetime||Permanent, originates with the element’s creation and exists through the lifetime.||Transient, added and removed dynamically.|
|Environment||Full control of content.||Foreign document or limited control of content.|
|Shadow Tree||Only one tree, initialized as the element is created. Inherited shadow trees can be reused, nested in the element's tree.||Each decorator must have its own shadow subtree, and the aggregate shadow tree of an element is composed out of these subtrees.|
|DOM API||Explicitly interested in exposing methods or properties on the DOM element as its API.||Should avoid adding any extra methods or properties to the DOM element that’s being decorated.|
Existing Specifications and Implementations
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 follow inherited bindings.
- There is a fair bit of machinery specified to marry the aspect and inheritance concepts seamlessly.
- There is no notion of extending DOM elements.
What does XBL1 do?
- There does not seem to be a separation between these two decorator and element behavior attachment. The http://mxr.mozilla.org/mozilla2.0/source/toolkit/content/xul.css seems to indicate the need for element attachment.
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.