W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2005

Re: [dom3core] getAttribute

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 6 Dec 2005 11:16:15 -0800
Message-Id: <7ACDA739-5D22-4079-94E2-26AAA8C77CAC@apple.com>
Cc: Brendan Eich <brendan@meer.net>, www-dom@w3.org
To: Ray Whitmer <ray@personallegal.net>


On Dec 6, 2005, at 2:39 AM, Ray Whitmer wrote:

> You should explain how this would occur, using the preferences the  
> way I described them in a previous message:
>
> (from my previous message on the topic)
>> Example of radio buttons:
>>
>> (1) * IE (default for almost users, let's label it as it is, IE)
>> (2) * Standards (claim 100% compliance if only the content were, not
>> used unless IE-incompatible content is found)
>> (3) * IE Standards Subset (non-treacherous for use by web authors so
>> they produce content that is both IE and standards compliant)
>>
>> Users use the mode (1) if IE compatible, non-standards-compliant is
>> the rule and they never need anything else.
>>
>> Web authors use mode (3) to test, which is designed to yield content
>> that always works under mode (1) while being standards compliant.
>>
>> Mode (2) is only needed by test suites or content that is otherwise
>> broken in IE.  If there is content that needs it, you otherwise had
>> no way to process it so having to flip a UI seems marginally better
>> than nothing.  Not a great solution, but in several ways superior to
>> the status quo.
> (end of self quote)
>
> How does this mode for web authors produce code that "might break  
> in almost all browsers"?  Mode 3 was proposed as an option that  
> produces code that should work in almost all browsers while also  
> complying with standards. Only if it is not correctly implemented  
> would it produce code that "might break in almost all browsers".   
> Please explain.

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.

Regards,
Maciej
Received on Tuesday, 6 December 2005 19:16:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:58 GMT