- From: James Graham <jgraham@opera.com>
- Date: Tue, 20 Oct 2009 19:17:39 +0000
- To: Tony Ross <tross@microsoft.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, Adrian Bateman <adrianba@microsoft.com>, "public-html@w3.org" <public-html@w3.org>
Quoting Tony Ross <tross@microsoft.com>:
> Examples:
> 1. Implicit namespaces for HTML, SVG, and MathML are generated by
> the current HTML 5 parsing algorithm.
That's a bug not a feature. Or rather it is an undesirable consequence
of the way that SVG and MathML have been grandfathered into the
language. I expect authors to be pretty confused that they can write
<svg><circle></circle></svg> (plus some attributes) and see a circle
but doing
var svg = document.createElement("svg");
var circle = document.createElement("circle")
//set some attributes for radius and position here
svg.appendChild(circle)
document.body.appendChild(circle)
won't have the same effect
> I want to make it clear that no new APIs, complexity, or problems
> are being introduced from a DOM perspective.
The fact that we have additional some additional complexity already
for the special case of SVG and MathML does not mean that it is a good
idea to generalise that complexity so that it occurs every time
someone decides they would like to unilaterally extend HTML. When it
is restricted to special cases it is relatively east for e.g.
javascript libraries to paper over the cracks (e.g. by having a list
of tag names associated with each namespace, or providing hard coded
short names to use in place of URIs, or having some higher-level API
specifically for working with SVG or MathML). When there is the
possibility of an arbitrary number of namespaces with arbitrary tags
names in each these solutions don't work and authors must bear the
full brunt of the complexity.
Received on Tuesday, 20 October 2009 19:18:17 UTC