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: Mon, 28 Nov 2011 09:02:42 -0800
Message-ID: <CADh5Ky1+kGHtgtggGr5bQF73NNiJQUBgBLO41H2=tYDdiodpRg@mail.gmail.com>
To: Dominic Cooney <dominicc@google.com>
Cc: public-webapps <public-webapps@w3.org>, Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>
On Wed, Nov 23, 2011 at 11:06 PM, Dominic Cooney <dominicc@google.com> wrote:
> 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?

No, you've got it. We could totally retarget during dispatch, but that
would _feel_ weird.

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

Maybe? This will depend on the outcome of the exercise.

>> 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 Monday, 28 November 2011 17:03:11 UTC

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