W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2005

Re: [dom3core] getAttribute

From: Curt Arnold <carnold@houston.rr.com>
Date: Thu, 1 Dec 2005 10:07:52 -0600
Message-Id: <8AF25E9B-24FB-40CD-97ED-F5D5BFBC0F34@houston.rr.com>
To: DOM mailing list <www-dom@w3.org>

A lot of good traffic on today.  Sorry I was asleep when much of it  
happened and couldn't participate in real time.

The DOM L1 test suite has a couple of tests that check for an empty  
string return from getAttribute, specifically elementgetelementempty,  
elementreplaceexistingattribute (and hc_ variants), and  
hc_elementremoveattribute.

C++ bindings using STL strings are one instance of a language that  
does not have distinct representation of a NULL string.

There is a legitimate end-user benefit for non-dominant browsers to  
conform the de-facto behavior when it deviates from the spec.   
However, HTML browsers are only one class of apps that implement the  
DOM spec.  If an errata was issued that made null a valid return  
value for getAttribute, Java code that depended on the behavior in  
the recommendation could break with a new comformant Java  
implementation that decided to return null instead of empty.

There may be some benefit from documenting where HTML+Javascript  
implementations are known to deviate from the recommendation for  
compatibility.  However, if something is done, it should be done in a  
way that XHTML+Javascript or SVG+Javascript browsers are required to  
follow the recommendation since there isn't a significant body of  
existing script.
Received on Thursday, 1 December 2005 16:08:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:58 GMT