- 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