[whatwg] WebIDL and HTML5

[Ian Hickson]

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.

WebIDL now requires this.


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.


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

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


On Sun, 21 May 2006, Dave Hodder wrote:
> 
> Should Web Applications 1.0 make some kind of reference to RFC 4329?  
> It defines the application/ecmascript and application/javascript media 
> types; it also defines text/javascript and text/ecmascript but marks 
> them as "obsolete".
> 
>     http://www.ietf.org/rfc/rfc4329.txt
> 
> I would suggest referring to it but noting that text/javascript and 
> text/javascript;e4x=1 may be preferable for compatibility with current 
> user agents.

I don't see much point in referring to RFC 4329.


On Thu, 17 May 2007, Philip Taylor wrote:
> 
> What happens when someone calls drawImage(image, dx, dy, dw)? That's too 
> few arguments for "void drawImage(in HTMLImageElement image, in float 
> dx, in float dy, in float dw, in float dh)", but too many for "void 
> drawImage(in HTMLImageElement image, in float dx, in float dy)".

WebIDL defines this now (though I haven't done the maths to work out if 
this throws a TypeError or invokes one of the functions with an undefined 
argument).


On Wed, 16 May 2007, Darin Adler wrote:
>
> Typically in JavaScript, too few arguments just means that each 
> additional argument is treated as undefined.

Indeed.


[snip various e-mails about providing a hashcode for nodes]

I intend to defer this to the ES group, as it is a generic language issue.


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.

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

For both DOMString attributes and DOMString arguments, we have the 
following ways to handle null and undefined:

   null -> null
   null -> ""
   null -> "null"

   undefined -> null
   undefined -> ""
   undefined -> "undefined"

...which in practice are combined in the following ways:

   null -> null, undefined -> null
   null -> null, undefined -> ""
   null -> "", undefined -> ""
   null -> null, undefined -> "undefined"
   null -> "", undefined -> "undefined"
   null -> "null", undefined -> "undefined"

I think what we need is for WebIDL to have annotations for these cases, 
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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'