Re: template namespace attribute proposal

On Thu, Mar 12, 2015 at 4:20 PM, Benjamin Lesh <blesh@netflix.com> wrote:

> For my part, I disagree slightly with this statement. If you just drop a
> <circle> tag in a <div>, you're going to get an HTMLUnknownElement. This is
> by design and to spec, of course. But it unfortunately means you can't
> clone() the element over to an SVG parent and hope it will work.d
>

Could you post the specific regression you ran into? The behavior you
describe should only true for text/html parsing; it doesn't apply to DOM
and application/xhtml+xml.

For instance, given an arbitrary, conforming HTML document containing an
SVG circle element, this should work:

var svgns = 'http://www.w3.org/2000/svg';
var c = document.getElementsByTagNameNS(svgns, 'circle')[0].cloneNode();
document.getElementsByTagName('body')[0].appendChild(c);
document.getElementsByTagName('body')[0].lastElementChild.namespaceURI ==
svgns; // true

text/html just isn't cut out for the sort of complex stuff we're
discussing. For instance, what if I want to start using the proposed
application/api-problem+xml format? You can't. text/html simply isn't built
for the complex features being proposed. This is made explicit in HTML5:

The DOM, the HTML syntax, and the XHTML syntax cannot all represent the
same content. For example, namespaces cannot be represented using the HTML
syntax, but they are supported in the DOM and in the XHTML syntax.
Similarly, documents that use the noscript feature can be represented using
the HTML syntax, but cannot be represented with the DOM or in the XHTML
syntax. Comments that contain the string "-->" can only be represented in
the DOM, not in the HTML and XHTML syntaxes.


There's a craptonne of XML based markup languages and file formats out
there. We can't just keep importing all of them into HTML every time we
decide one of them might be useful to embed inside HTML. THERE is a
usability and complexity nightmare.

Explicit is better than implicit, so I like the idea of a namespace
attribute element, it is forward-compatible with future vocabularies we may
wish to use.

Namespaces aren't *that* hard to understand. In my code above, I added one
line declaring the namespace (`var svgns`). Is that really so hard? If you
want to use the more advanced features of HTML, use namespaces, or import
whatever vocabulary I want - DocBook, OpenDocument, music notation, XSL,
without worry of collision. That's what they're there for, and at least a
handful of client-side libraries already do this, e.g. <http://webodf.org/>.

(Certainly much simpler than, say, the parsing differences between script,
style, pre, and attributes, which I only understand well enough to know to
stay the cuss away from putting user content in script tags. The amount of
inconsistency and complexity of text/html parsing is single-handedly
responsible for most of the XSS injections I come across. This isn't just
matter of having a feature or not, this is a matter of security... why not
fix *this*? /rant)

I understand the URI may be too much for people to grok, maybe instead use
a tag name ("html", "svg" or "mathml"):

<template namespace="svg">
  <circle cx="10" cy="10" cr="10" />
</template>

The application/xhtml+xml parser would simply ignore the namespace
attribute, using xmlns on children instead. Polyglot HTML would use both
attributes.

If two separate attributes is too much, then just add xmlns= support to
text/html.

Austin.