Re: Some DOM related comments

Hi David.

I’ve been doing some similar tests recently on the ECMAScript bindings,
which I just now posted to the webapi list:

  http://www.w3.org/mid/20070602065924.GD11862@arc.mcc.id.au

liorean:
> In 1.3.1: I think the issues related to prototype delegation have to
> be addressed. More specifically:

Yes I think all of these things should be specified.  I’m meant to be
editing the Bindings4DOM spec for the Web API group, which will define
these things in some general manner.  Hopefully then HTML5 can reference
that spec and then mention any peculiarities required for web browsers.

> Finally: (Pretty sure this is not the realm of the HTML WG, but I'll
> mention it anyway.)
> The DOM should always specify whether a type is nullable or not and if
> nullable how DOM methods are to behave if passed null. Currently Node
> type properties may be null (e.g. Node.firstChild) but there is no
> text on whether methods with Node type arguments (e.g.
> Node.appendChild) may be passed null or what to do in those cases. If
> the Node type for properties is nullable but the Node type for
> arguments isn't then they should not be using the same type name but
> be distinct. If they are indeed both nullable types then the DOM
> methods need to specify the case of what to do with a null argument.
> The Node.insertBefore method has a case of the Node type argument
> refChild having a defined behaviour when passed null — thus suggesting
> Node type is indeed nullable in both cases — but this is not the case
> for many other Node type arguments to several DOM methods.
> Also ECMAScript allows any arguments to be sent to any function and
> formal parameters not present in the arguments sent to a function are
> set to undefined (meaning a missing argument and an argument of
> undefined should have exactly the same result), thus the ECMAScript
> bindings also need to specify what behaviour passing the wrong type of
> object gives. All major browsers currently handle these things very
> differently from each other, and not necessarily internally
> consistent:

Agreed.  The Bindings4DOM spec should provide some easy way to reference
such behaviour (nullable, convertable from different types and in what
ways, etc.).

> I'm of the opinion that if the error lies in the ECMAScript code
> passing the wrong type, that should always be defined to result in a
> certain DOMException being thrown and never result in an uncaught
> implementation specific exception, nor should which exception is
> appropriate be left uncertain.

I agree that which exception is thrown should be specified.  Do you
think it’s inappropriate to use a TypeError exception rather than
defining a DOMException for these errors where a value of the wrong type
is used?

-- 
Cameron McCormack, http://mcc.id.au/
 xmpp:heycam@jabber.org  ▪  ICQ 26955922  ▪  MSN cam@mcc.id.au

Received on Saturday, 2 June 2007 07:13:04 UTC