W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: Making <template> play nice with XML and tags-and-text

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 6 Aug 2012 13:36:29 -0700
Message-ID: <CAJE5ia-MSMbH2fD0mqcmz_+Hh_FY7qatkSnGeR0LTCV1AyPEhA@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:54 GMT