W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: template namespace attribute proposal

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 18 Mar 2015 14:19:36 -0700
Message-ID: <CAAWBYDBrf09Tp_0_quyUquqtCtCuMnD_Uqer1RpKp=nXxXqikQ@mail.gmail.com>
To: Ryosuke Niwa <rniwa@apple.com>
Cc: Benjamin Lesh <blesh@netflix.com>, Austin William Wright <aaa@bzfx.net>, Anne van Kesteren <annevk@annevk.nl>, Adam Klein <adamk@chromium.org>, WebApps WG <public-webapps@w3.org>
On Wed, Mar 18, 2015 at 2:06 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
> On Mar 16, 2015, at 3:14 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> Karl Dubost said:
>>> The intersection seems to be:
>>> ['a', 'style', 'script', 'track', 'title', 'canvas', 'source', 'video', 'iframe', 'audio', 'font']
>>
>> Whoops, sorry, forgot about <title>.  We can resolve that conflict in
>> favor of SVG; putting an html <title> into a <template> is, I suspect,
>> exceedingly rare.
>
> That may be true but the added complexity of <title> inside a template element being special (i.e. it’s treated as SVG instead of HTML) may not be worth the effort.  HTML parser is already complex enough that using a simple rule of always falling back to HTML if element names are ambiguous may result in a better overall developer ergonomics.

Possibly, dunno.  I could go either way.  Consistently resolving
ambiguity in one direction could be simpler, but so could resolving in
favor of the massively-more-likely one.  Spec/impl complexity isn't
really of concern here; impls would need an explicit list of
elements/namespaces anyway. The spec could possible get away with a
blanket statement, but that opens up the possibility of ambiguity,
like <image> (which should clearly be SVG, despite the parser turning
it into <img> for you).

~TJ
Received on Wednesday, 18 March 2015 21:20:23 UTC

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