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

Re: [dom3core] getAttribute

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 1 Dec 2005 23:30:48 -0800
Message-Id: <F23722BA-A42A-402E-A44B-FE9C2CEE6DB4@apple.com>
Cc: DOM mailing list <www-dom@w3.org>
To: Curt Arnold <carnold@houston.rr.com>

On Dec 1, 2005, at 8:07 AM, Curt Arnold wrote:

> 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.

How about allowing null only for JavaScript implementations, then? It  
seems silly to make the spec incompatible with a vast body of  
existing JavaScript code for the sake of Java.

If the DOM intends to ignore browser-based implementation issues,  
then we'll have to conclude that our best alternative is to seek a  
different standards forum that cares (e.g. <http://whatwg.org/mailing- 

I will note that the CSS working group is much more flexible about  
evolving the spec based on browser implementation experience. Note  
that CSS 2.1 actually removes entire features from CSS2.

> 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.

It seems like a recipe for disaster to have a subtle change of  
semantics like this between different documents. In particular, a  
browser may allow inserting SVG MathML elements into an HTML document  
via the DOM, or may import a node from an XHTML document into an HTML  
document via adoptNode - at this point should the semantics of  
getAttribute change? Requiring implementations to be inconsistent  
with themselves seems even worse than allowing inconsistency between  
different implementations.

Received on Friday, 2 December 2005 07:30:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:12 UTC