Re: [dom3core] getAttribute

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