Re: [whatwg] WebIDL and HTML5

On Tue, 26 Aug 2008 23:20:16 -0400, Boris Zbarsky <bzbarsky@mit.edu> wrote:

>
> Garrett Smith wrote:
>> I have created a demo which expects that setting textContent to null
>> will have no effect, as per DOM Core 3.
>
> Except that's not what DOM Core 3 says.  Please do read what it says.  
> Carefully:
>
>    On setting, any possible children this node may have are removed
>    and, if it the new string is not empty or null, replaced by a
>    single Text node containing the string this attribute is set to.
>
> So.  On setting all children are removed.  If the string is not empty or  
> null, they are then replaced by a single Text node, etc.  If it's empty  
> or null, the kids are removed and that's it.  It would perhaps help to  
> write this out as a step-by-step list instead of having a moderately  
> complex grammatical structure with a subordinate clause, but the meaning  
> is still the same.
>
> As for your test, sounds to me like Firefox and Webkit implement what  
> the spec says, and Opera is just buggy here.

Couple examples:

Example 1:
var div = document.createElement("div");
div.textContent = null;

'textContent' takes a DOMString, null is not one, null is toString()ed to  
"null" and the textContent becomes "null".

Example 2:
var div = document.getElementsByTagName("div")[0];
div.style.display = "none";
div.style.display = null;

'display' takes a DOMString, null is not one, null is toString()ed to  
"null" and since "null" is not a valid value for the display property, the  
new declaration is ignored and the display remains at 'none'.

I know Opera differs in these cases compared to Safari and Firefox, but  
 from an ECMAScript point of view, Opera does what I expect.

With that said, if that's a behavior of ECMAScript and the DOM spec  
clashes, which one gets priority and in what situations and why?

Although I understand why it might be desired to have null have the same  
effect as "", it seems odd to be so inconsistent across different things  
in the DOM and inconsistent with ECMAScript (which exposes the DOM to  
users, in browsers).

It'd be nice if the behavior was the same for all DOM things taking a  
DOMString. But, since that probably can't happen because of compatibility,  
I guess it would be great to have a way to show each and every special  
case so browsers don't differ and break pages.


-- 
Michael

Received on Wednesday, 27 August 2008 07:20:38 UTC