[whatwg] WebIDL and HTML5

[Garrett Smith]

On Tue, May 6, 2008 at 4:04 AM, Ian Hickson <ian at hixie.ch> wrote:
>
> heycam -- see at the end for a request for WebIDL.
>
> On Mon, 25 Apr 2005, Brad Neuberg wrote:
>>
>> True, but having prototypes on DOM objects can be extremely useful and
>> provide all sorts of very powerful options.  Mozilla allows manipulation
>> of the prototype object on DOM objects (except for removing the original
>> native methods and attributes, for security reasons).  Unfortunately, IE
>> doesn't support this, so this ability can't really be used in practice.
>

Nor should it be. For any environment. It is a good way to create bugs
and confuse programmers. Anyone who says that this is "misfortunate"
ought to say why he thinks this is so.

> WebIDL now requires this.
>

Requires what?

>
> On Thu, 11 May 2006, Dean Edwards wrote:
>>
>> At the moment, DOM objects are specified in a language neutral way.
>> That's fine. However, this makes these objects uninteresting and
>> cumbersome to script with.
>>
>> Mozilla has a more integrated programming environment. It exposes DOM
>> objects as native JavaScript objects. That means I can do things this
>> like this:
>>
>> Object.prototype.foo = "bar";
>> alert(document.body.foo);
>>
>> ==> "bar"
>>
>> A trivial example but it demonstrates that the DOM and JavaScript are
>> not totally separate on a Mozilla platform. This is very cool. 8-)
>
> WebIDL now requires this.
>

Can you elaborate on that statement?

>
>> It would be great if NodeLists were subclasses of JavaScript Array
>> objects (especially with the introduction of Mozilla's Array Extras
>> [1]). This makes iteration over DOM queries more flexible.
>

No, it doesn't. You did not prove that there is something that is
preventing you from accomplishing whatever it is you are trying to
accomplish. I don't believe that this can be proven. Please post your
use case.

> You can assign the Array methods to the NodeList prototype, they're
> generic.
>

Was there any thought that went into that statement?

This is horrible advice for several reasons:

1) Modifying host objects with new properties is a good way to create
bugs and confuse developers.
2) NodeList is an interface and should not have any implementation.
Even in browsers that expose a NodeList object, it cannot be
guaranteed
3) You answered a question for which no need was demonstrated, and
provided no example.
4) Calling any of the array methods on a NodeList would obviously
fail. We can take a look at push, for example:-

javascript:try{ alert(Array.prototype.push.call(document.childNodes));
} catch(ex){alert(ex.message);}

Should err out in step 7 of push attempting to set the "length" property.

| 15.4.4.7  Array.prototype.push([ item1[, item2 [,...]]])
|
|   The arguments are appended to the end of the array,
| in the order in which they appear. The new length of the array
| is returned as the result of the call.
|
|   When the push method is called with zero or more arguments
| item1, item2, etc., the following steps are taken:
|
| 1. Call the [[Get]] method of this object with argument "length".
| 2. Let n be the result of calling ToUint32(Result(1)).
| 3. Get the next argument in the argument list; if there are no more
|arguments, go to step 7.
| 4. Call the [[Put]] method of this object with arguments ToString(n)
|and Result(3).
| 5. Increase n by 1.
| 6. Go to step 3.
| 7. Call the [[Put]] method of this object with arguments "length"
|and n.
| 8. Return n.

We could also see how easily [[put]] method would not work as Array
[[Put]]. For example, setting a "2" property:-
javascript:alert(document.childNodes[2] = 1);

will add a new property with name "2"
javascript:alert(document.childNodes[2]);

and will not update the length.

javascript:alert(document.childNodes.length);

Modifying host objects is a very bad idea. NodeList is an Interface.
An interface should have no implementation. Even if you really wanted
to follow Ian's advice, it wouldn't work.

This is probably what led up to the dojo.NodeList and may have
influenced Ian in his Web Forms 2.0. Ian's advice is quite bad.

(more top posts)

>
> On Sun, 21 May 2006, Dave Hodder wrote:

[snip]

More...

> On Sat, 2 Jun 2007, Anne van Kesteren 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 Mon, 4 Jun 2007, Jonas Sicking 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 Mon, 4 Jun 2007, Michael A. Puls II 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.
>>
>> The way IE and Opera do "null" doesn't seem to be just limited to
>> innerHTML.
>
> On Tue, 5 Jun 2007, 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.
>

I agree. We can see that IE does not always.

javascript:void(document.body.style.color = { toString: function()  {
return "#900"; } })

Won't take that ToString to call the objects' toString.

I agree that this should be specified.

> On Mon, 4 Jun 2007, Maciej Stachowiak 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".

That would be the ToString algorithm. Please see section 9.2.

>
> I think what we need is for WebIDL to have annotations for these cases,

Why?

A simple call to ToString for setting string values is all that needs
to be said.

> which can be prefixed in front of any occurance of "DOMString" in any IDL
> block, and then we can work down the APIs and check each DOMString
> occurance and work out which the UAs are doing. Say:
>
>   [Null=Null, Undefined=Null]
>   [Null=Null, Undefined=Empty]
>   [Null=Empty, Undefined=Empty]
>   [Null=Null, Undefined=String]
>   [Null=Empty, Undefined=String]
>   [Null=String, Undefined=String]
>
> ...so that we can do, e.g.:
>
>   Window open([Null=String, Undefined=String] in DOMString url,
>               [Null=String, Undefined=Empty] in DOMString name,
>               [Null=Empty, Undefined=Empty] in DOMString features);
>
> ...or whatever is appropriate.
>

Why such complexities?

> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL