W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [Component Model] Decorator Challenges

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Wed, 23 Nov 2011 14:43:40 -0800
Message-ID: <CADh5Ky3zhe9uvXpHpCX_NNkwzVN0FrscUByWqvdAWuO8btRneA@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: public-webapps <public-webapps@w3.org>, Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>
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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:37 UTC