- From: Dan Connolly <connolly@w3.org>
- Date: Wed, 25 Oct 2006 14:52:02 -0500
- To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
- Cc: www-tag@w3.org
On Tue, 2006-10-24 at 22:17 +0100, Henry S. Thompson wrote: [...] > Is the indefinite persistence of 'tag soup' HTML* consistent with a > sound architecture for the Web? [...] That description is good enough for me... > [...] I'd much prefer to see discussion > about the architectural issue itself. . . The following is a particularly interesting scenario, I think. It shows we need to look at the macro interactions as well as the micro interactions. Forwarded with permission... On Tue, 2006-08-22 at 01:06 +0000, Ian Hickson wrote: [...] > The second, and more important reason, is illustrated by this scenario: > > Alice writes a document that uses the new feature. It is handled as tag > soup in legacy UAs, and is handled according to XML rules in new UAs. > Everything is fine. > > Bob, who only has a legacy UA, edits the document. The document seems to > work fine to Bob, because in his legacy UA it is handled according to > tag soup error handling rules. > > Alice, using her new UA, tries to access the document. However, > unbeknownst to Bob, he introduced a well-formedness error. Alice's > browser is therefore required, according to XML rules, to show an error > message. > > Alice complains to her UA vendor. > > This happens many thousands of times with different people. > > The UA vendor stops using an XML processor, because otherwise he will > lose his market share. > > This isn't hypothetical; it is the situation we are in today with XHTML > documents sent as text/html. UAs cannot use XML parsers to parse these > XHTML-sent-as-text/html documents, even if they could find a way to detect > them, because a huge fraction of such documents are ill-formed and would > thus render *worse* in new UAs than in legacy UAs. > > Users won't upgrade to a browser if it renders documents worse. -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Wednesday, 25 October 2006 19:52:11 UTC