- From: Robin Berjon <robin.berjon@expway.fr>
- Date: Mon, 06 Oct 2003 17:07:32 +0200
- To: steve@fenestra.com
- Cc: www-dom@w3.org
Steve Schafer wrote: > On Sun, 05 Oct 2003 20:24:50 +0200, Robin Berjon wrote: >>I understand your wishes but can that not be solved differently by the >>implementation? > > Yes, as I said, it _can_ be handled behind the scenes by the > implementation. That's what I'm doing now. Of course, everything in the > DOM _can_ be handled by an implementation without using the DOM at all, > but that, I think, is rather beside the point of this mailing list. That's an extreme take that doesn't represent my point of view. All I'm saying is that I believe DOM Core features should be generic enough in that they solve problems that are seen frequently enough and/or are otherwise overly painful to deal with. I've seen lots of proposals for new DOM methods in a bunch of places (and I'm sure the WG has seen many many more), often ones that were implemented as extensions here or there. They are usually useful but not generic enough. If you step back and look at all the things that one can do with a DOM, it becomes obvious that a *lot* can be added. But that would lead to an API bloated beyond all recognition. Because of that, the razor should imho be very sharp. And while I think your proposed feature is something that I myself would use in some cases, I don't feel it passes the test. > I admit that there may be situations where the semantics of a given > element are substantially dependent on the context of that element, but > I don't think HTML's <li> is a good example of such. An attribute having > useful meaning in one context and simply being ignored in another (that > is, it could still have the same meaning; it's just not used) is a far > cry from an attribute having completely different useful interpretations > in two (or more) contexts, which is what's happening in SVG. Also note > that the "value" attribute of <li> is deprecated in HTML 4.0 and absent > in XHTML (except via the Legacy module); this suggests that the authors > understand that there are significant problems with using such heavily > overloaded element and attribute names. I know that <li> isn't a terribly good example, I simply wanted to pick something from a common vocabulary, and that a bit late on a friday evening :) The fact still stands, for instance I have a vocabulary in which the <title> element can either be the title of the document, of a section, or of an embedded object (eg an image). In the two first cases it'd behave pretty much the same, in the third it would typically become a tooltip. The specialised DOM would want to do very different things, and it could only do that when the element is added to the tree. As a side note, I don't think that value was deprecated because of <li>'s overloading -- which honestly isn't really heavy -- but rather because it was deemed too presentational (it can be replaced by CSS). > Well, if in fact the DOM is concerned only with the "generic way," then > it doesn't need anything like namespace support or most of the other > stuff added in Levels 2 and 3, since all of that can be handled, albeit > somewhat painfully, using Level 1 features and implementation-specific > extensions. I don't think that namespace handling is something that could be handled nicely before DOM 3. It also happens to be something that 98% of users will need. > But it's clear that the authors are interested in dealing > with more than the bare minimum. Section 1.1.12 of the latest DOM Level > 3 draft clearly shows that the authors have been thinking about the > problem of dealing with elements from multiple namespaces; Hmmm, there's no 1.1.12 in the June WD of DOM 3 did you mean 1.3.3 and/or 1.3.5 and/or 1.3.6? > what I'm > proposing is a simple extension of exactly the same idea to attributes. This somewhat imaginary code deals with attributes: if (attr.isSupported("+SVG", "1.2")) { SVGRotateAttr srat = (SVGRotateAttr)attr.getFeature("+SVG", "1.2") ... } This allows you to get a specialised Attr in the same way you can get a specialised SVGRectElement. This also happens to be what imho should be user-visible. Do you want to "force" users to use your proposed extensions? Will they see the value in them? Will they not rather think "well that should be dealt with by the implementation, I don't see the value here and I'll stick to the API I already know"? >>In the case of SVG, I believe all that you raise goes away when using >>setAttributeNS() (that might not be true in other languages). > > No, that's not true. The various ...AttributeNS... methods are for > dealing with attributes which themselves belong to a namespace; except > for a handful, like xml:base et al., the attributes in SVG aren't > associated with any namespace. In other words, in the following: No, foo.setAttributeNS(null, "d", "M 0 100 H 100 V 100") will do the right thing. IIRC there's a subtle difference between setAttributeNS() and setAttribute(), in that in both nodeName will be set but localName will only be set with the former since it is namespace aware. Since I live on a namespaces-only planet, I only use the NS forms of all methods anyway. Either way, what I said holds for setAttribute(). Using this approach, when setAttribute{NS} (and its variants) is called, you have full context. -- Robin Berjon <robin.berjon@expway.fr> Research Scientist, Expway http://expway.com/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
Received on Monday, 6 October 2003 11:07:34 UTC