W3C home > Mailing lists > Public > public-html@w3.org > June 2007

Re: Some DOM related comments

From: liorean <liorean@gmail.com>
Date: Sat, 2 Jun 2007 09:54:15 +0200
Message-ID: <cee13aa30706020054y31d965feh164135a5fd4409ff@mail.gmail.com>
To: "HTML WG" <public-html@w3.org>

On 02/06/07, Cameron McCormack <cam@mcc.id.au> wrote:
> 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

I'll check that out.

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

Nice, I haven't paid enough attention to WebAPI it seems.

> > Finally: (Pretty sure this is not the realm of the HTML WG, but I'll
> > mention it anyway.)
[snip]
> Agreed.  The Bindings4DOM spec should provide some easy way to reference
> such behaviour (nullable, convertable from different types and in what
> ways, etc.).

Ah. When you mention it, I recall seeing there were the beginnings for
such a spec on the CVS, but it looked rather inactive having last been
modified in 2006-05-01.
<uri:http://dev.w3.org/cvsweb/~checkout~/2006/webapi/Binding4DOM/publish/Binding4DOM.html?rev=1.1&content-type=text/html;%20charset=iso-8859-1>

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

Not inappropriate at all, I think the ECMAScript NativeError objects
are preferable for any error as long as it does not break consistency
with the DOM specs. I suggested a DOMException since I thought other
consumers of the DOM than ECMAScript may want the same late handling
of type errors.
-- 
David "liorean" Andersson
Received on Saturday, 2 June 2007 07:54:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:45 UTC