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


From: Ray Whitmer <ray@personallegal.net>
Date: Sat, 3 Dec 2005 08:46:42 -0700
Message-Id: <777C36CC-82F8-477E-AB4F-ACF26D402ABF@personallegal.net>
Cc: Curt Arnold <carnold@houston.rr.com>, DOM mailing list <www-dom@w3.org>
To: Maciej Stachowiak <mjs@apple.com>

On Dec 3, 2005, at 3:25 AM, Maciej Stachowiak wrote:

>> A configuration option in the browser that would allow the user  
>> (likely developer) to change between standard conformant and  
>> compatibility mode.
> ...
> It would create a world where users would have a choice between  
> some sites working but not others.

I can't parse what you just said.

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

> Current generation browsers aim for a small and understandable set  
> of preferences.

I fully understand this objection, and I would hope for something  
better, but only implementing IE behavior seems worse and for IE- 
inspired content, if you make that the default, no intervention is  
required by the user.

> If there is to be a switchable behavior here, it should be  
> switchable by the developer of the site, not the user.

I do not follow your statement.  Developer-switcher seems clearly  
less workable than user settings if the problem stems from the  
inability to think of a reasonable way to get the developer to fix  
the broken content, which seems just as easy as otherwise causing the  
developer to switch.  I agree that the developer of the site should  
take responsibility, but if he does that the problem is already solved.

There are other possible approaches, but you may need to separate out  
each behavior and you have to choose the quirks you are willing to  
live with and what you can do given the abilities of your particular  
environment to pursue such contradictory behaviors.

Off the top of my head:

For getAttribute on a non-existent attribute return a special  
"quirky" empty-string object manufactured for the situation, which  
has the characteristic that in addition to normal string behaviors it  
returns true in a comparison with a null, so that someone using it as  
a string, gets the expected behavior, and someone comparing against  
null gets expected behavior.

For WRONG_DOCUMENT_ERROR you do not throw the error unless you pre- 
detect a handler that catches it.

How easily these sorts of quirky behaviors can be hacked into your  
engine remains to be seen, depending upon design.  I do not like any  
of these -- I think standards adherence should be cleaner -- but that  
is just me, and people only going for the end effect of compatibility  
with ordinary IE-inspired content and standards may have less problem  
with these sorts of approaches.

Ray Whitmer
Received on Saturday, 3 December 2005 15:46:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:12 UTC