- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Mon, 24 Apr 2006 22:19:09 +0200
- To: Robin Berjon <robin.berjon@expway.fr>
- Cc: Web APIs WG <public-webapi@w3.org>
* Robin Berjon wrote: >I don't think it needs to go into D3C. I am not too fond of adding >ever more convenience methods to the DOM, but this one is very >convenient as well as adapted to constrained devices (where >performance also matters). It also helps kill what is possibly the >number one user error when navigating the DOM, which to >consider .firstChild, .nextSibling, etc. to be elements. The great thing about .firstChild, .nextSibling, and so on is that they work absolutely everywhere, in particular in script-enabled SVG viewers. Well, except Tiny 1.2 implementations where they may or may not work. So if you use them, your content is unlikely to work there, and if you use ElementTraversal instead, your content is unlikely to work anywhere else unless you include a second code path everywhere so you use both. This, in addition to the confusion caused, makes this design highly expensive. ElementTraversal exists virtually nowhere. In contrast, selectSingleNode is very widely available and known, whether you code with MSXML, .NET, Xalan, Flash, IE's XMLHttpRequest, Perl's XML::DOM::Lite, JDOM, dom4j, and so on and on, it's there. It is likely to be standardized and added to more implementations in the future, it is a highly flexible and easy to use, and there are more hits for it on groups.google.com than for all the simple tree navigation methods together, or getElementsByTagName. It seems unlikely that implementations where neither the DOM Core tra- versal methods nor selectSingleNode work but ElementTraversal does would persist for a considerable timeframe, even on mobile devices one of the facilities is readily available, OMA's ECMAScript Mobile Profile has firstChild and its kind, and so does Flash Lite, for example. If the goal is to have less differences between the many XML environ- ments, inventing entirely new features instead of subsetting fairly ubiquitous features is clearly not a good approach, both designs pro- vide the exact same functionality in a similar way and with similar resource requirements, that one design "rocks" more, matters about as much as people "love" it or how "nice" it is, there are many better arguments you could cite against a selectSingleNode based design. That said, I don't feel particularily strongly about ElementTraversal, but it should be clear in this discussion that this is more about SVG Tiny 1.2 having highly SVG Tiny 1.2-specific means to address core use cases rather than adding a bit convenience to the Core DOM. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Monday, 24 April 2006 20:19:14 UTC