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

Re: [dom3core] getAttribute

From: Ray Whitmer <ray@personallegal.net>
Date: Thu, 1 Dec 2005 06:20:11 -0700
Message-Id: <D31BD7AA-9276-406E-AD22-15761DE2219F@personallegal.net>
Cc: Anne van Kesteren <annevk@opera.com>, ML-www-dom <www-dom@w3.org>
To: Kasimier Buchcik <K.Buchcik@4commerce.de>

On Dec 1, 2005, at 4:16 AM, Kasimier Buchcik wrote:

> But maybe the damage is really already done, and DOM implementations
> of browsers will differ from other DOM implementations; not exactly
> the intention of a DOM API, is it?

I don't think there is sufficient wiggle room to explain it as a  
binding difference, but I could be wrong. I don't remember well now.  
I know we revisited it any number of times and if we had had early  
consensus to change it, we would have. If anyone was arguing against  
this empty string return initially, I would be sure that it was the  
Java camp (which I was part of in DOM level 1), who now appear to be  
the only ones conforming.

I believe that this is what the DOM test suite is for, and that a  
test should be submitted, if one does not exist, to identify this  
incompatibility of some browsers with the DOM level 1 standard (which  
in many cases their representatives clearly drafted and approved).

Just because there is a compliance test they fail doesn't mean they  
have to care, and some obviously will not, but it clearly identifies  
the issue of contention and just go back and look at the names of the  
participants on the DOM Level 1 standard, level 2, etc.

Perceived compliance of browsers is a shallow illusion, and the test  
suite will never prove compliance.  It should be possible in theory  
to at least convince those who drafted it to comply, which would seem  
to be its value, and the issue here is such a simple one, they should  
fall in to line and tell people to fix their web pages. If not, well  
what did we ever need a W3C DOM WG for if the implementers are just  
going to fight it out anyway by their dominance.

We could suggest other simple level 1 tests that Java implementations  
would generally pass and recent browser implementations would fail  
but few web pages use the functionality precisely because major  
browsers fail to implement it and the test suite fails to implement  
it, so it is not at issue here, i.e.:

<p id='foo'>Test</p>
<script>
alert(document.getElementById('foo').getAttributeNode('id').firstChild);
</script>

Try it on Safari, and returns null.

Try it on Firefox and it actually works (I don't believe it always  
did on Mozilla, good work Johnny) and gives you a text node.  Of  
course, in Firefox, if I change it to:

<p id='foo'></p>
<script>
alert(document.getElementById('foo'));
</script>

it produces a null, which seems wrong, too, because I often want  
Javascript to change the text of a paragraph that starts empty, not  
that I can't put something there to work around the error (Safari  
works correctly in this case).  Of course, if I change it to... then  
Firefox works and Safari does not... Let me know if you want more  
examples...

Ray
Received on Thursday, 1 December 2005 14:45:47 GMT

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