W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: Model-driven Views

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Wed, 27 Apr 2011 21:47:48 +0300
Message-ID: <4DB864D4.6050808@helsinki.fi>
To: Erik Arvidsson <arv@chromium.org>
CC: Rafael Weinstein <rafaelw@google.com>, public-webapps@w3.org
On 04/27/2011 09:13 PM, Erik Arvidsson wrote:
> On Wed, Apr 27, 2011 at 08:33, Olli Pettay<Olli.Pettay@helsinki.fi>  wrote:
>> Not sure why this had some relation with XBL. Unless you are
>> planning to put the template based DOM nodes to anonymous DOM.
> The relation to XBL is that XBL has a template element and inside it
> you can "bind" attributes and content to the host element's attributes
> and content. We feel that the same concept can be useful outside of
> XBL and that we would like to provide a more generic solution that
> something like XBL can then reuse.
But the way XBL, at least XBL1 and some-version-of-XBL2, works
is quite far away from MDV template. XBL has anonymous content,
which causes event handling and styling to work in a bit different
way. etc.
And also, in MDV iterative template seems to have quite a big role.
That is not what XBL is quite for
(although one could implement iterative-like XBL widgets).

But ok, both have templates which are used to generate
some kind of instance.

>> - "Child nodes are not considered to be a part of the DOM. During
>>   parsing, they are lifted out..." Huh, you really want to alter HTML
>>   parsing?
>> - "If a template element is created via script, any children are
>>    removed and attached to the instancePrototype when the template
>>    element is attached to a document." What if the template is already
>>    in DOM when the new child elements are added.
>>    It sounds *very* strange to add new special cases to DOM Core
>>    methods.
> I feel like the document reflects too much what we ended up doing in
> the prototype. Lets backup and look at the problems we are trying to
> fix here.
> 1. We want<template>  to be able to contain arbitrary content that is
> used as the content of the instances that are created from it. Now
> assume that the template element contains some active content such as
> <audio autoplay>, script or simply just an image. We don't want the
> audio to start playing, we don't want the script to run inside the
> template element and we don't want the image to be requested at this
> point.

<audio> works even if it is not in document, and so
does <img>.
But I see the problem you're trying to avoid.

> 3. The last issue we are trying to provide a solution too is with DOM
> access, specifically with getElementById, querySelector etc. It is
> highly unlikely that the user wants to get to the content inside the
> template element. What they usually want is to get access to the
> template instance.
Yes, makes sense.

Received on Wednesday, 27 April 2011 18:48:15 UTC

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