W3C home > Mailing lists > Public > public-html@w3.org > April 2007

Re: A Compromise to the Versioning Debate

From: Henri Sivonen <hsivonen@iki.fi>
Date: Mon, 16 Apr 2007 12:04:11 +0300
Message-Id: <9C9964FC-C752-44DD-85FA-38E71D8F1DCE@iki.fi>
Cc: Lachlan Hunt <lachlan.hunt@lachy.id.au>, public-html@w3.org
To: Dão Gottwald <dao@design-noir.de>

On Apr 16, 2007, at 11:18, Dão Gottwald wrote:

> Henri Sivonen schrieb:
>>> <!DOCTYPE html>
>>> <!--[mode = IE8]-->
>>> <html>
>>> ...
>>> It doesn't really matter what syntax you use for it.
>> It sure does. If Microsoft insists on more switches, the sane way  
>> is to use an attribute on the root element as it survives through  
>> various XML APIs. I have been involved in hacking a SAX-based tool  
>> to preserve (against my explicit advice) IE6 quirks modeness in  
>> XHTML served as text/html. (The XML decl thing.) It was ugly.
> Why should it survive?

If it doesn't survive, the tool that zapped it will be blamed for  
breaking the page.

Scenario 1 (Good):
  * Microsoft doesn't insist on IE-specific switches.
  * The WG doesn't spec version identifiers.
  * (X)HTML5 gets the standards mode and bug fixes apply.

Scenario 2 (Bad):
  * Microsoft insists on switches tied to IE versions.
  * The WG vehemently objects.
  * The conformance definition doesn't leave room for an attribute- 
based switch on the root element.
  * Microsoft bakes the switch into syntactic sugar to make the  
switch invisible to conformance checkers.
  * The switch gets dropped by architecturally sound XML toolchains  
that do not round-trip syntactic sugar or that drop comments as  
permitted by the XML spec.
  * Documents that pass through such toolchains have their behavior  
changed in IE.
  * Tool vendors are pre-emptively horrified in order to avoid their  
customers getting horrified.
  * Tool vendors feel compelled to sacrifice sane software  
architecture and make the ugliest hacks to preserve the IE versioning  

Scenario 3 (Not quite as bad):
  * Microsoft insists on switches tied to IE versions.
  * The WG gives MS an attribute on the root element.
  * The attribute is naturally round-tripped by XML toolchains.
  * The harm to intermediate tool vendors is minimized even though  
the impact on browsers stays as bad.

> IE is the only browser who needs this, hence the proprietary  
> conditional-comments thingy. Other browsers don't want to switch;  
> they already handle the standards mode like the next IE is supposed  
> to handle <!DOCTYPE html>.

That's not the point.

True story:

A server-side software vendor was developing a product that parsed  
customer-supplied XHTML documents using a SAX parser, injected some  
stuff in a SAX pipeline, serialized as Appendix C XHTML and served as  
text/html. The lead developer worked on a Mac and everything seemed  
to work out just fine. Then the product was tested with a real  
customer-supplied layout and with IE6. (This happened when IE6 was  
the most recent IE.) The layout broke. The reason was that the  
customer-supplied document had an XML declaration (quirks mode in  
IE6) but the serializer did not emit an XML declaration (standards  
mode in IE6). Having full data about the cause of the problem and  
having an assessment that the next IE would likely fix the bug, the  
company leadership chose to sacrifice developer time, real money and  
architectural elegance in order to avoid the product exposing the IE  
bug or the customer's bad CSS practices to the customer. The product  
was hacked to round-trip the presence/absence of the XML declaration  
even though it wasn't part of the data that would naturally flow in a  
SAX pipeline.

If Microsoft insists on a switch, at least the damage can be  
contained somewhat if the switch is in the data that is exposed via  
the SAX2 ContentHandler interface. (This is not meant to be a SAX- 
specific statement but a practical formulation that conveniently  
covers the needs of other XML APIs as well.)

Henri Sivonen
Received on Monday, 16 April 2007 09:04:37 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:18 UTC