Re: Namespace-aware APIs do not need to suck

Maciej Stachowiak wrote:
> ...
> I think to have a solid proposal we'd need:
> 
> A) More methods than just createElement()... a big part of the concern 
> is using DOM APIs to deal with elements and attributes created by 
> parsing markup.
 > ...

Obvious additions would be

   Node.expandedName

plus Clark-Notation aware variants of

   Node.getElementByName

   Node.createElement

Would having equivalents for everything in DOM L2 be sufficient, or are 
you looking for more?

> B) Slightly more formal specificiation - a sample implementation in 
> JavaScript is not easy to read or clear about what details would be 
> normative.
> 
> Assuming this aligned with the DOM Core set of methods, then probably 
> Web Apps WG would be the right venue for such a proposal.

The venue doesn't really matter. What's important is that *if* one of 
the perceived problems with XML namespaces is the quality of namespace 
support in DOM, then some group inside the W3C should work on fixing this.

> Personally, I'm still somewhat dubious of this API. Having to predeclare 
> all the tags you intend to use is inconvenient and may substantially

You don't have to predeclare. But if you do you benefit from syntax 
checking (if you mistype the variable name holding the expanded name, 
the script will fail early).

> increase code size. But it might be nicer if there were predeclared 
> versions of the Clark notation strings for all standard elements and 
> attributes. For example if you could write this without having to 
> predeclare anything:
> 
> var x = document.createElement(svg.a);
> x.setAttribute(xlink.href, "http://foobar.com");
> 
> ... then that would be pretty sweet.
> ...

That would require hardwiring SVG into the API. I don't think that's a 
good idea. If we did that, we could also do

var x = document.createSvgElement("a");

Best regards, Julian

Received on Friday, 20 November 2009 11:21:37 UTC