- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 7 Dec 2005 12:34:11 -0800
- To: Ray Whitmer <ray@personallegal.net>
- Cc: Brendan Eich <brendan@meer.net>, www-dom@w3.org
On Dec 7, 2005, at 6:49 AM, Ray Whitmer wrote:
>
> On Dec 6, 2005, at 12:16 PM, Maciej Stachowiak wrote:
>
>> The problem is that your mode (3) is impossible. getAttribute can
>> return either empty string or null. How could you have a mode
>> where it complies with the standard by returning empty string, yet
>> ensures that the JS code will still work in a browser that returns
>> null? Proving that reduces to solving the halting problem.
>
> Mode 3 is for compliance testing with standards that also work in IE.
>
> So we wish to discourage use of getAttribute to check whether the
> attribute exists (fail if they do it).
>
> Therefore, calling getAttribute on a non-existant attribute in mode
> 3 would ideally throw an exception, so that any script that called
> getAttribute without knowing whether an attribute existed first
> would get an exception in this mode, because due to the ambiguity /
> tension between the specification and the status quo, there is no
> predicting what happens.
A mode that did this would not be compliant with the standard and
would fail the test suite. So really this is inventing a new kind of
nonstandard behavior. This mode would also reject some obvious idioms
that work with both the written spec and the de facto standard:
if (!e.getAttribute("foo")) {
// code to run if e is either empty or null
}
As well as breaking both compliant code and de facto standard code.
Furthermore, since the error only occurs at runtime, you might never
go through the code path where it comes up and so could never tell
your code was right.
I don't think adding a new mode that is both noncompliant *and*
incompatible with existing content would be very helpful.
Regards,
Maciej
Received on Wednesday, 7 December 2005 20:37:01 UTC