Re: [Component Model] Decorator Challenges

On Wed, Nov 23, 2011 at 2:18 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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?

It's sort of both. The mechanics of DOM projection can be implemented
as just cloning of DOM trees, which alleviates the concerns. At the
same time, I am rather interested in supporting multiple render
objects ( boxes/frames) per DOM node in WebKit, which would enable a
truly performant projection. But for the moment, that last part is
just a ... projection. *rimshot*

>
> ~TJ
>

Received on Wednesday, 23 November 2011 22:44:30 UTC