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

Re: [whatwg] WebIDL and HTML5

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 27 Aug 2008 08:34:03 -0400
Message-ID: <48B549BB.4070309@mit.edu>
To: "Michael A. Puls II" <shadow2531@gmail.com>
CC: Web Applications Working Group WG <public-webapps@w3.org>

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.

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

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

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

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

That's exactly the goal.  Garrett opposes it for some reason I can't 
quite pin down.

Received on Wednesday, 27 August 2008 12:34:53 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:11 UTC