- From: liorean <liorean@gmail.com>
- Date: Tue, 5 Jun 2007 04:52:20 +0200
- To: "HTML WG" <public-html@w3.org>, "Web APIs WG (public)" <public-webapi@w3.org>
[Sorry for the double of this post to those who are members of both public-html and public-webapi] On 02/06/07, Anne van Kesteren <annevk@opera.com> wrote: > For .innerHTML = null Opera and Internet Explorer act as if the literal > string "null" was used. Firefox acts as if "" was used. > > For .innerHTML = undefined Opera, Firefox and Internet Explorer act as if > the literal string "undefined" was used. On 6/4/07, Jonas Sicking <jonas@sicking.cc> wrote: > I'd really dislike having to have this one property behave differently > than other text properties in the DOM. How do opera/ie deal with other > text properties like .src, .id, .textContent? On 05/06/07, Michael A. Puls II <shadow2531@gmail.com> wrote: > For .src and .id, IE and Opera set "null". > Opera does the same for textContent. > > For .src, this obviously means that IE and Opera will then return the > directory of the page + "null" where as FF will return the URI to the > page. On Jun 4, 2007, at 5:45 PM, liorean wrote: > Seems to me like they are simply using the ECMAScript ToString > algorithm, unless I'm mistaken. That's probably a good thing to > specify for this, too. On 05/06/07, Maciej Stachowiak <mjs@apple.com> wrote: > I think DOM properties (and sometimes methods and function arguments) > vary on this. Some use the raw ECMAScript ToString algorithm. Others > additionally map the null value to the empty string instead of > "null". Still others map the undefined value to "undefined". Some do > both. I am pretty sure that for compatibility reasons you can't just > do the same for each, so we may as well just define and test the > legacy behavior for each one. Whatever is most common can be the > default, and others can be marked up in the IDL appropriately. I know. But I think this should be very clearly specified in the DOM specification and ECMAScript bindings, and more specifically I think that the correct way to specify it is as follows: Type conversions should follow the rules used for the specific language. In the case of ES3: - If the DOM requires a DOMString, since DOMString is mapped to ES3 String, the type conversion should be through ToString(value). - If the DOM requires an unsigned long, the ES3 spec way of handling this is to take ToNumber(value) and compare it to ToUInt32(value). If not equal an ES3 TypeError should be thrown, if equal the return value from ToUInt32(value) should be cast from Number to UInt32. (This conversion is on the ES3 side of the function call, so for example CharacterData.substringData would not throw INDEX_SIZE_ERR on negative offset or count since the language conversion would already have failed before the function was entered.) - If the DOM requires a boolean, there's two possibilities: 1. It's a TypeError if the value is not a Boolean. (I.e. a strict comparison.) 2. The DOM is sent the return value of ToBoolean(value). I don't have enough data on browser behaviour to say if either conversion is the most appropriate in general or if this have to be dealt with in the ECMAScript bindings on a per case basis. I suspect the latter. - If the DOM requires a Node*, a TypeError should be thrown if the value is neither null nor an object that has one of the following properties: 1. It's [[Class]] internal property has a value of "Node". 2. It's [[Class]] internal property contains a type that also has to implement the Node interface. 3. It's [[Class]] internal property contains a derived type of the Node interface object. Also, and this is an area the DOM specifications are very bad at defining, all uses of Node type should specify the exact handling of null values. * Which seems to be a nullable type if you read the DOM spec a bit. The spec really should make sure to specify the types it uses more exactly, especially whether types are nullable or not. - Analogous for other DOM interface types. On 05/06/07, Maciej Stachowiak <mjs@apple.com> wrote: > I think this overlaps with the Web API group's DOM bindings for > ECMAScript project. Yes it does, so I added WebAPI as CC. -- David "liorean" Andersson
Received on Tuesday, 5 June 2007 02:52:27 UTC