[Component Model] Decorator Challenges

This is a continuation of the Component Model discussion at TPAC,
focusing on decorators (see definition here:
http://wiki.whatwg.org/wiki/Behavior_Attachment).

The design goal for decorators can summarized as follows: allow
runtime (dynamic) application and unapplication of presentation (and
possibly behavior, associated with the presentation) to a DOM element,
regardless of the current state of the element, in a way that’s
performant (both in memory and time space), and intuitive for today’s
Web developers.

The problem with decorators is not their application, but the unapplication.

If the decorator maintains state, this requirement of unapplication
creates a difficulty of understanding when the state matters, when it
no longer does, and even whether it’s the same state/instance as the
one you left just a moment ago.

For example, running script inside of the decorator forces the
decorator’s author to follow rules of engagement that differ from
those in typical script development -- in non-obvious ways:
* registering an event listener with any DOM node outside of the
decorator produces undesirable effect of a listener sticking around
even after the decorator is unapplied.
* using setInterval/setTimeout/XHR, or anything that exits event loop
produces an expectation of code running after the decorator is
unapplied.
* even just storing state inside of a decorator is challenging; in
situations where decorator is unapplied/reapplied quickly (like
matching a hover pseudoclass), the state is lost without any warning.

Even if we attempt to separate the state of a decorator from the
element and its document using an iframe- or worker-like machinery,
we’ll still have similar issues of managing decorator instances that
are no longer relevant, but don’t know that yet -- in addition to the
performance costs of such high-isolation approach.

One way to remove some state uncertainty could be to pool all
decorators instances and reuse them on reapplication, rather than
creating new instances. Unfortunately, this means that the decorators
may never be reclaimed, which also impacts performance
characteristics.

We could explicitly prevent the decorator from ever having a state or
being able to change it. This places a set of unorthodox (at least
from author’s perspective) constraints on the DOM tree, created by the
decorator. All of these constraints stem from the need to halt DOM
changes in a decorator shadow subtree and include not allowing:
* <script> elements,
* contenteditable,
* inline event handlers,
* custom elements, etc.

Conceptually, this type of arrangement is the one of DOM projection,
where there’s only one instance of the decorator’s shadow DOM subtree
in existence, and each application is just a rendering of that DOM
tree. While the barrier for fully grokking the frozen-state DOM could
be high for authors, this is probably the highest-performing solution,
since application and unapplication of a decorator is just a matter of
building and tearing down a box tree.

All approaches mentioned here have their drawbacks, and it appears we
either needs to invent something better or play the game of picking
lesser evils. Personally, I am leaning slightly toward the projected
DOM solution, because it yields fewer surprises for authors (it either
works or it doesn’t -- right away) and enables nice performance.

Thoughts and comments are appreciated.

The gist of this email is also here: Also here:
http://wiki.whatwg.org/wiki/Component_Model:_Decorator_Challenges

:DG<

Received on Tuesday, 22 November 2011 23:05:37 UTC