Re: [Component Model] Decorator Challenges

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