Re: [Component Model] Decorator Challenges

On Tue, Nov 22, 2011 at 3:05 PM, 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,
> * 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.

I am in favor of pursuing this "projection" idea.  It solves our
problems elegantly (there's no per-instance DOM to hang state off of,
so you can't hang state off of each instance!) while being useful for
other stuff as well.  In SVG, for example, I'm attempting to recast
<use> into the semantics of the Component Model so we can reuse code
and have a single conceptual model, and a projected tree appears to be
exactly what's needed to make <use> work properly.

When we discussed this at TPAC, there were some concerns about layout
that would make this difficult.  Have you come up with something in
the interim to render that concern moot, or are you just confident it
can be worked around?

~TJ

Received on Wednesday, 23 November 2011 22:19:26 UTC