- From: Ray Whitmer <ray@personallegal.net>
- Date: Sat, 3 Dec 2005 08:46:42 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Curt Arnold <carnold@houston.rr.com>, DOM mailing list <www-dom@w3.org>
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