Comments on: Markup Madness, Part One: HTML/XHTML Deathmatch http://www.allpeers.com/blog/2007/08/23/markup-madness-part-one-htmlxhtml-deathmatch/ The official AllPeers blog Mon, 01 Dec 2008 21:21:13 +0000 http://wordpress.org/?v=2.2 By: Laurens Holst http://www.allpeers.com/blog/2007/08/23/markup-madness-part-one-htmlxhtml-deathmatch/#comment-117110 Laurens Holst Wed, 10 Oct 2007 21:24:12 +0000 http://www.allpeers.com/blog/2007/08/23/markup-madness-part-one-htmlxhtml-deathmatch/#comment-117110 Yuri, if you’re talking about an XML toolchain, then I don’t see how a browser could be served a document with a markup error (rather: a well-formedness error). It would either not give trouble at all, or already give parsing errors in the toolchain. If it would send unacceptable content to the browser, then that’s a sign that there must be something wrong with the XML toolchain, which I’d rather find out than leave undetected. Yuri, if you’re talking about an XML toolchain, then I don’t see how a browser could be served a document with a markup error (rather: a well-formedness error). It would either not give trouble at all, or already give parsing errors in the toolchain. If it would send unacceptable content to the browser, then that’s a sign that there must be something wrong with the XML toolchain, which I’d rather find out than leave undetected.

]]> By: Juri Pakaste http://www.allpeers.com/blog/2007/08/23/markup-madness-part-one-htmlxhtml-deathmatch/#comment-99101 Juri Pakaste Fri, 24 Aug 2007 06:14:23 +0000 http://www.allpeers.com/blog/2007/08/23/markup-madness-part-one-htmlxhtml-deathmatch/#comment-99101 XHTML is nice in the backend, because it allows you to use the normal XML toolchain on the stuff you produce. And it's good you can shove it down the browsers' throats, thus avoiding conversion. However, I don't see why I would want a browser not to display a document I've created because of a markup error, which is what is implied by the desire to go for strict XML parsing. Sure, it would make a lot of things simpler, but I think the drawbacks would outweigh the benefits by far. XHTML is nice in the backend, because it allows you to use the normal XML toolchain on the stuff you produce. And it’s good you can shove it down the browsers’ throats, thus avoiding conversion.

However, I don’t see why I would want a browser not to display a document I’ve created because of a markup error, which is what is implied by the desire to go for strict XML parsing. Sure, it would make a lot of things simpler, but I think the drawbacks would outweigh the benefits by far.

]]> By: Matt http://www.allpeers.com/blog/2007/08/23/markup-madness-part-one-htmlxhtml-deathmatch/#comment-98969 Matt Thu, 23 Aug 2007 22:17:13 +0000 http://www.allpeers.com/blog/2007/08/23/markup-madness-part-one-htmlxhtml-deathmatch/#comment-98969 Jesse - My brain was thinking fission, but apparently my fingers had other ideas. Jesse - My brain was thinking fission, but apparently my fingers had other ideas.

]]> By: jgraham http://www.allpeers.com/blog/2007/08/23/markup-madness-part-one-htmlxhtml-deathmatch/#comment-98958 jgraham Thu, 23 Aug 2007 20:56:41 +0000 http://www.allpeers.com/blog/2007/08/23/markup-madness-part-one-htmlxhtml-deathmatch/#comment-98958 If you want to try out a HTML 5 parser, there's an online version of html5lib (a python implementation of the HTML 5 parsing spec) <a href="http://james.html5.org/parsetree.html" title="html5lib Parse Tree Viewer" rel="nofollow">available</a>. I'm curious to know what the other supposed advantages of an XML-based web would be. Extensibility is one (but we're hoping to solve that in HTML somehow) and I guess sanity in situations involving legacy code is, in principle, another. However I think getting from a world of permissive parsers to one of strict parsers is not feasible. Indeed I don't think that one could even start with strict parsers and keep them strict; competition between browsers would always drive them to take more and more liberties with strict error handling. If you want to try out a HTML 5 parser, there’s an online version of html5lib (a python implementation of the HTML 5 parsing spec) available.

I’m curious to know what the other supposed advantages of an XML-based web would be. Extensibility is one (but we’re hoping to solve that in HTML somehow) and I guess sanity in situations involving legacy code is, in principle, another. However I think getting from a world of permissive parsers to one of strict parsers is not feasible. Indeed I don’t think that one could even start with strict parsers and keep them strict; competition between browsers would always drive them to take more and more liberties with strict error handling.

]]> By: Jesse Ruderman http://www.allpeers.com/blog/2007/08/23/markup-madness-part-one-htmlxhtml-deathmatch/#comment-98956 Jesse Ruderman Thu, 23 Aug 2007 20:47:55 +0000 http://www.allpeers.com/blog/2007/08/23/markup-madness-part-one-htmlxhtml-deathmatch/#comment-98956 Chernobyl-era *fusion* reactor? Chernobyl was a fission plant ;) Chernobyl-era *fusion* reactor? Chernobyl was a fission plant ;)

]]> By: Al Billings http://www.allpeers.com/blog/2007/08/23/markup-madness-part-one-htmlxhtml-deathmatch/#comment-98947 Al Billings Thu, 23 Aug 2007 20:26:58 +0000 http://www.allpeers.com/blog/2007/08/23/markup-madness-part-one-htmlxhtml-deathmatch/#comment-98947 Considering that Microsoft is definitely not adopting anything coming out of the WHAT WG (instead, having members on the W3C HTML WG), work by the WHAT WG isn't going to solve any problems if you care about IE implementation. Considering that Microsoft is definitely not adopting anything coming out of the WHAT WG (instead, having members on the W3C HTML WG), work by the WHAT WG isn’t going to solve any problems if you care about IE implementation.

]]>