> On Mar 18, 2015, at 2:19 PM, Tab Atkins Jr. <jackalm...@gmail.com> wrote: > > On Wed, Mar 18, 2015 at 2:06 PM, Ryosuke Niwa <rn...@apple.com> wrote: >> On Mar 16, 2015, at 3:14 PM, Tab Atkins Jr. <jackalm...@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).
Implementation complexity isn’t my concern. Exception for <title> will be yet another random fact Web developer needs to be aware of. In general, we have too much tolerance for complexity and exceptions to rules on the Web platform. We should strive to make the Web platform as simple as possible so that humans can comprehend. - R. Niwa