Re: [dom3core] getAttribute

Hi,

On Thu, 2005-12-01 at 06:20 -0700, Ray Whitmer wrote:
> 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.  

The difference I see in the usage of getAttribute() is that
it is not defined not to give information whether an attribute
node exists or not; it returns "" in both cases. If it would
return NULL then it would indicate that the attribute node is
not existent. Isn't this a clear API difference?

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

Yeah, I guess if would be easier for Java to return NULL in such a
case rather than the having the overhead of returning an empty string.

> 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  

It will surely never prove compliance if one doesn't seek to
be compliant. I'm a bit scared of such statements being taken as
a justification for not trying it.

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

I agree with you.

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

No, I'm not interested in more examples of how browsers fail to
implement the DOM API.

Regards,

Kasimier

Received on Thursday, 1 December 2005 14:24:58 UTC