- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Wed, 27 Apr 2011 21:47:48 +0300
- 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. -Olli
Received on Wednesday, 27 April 2011 18:48:15 UTC