- From: Kasimier Buchcik <K.Buchcik@4commerce.de>
- Date: Thu, 01 Dec 2005 10:46:17 +0100
- To: Anne van Kesteren <annevk@opera.com>
- Cc: ML-www-dom <www-dom@w3.org>
Hi, On Thu, 2005-12-01 at 10:00 +0100, Anne van Kesteren wrote: > On Thu, 01 Dec 2005 01:18:54 +0100, Maciej Stachowiak <mjs@apple.com> > wrote: > >> Opera will probably change its behavior to be in line with the above > >> mentioned browsers. > > We changed our behavior. (Release is not yet public.) > > > > Both "" and null are reasonable things to return for a nonexistent If both, "" and NULL would be allowed to be returned, then people would have to test for both cases to have the code run under any implementation. > > attribute, there is no deep principle at stake here. In fact one could > > argue that it's better to distinguish empty attribute value from absent Returning a NULL when a DOMString is expected is not possible in every programming language. E.g. Delphi's Strings are not objects and one cannot return a NULL (or NIL in Delphi) if the return type is a String, thus you have to return "". I don't think getAttribute() should be used to test if an attribute is existent; getAttributeNode() is there for this purpose. Please don't inject this extra functionality into getAttribute(). I tend to think that naming this method 'getAttribute' was not the most sensible thing to do - 'getAttributeValue' or 'getAttributeContent' would have fitted it better. > > attribute. So it seems better to update the formal spec to the de facto > > standard behavior. I second Joseph Kesselman's argument; people can use what is already there to solve this problem: 1) test for attribute node existence with getAttributeNode() 2) retrieve the value with getAttribute() or work on the attribute node previously acquired > Agreed. (Not sure if it can be done though without a DOM WG.) Regards, Kasimier
Received on Thursday, 1 December 2005 09:46:30 UTC