Re: "Intelligent" element and attribute creation

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