- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 18 Mar 2015 14:19:36 -0700
- 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