Re: appendChild exception missing from standard

On Mon, 11 Sep 2006, Hallvord R. M. Steen wrote:

> Understood. However, I have recently seen scripts where the authors depend on 
> this behaviour (exceptions being thrown if null or string is passed to 
> appendChild). Keeping this "implementation specific" means less 
> interoperability because some implementations will violate the expectations 
> of those authors. Hence I think it would be a good idea to state explicitly 
> what should happen in these cases.

One reason for not specifying it more is that the basic part of the DOM
specification serves both type safe and non-type-safe languages.

It would seem silly to Java users to create an exception for passing a
String in where a node, for example, is expected.

Null handling has also traditionally been a bit different even from one
Javascript implementation to another, and every time I try to describe the
current or historical handling on particular browsers I get into trouble,
even though I know some of the issues and worked on and represented Mozilla
for a few years.

It was to satisfy a particular Javascript implementations, for example, that
getAttribute was not permitted to return a null, but returns an empty string
for no attribute, which even Mozilla developers now seem to curse about who
said it was essential before, but there is no way even Java vendors who have 
suffered with it for years, will like to have their old implementations made
incompatible now.  They voted for it, and people have implemented based upon
their confidence.

I have been accused, I believe, in the past by a developer of your company of 
not being willing to listen to browser vendors or knowledgeable of their issues
on the very issue of getAttribute, which, among others, was spoiled by catering
to the browser vendors.  I am sorry I responded with an irritated tone.

If anything, some apparent flaws could be a result of listening too much to 
dominant browser vendors at the time rather than designing it in a way that
made sense and requiring bizarre type situations to be fixed on a per-binding
basis.

That is exactly what the specification is suggesting in this case,
raise exceptions if something bad is passed that the specification does not
define should be passed.

If it affects interoperability, it might be worth making a test suite.  I think
there are other very important things that should be done by browser vendors
towards interoperability, for example, giving web masters a super strict mode
where any non-portable behavior (in violation of a standard, known to be
broken or incorrectly implemented on major browsers, etc.) raises an exception.
The horrible tag/JS soup we have today is caused by browsers trying to accept
anything and thus being a treacherous yet the most popular tool for webmasters.

I would test my web pages against Opera, for example, if it had such a mode,
so I could be confident that it works in IE too.  Not that Opera probably
wants to bloat their product with such a tool, but someone who like yourself
makes a study of the portability issues needs to make it into a tool that
can actually be used to improve web pages and thereby make their product into
a more-credible test platform, rather than just a less common one that breaks
in yet different places.

Back to the topic:

Although it makes the bindings harder to work with some times, it really has
been a great advantage in other ways, to have Java and Javascript sharing the
same specification.

To get real work done on the DOM specification, a working group would have to
be tasked with it with active input and testing from more than one browser
vendor.

Ray Whitmer

Received on Tuesday, 12 September 2006 00:17:49 UTC