Consider you have a massive page of XML. Now what happens when:
a) the page stops loading half-way?

I think people are missing something here; XML only requires that the parser throw a fatal error and stop processing the stream. It doesn’t require applications to throw away what they have received from the parser thus far. If a browser wants to display half a page, it can.

But the actual point of the post was that I believe the principles behind Postel”s Law need to be re-examined. Perhaps they”re still sound, but they”re taken much too far

As I’ve said before, Postel’s Law is only beneficial when both sides keep up their end of the deal. Web authors aren’t conservative in what they send, so accepting it liberally (“being a doormat”) causes chaos. XML’s rule is obviously an attempt to stop being a doormat.

I”m also curious as to why you limit your discussion to welformedness

Whether something is well-formed or not is a question of syntax. It’s difficult to derive structure from a syntactically broken document. The job of transforming syntax into structure is entirely the XML parser’s job, and it should happen the same way for all document types.

Whether a document is valid or not is a question of structure. It may or may not be possible to recover from structural errors – whether it’s possible or not is application-dependent, so it makes no sense to apply a general rule to all XML document types.

Validity and well-formedness are two different things and are properties of two entirely different conceptual layers. Assuming that what applies to one also applies to the other is a mistake.

Eric Meyer wrote a post on his weblog that being liberal in what you accept as is currently done with HTML is bad. I of course wholeheartedly agree. This post elaborates on well-formedness in XHTML and SVG.

What I love about the comments so far is that everyone”s acting like I advocated forcing rigor onto the display layer starting tomorrow, and damn the consequences. Did I? No.

But by saying “if IE did [start to enforce wellformedness], you can be sure that people would fix their markup”, you did rather invite the discussion of what the actual consequences of such a move would be.

I’m also curious as to why you limit your discussion to welformedness – after all it’s not like the parser is the only UA layer that is affcted by the content recieved. Something like

<table><h1>Foo <li> </li> </h1> </table>

is totally wellformed yet utterly invalid code. So in the context of your overall thesis I assume you would have browsers reject any html that contained this type of code. With that in mind, I find it very hard to accept that “it isn”t like well-formed HTML is substantially more difficult to grasp than is tag-soup HTML.”. For static, hand authored pages, sure, it’s not that much more difficult. The real difference is that server side tools that can be relied on to produce valid (or even, much easier, well-formed) markup are much harder to produce. SSI and PHP – the two easiest ways in to building dynamic sites would never have been produced because messing with strings isn’t reliable enough where the choice is between correctness and total faliure. Instead people would be forced to use more complex frameworks like XSLT (clearly this didn’t exist at the time but the point is that this is the type of technology that would have developed instead of the simple technologies that are prevalent today). The additional complexity of making sure that a site used valid code would require effort to be spent on that rather mundane task rather than improving the actual content. The combination of a lack of accessible technologies and high difficulty of site building would, I expect, have killed the kind of pioneer-style low budget startup that drove innovation in the early commercial web. That, not the difficulty of hand authoring valid code, is why a web that enforced validity would have been closer to Evan’s 10,000 physics papers than the web of today.

In any case, expecting the browser makers to produce a browser that enforces validity is like expecting a pencil to balance on it’s tip – sure it’s an equlibrium but it’s highly unstable to small peturbations. In this case, a small peturbation might be a bug – say a browser continuing rendering when an <img> element with no alt attribute was encountered. Since, as experience shows, people test browsers rather than checking specs, there would be significant pressure for other browser makers to implement the quirk (this still happens of course, with almost every oddity in IE being replicated in code for all other browsers). Worse, there’s a significant competitive advantage in being able to render pages that no other browser can render since users care more about sites rendering than the browser they use. The people making browsers know this and have used it to their competitive advantage. So it’s practically impossible to imagine how strict error checking could have been enforced through the explosive growth of the web.

So, whilst I agree that we’d all be better off today if people used correct markup, I’m deeply sceptical that this would have been desirable in the past and furthermore don’t believe, captalism being what it is, that such a situation could have been maintained. I prefer to think of Postel’s law as a dictum for authors: Clients will be liberal in what they accept but not all clients are created equal so you should be conservative in what you send.

I elaborated a little on well-formedness in XHTML and SVG on my weblog.

~Grauw

There”s a lot of broken SVG out there on web pages now, because Adobe”s XML parser is non-compliant and accepts non-well-formed XML, without namespaces and using undefined namespace prefixes, unclosed tags, etc.

But, I think that given that Firefox 1.1 will require the SVG to be well-formed for it to work (yeah and Opera too), that Firefox will be able to force this problem in the right direction, and cause people fix their SVG. After all, Firefox is the first major browser distribution with SVG built-in.

(and no, I don”t consider Opera a major browser distribution right now, and besides it”s only got SVG Tiny, and that not without issues).

After all, it isn”t like well-formed HTML is substantially more difficult to grasp than is tag-soup HTML. It”s a pretty simple language either way; I”d even argue it”s simpler with rigor than without.

You”re absolutely right :).

After all, it isn’t like well-formed HTML is substantially more difficult to grasp than is tag-soup HTML. It’s a pretty simple language either way; I’d even argue it’s simpler with rigor than without.

But the actual point of the post was that I believe the principles behind Postel’s Law need to be re-examined. Perhaps they’re still sound, but they’re taken much too far (as Scott said, “Remember, Postel”s Law… doesn”t say to be a doormat”). Perhaps they’re no longer appropriate for the Internet. Perhaps they aren’t taken far enough. I personally think it’s one of the first two, but without a serious contemplation of how the Law has been applied and the consequences of doing so, we’ll never even have a chance to do better.

In the past eleven years, I”ve seen browsers tighten up their behavior on multiple occasions, and on every occasion, authors made the necessary corrections.

Forcing well-formed (let alone valid) HTML on the world would be orders of magnitude bigger than any of the small changes that people have made in the past. It would break well over 99% of the sites on the web. Even if webmasters took the time to upgrade their markup to be valid, there’d etill be a huge problem – very few backend systems are designed to enforce wellformedness. That would make creating DOS-style attacks very very easy – just get the page to include some content in the wrong character set or find a way to include some unclosed tags. Sure, it wouldn’t work everywhere but I bet a huge number of systems have this kind of problem somewhere simply because very few server-side applications have been designed to ensure well-formedness (for example by using a compliant XML parser).

Indeed the fact that content must be well-formed is, IMHO, responsible for the current faliure of XML on the web. Until XML gets CSS-style well-defined error handling it is unlikely to gain any sort of widespread adoption. Indeed I still feel that it’s more likely that a vendor will release a ‘liberal’ XML-parser than XML in its current form will be widely used for human-consumed documents.

If browsers had done it from the beginning, the WWW would consist of a collection of about 10,000 physics papers.

Indeed. And if it changed now, all that would be left is about 1000 blogs.

If a document fails to load completely for any reason, it is the same situation as if the document had been transmitted in full, but was incomplete in itself

So, if I load a large document, have it incrementally render, notice that the part I’m interested in has loaded, and press stop, you think that the document should be replaced by the YSOD? Or you think that incremental rendering of XML documents should be forbidden?

The scenarios you pointed out are not really valid, IMO. If a document fails to load completely for any reason, it is the same situation as if the document had been transmitted in full, but was incomplete in itself. I for one would not like to see the client app make any “best guesses” about the rest of the document’s content.

If you liken the document content to a recipe (in that it contains instructions for what the client application displays / processes), you would not want it to get to an instruction to “put the thing into a hot oven”, and then not be aware of how long to leave it there, or how to take it out. In HTML, the error-correction is not so bad – there aren’t many instances where a misinterpreted block of code will cause undesirable behaviour – but if you are expecting an XML document of application configuration data, or some other set of instructions, the implications of a missing tag or block of data are enormous.

If IE did it, the flow of users to Firefox would become a full-on stampede.

If browsers had done it from the beginning, the WWW would consist of a collection of about 10,000 physics papers.

I disagree. In the past eleven years, I’ve seen browsers tighten up their behavior on multiple occasions, and on every occasion, authors made the necessary corrections. Users didn’t stampede anywhere, even when there were choices. They didn’t have to, because sites didn’t stay broken for very long.

Forcing rigor into the display layer would be like forcing UNIX sys admins to replace all their shell scripts with Java JARs.

I think that’s just a wee bit of an overstatement.

Remember, Postel”s Law says to be “liberal” in what you accept from others, it doesn”t say to be a doormat.

Exactly. It isn’t Postel’s Law that’s at fault. The problem is what this broken software is doing with the input.

And would that be so bad, even for HTML? After all, if IE did it, you can be sure that people would fix their markup. If browsers had done it from the beginning, markup would not have been malformed in the first place.

If IE did it, the flow of users to Firefox would become a full-on stampede.

If browsers had done it from the beginning, the WWW would consist of a collection of about 10,000 physics papers.

The web is successful because from the beginning, it has always been very easy to create content. The language of the web matches the web’s main use cases. Obviously the hardcore geeks want to do open up more sophisticated use cases, and a more rigorous syntax would make this easier. However, for the vast, vast majority of existing use cases — searching for stuff, reading stuff, submitting form data so you can buy stuff — the display layer does not need to be rigorous. Forcing rigor into the display layer would be like forcing UNIX sys admins to replace all their shell scripts with Java JARs. Shell scripts do the job. Java would be massive overkill. Pick your tools wisely.