W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: [whatwg] WebIDL and HTML5

From: Michael A. Puls II <shadow2531@gmail.com>
Date: Wed, 27 Aug 2008 17:14:38 -0400
To: "Boris Zbarsky" <bzbarsky@mit.edu>
Cc: "Web Applications Working Group WG" <public-webapps@w3.org>
Message-ID: <op.ugkdad1e1ejg13@tonja-ba9555948>

On Wed, 27 Aug 2008 08:34:03 -0400, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> Michael A. Puls II wrote:
>> 'textContent' takes a DOMString, null is not one
>
> Uh... Except null IS a DOMString according to the DOM specs.  Certainly  
> they implicitly treat it as one, and one of the clarifications that  
> WebIDL is making is making it clearer that null is a valid DOMString  
> value.
>
>> null is toString()ed to "null" and the textContent becomes "null".
>
> Except that's not what the spec for textContent says to do.  Please do  
> read the spec.  Carefully.

Yes, understood. Those were just my guesses for reasons why Opera does  
what it does.

>> I know Opera differs in these cases compared to Safari and Firefox, but  
>> from an ECMAScript point of view, Opera does what I expect.
>
> But it doesn't do what the DOM spec says to do in the textContent case.  
>   Sad, but there you are.

Understood.

>> 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?
>
> The DOM spec gets priority for methods it defines, just like in all  
> cases of host objects and methods.  There are no requirements for those  
> to follow all sorts of rules that native methods and objects have to  
> follow.  See the ECMAScript spec.

O.K. Thanks. That clears it up right there.

>> 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 _is_ odd.  But it's an established fact of life, and changing that  
> behavior is not acceptable at this point.

Understood.

> Too bad no one brought all this up back when the DOM specs were being  
> written.  Or maybe they did, and the non-ECMAScript users of the DOM  
> carried the day on the issue. Again, in other languages the fact that  
> null is a string is much more natural than in ECMAScript.

Yes, too bad.

Thanks


-- 
Michael
Received on Wednesday, 27 August 2008 21:15:26 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:27 GMT