- From: Adam Barth <w3c@adambarth.com>
- Date: Mon, 6 Aug 2012 13:36:29 -0700
- To: Tony Ross <tross@microsoft.com>
- Cc: Henri Sivonen <hsivonen@iki.fi>, Adam Klein <adamk@chromium.org>, WebApps WG <public-webapps@w3.org>, Ian Hickson <ian@hixie.ch>, Rafael Weinstein <rafaelw@chromium.org>
On Mon, Aug 6, 2012 at 11:44 AM, Tony Ross <tross@microsoft.com> wrote: > From: hsivonen@gmail.com [mailto:hsivonen@gmail.com] On Behalf Of Henri Sivonen > Sent: Sunday, August 05, 2012 7:00 AM >> On Wed, Jul 18, 2012 at 11:35 PM, Adam Barth <w3c@adambarth.com> wrote: >> > On Wed, Jul 18, 2012 at 11:29 AM, Adam Klein <adamk@chromium.org> >> wrote: >> >> >> >> On Wed, Jul 18, 2012 at 9:19 AM, Adam Barth <w3c@adambarth.com> wrote: >> >>> >> >>> Inspired by a conversation with hsivonen in #whatwg, I spend some >> >>> time thinking about how we would design <template> for an XML world. >> >>> One idea I had was to put the elements inside the template into a >> >>> namespace other than http://www.w3.org/1999/xhtml. >> >> On the face of things, this seems a lot less scary than the wormhole >> model. I think this merits further exploration! Thank you! > > Just to clarify, is what you find scary about the other model the lack of support for XML, or something more? > > I've been under the impression we're trying to shield HTML developers from namespaces, so I'm a little concerned that this new proposal will move us in the opposite direction. Sure I'd like a proposal that works for XML too, but not if it means making the feature confusing for web developers. We already uses namespaces in HTML to implement SVG-in-HTML, for example. >> >> Also, the elements inside <template>, though they appear to be HTML, >> >> wouldn't have any of the IDL attributes one might expect, e.g., <a >> >> href="foo"></a> would have no "href" property in JS (nor would <img> >> >> have src, etc). They are, perhaps, too inert. >> >> I think that's not a problem, because you're not supposed to mutate the >> template anyway. You're supposed to clone the template and then mutate >> the clone. > > I agree cloning is the main use case (and will probably require a dedicated API since cloneNode won't cut it as-is), That's likely needed in any case because we'll want to clone-and-fill-in-the-holes in the template. Adam > but I wouldn't rule out developers altering templates dynamically. Under those conditions this exposes a lot of subtle differences I think most developers won't expect or understand. > > - Tony
Received on Monday, 6 August 2012 20:37:30 UTC