Re: [Component Model] Decorator Challenges

On Wed, Nov 23, 2011 at 8:05 AM, Dimitri Glazkov <dglazkov@chromium.org>wrote:

> 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,
>

Is the problem with inline event handlers that you’d expect the
event.target of such a handler to be a DOM object, which doesn’t explicitly
exist in a decorator since the decorator is merely specified with DOM, but
the implementation is given latitude to realize it as a projection? That
seems reasonable. Or something else?


> * custom elements, etc.
>

If the decorator only relies on state in the decorated element (say, in
that element’s attributes) it seems the decorator could be applied and
unapplied safely. However say a given decorator includes a <progress>
element. Would all instances of that decorator display the decorator with
the same % complete? It would be an interesting exercise to catalog HTML
elements and identify which ones would be problematic in this way.

Alternatively you could whitelist elements, and maybe even attributes, that
_can_ be used in decorators. Is it possible that what decorators are doing
is in fact specifying something more primitive than DOM, like styled CSS
boxes that can react to events? Do you think a proposal based on that would
be feasible?


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