<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: The Joy of Strict XHTML</title>
	<atom:link href="http://www.davidlouisedelman.com/technology/joy-of-xhtml/feed" rel="self" type="application/rss+xml" />
	<link>http://www.davidlouisedelman.com/technology/joy-of-xhtml/</link>
	<description>Science Fiction Novelist, Blogger, Web Programmer</description>
	<pubDate>Fri, 21 Nov 2008 20:31:00 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: David Louis Edelman</title>
		<link>http://www.davidlouisedelman.com/technology/joy-of-xhtml/#comment-67</link>
		<dc:creator>David Louis Edelman</dc:creator>
		<pubDate>Fri, 28 Apr 2006 14:54:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.davidlouisedelman.com/?p=106#comment-67</guid>
		<description>Forgive a guy for being an optimist. :-) I don't &lt;em&gt;really&lt;/em&gt; think that we're all going to be sitting in a techno-utopia sipping lattes on the beach because of XHTML... but it's a nice start. Standards compliance of any kind is really the key, like interchangeable parts was the key for the automotive industry.

As for IE7, I was disappointed to discover that it &lt;a href="http://blogs.msdn.com/ie/archive/2005/09/15/467901.aspx" rel="nofollow"&gt;will not support application/xhtml+xml&lt;/a&gt;. Part of Microsoft's obsession with backwards-compatibility, I guess. The MS dude at the IEBlog claims that he's doing this to help XHTML's long-term prospects -- which seems like dubious logic to me, but then again, I don't control how 85-90% of the world views the web.</description>
		<content:encoded><![CDATA[<p>Forgive a guy for being an optimist. <img src='http://www.davidlouisedelman.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> I don&#8217;t <em>really</em> think that we&#8217;re all going to be sitting in a techno-utopia sipping lattes on the beach because of XHTML&#8230; but it&#8217;s a nice start. Standards compliance of any kind is really the key, like interchangeable parts was the key for the automotive industry.</p>
<p>As for IE7, I was disappointed to discover that it <a href="http://blogs.msdn.com/ie/archive/2005/09/15/467901.aspx" rel="nofollow">will not support application/xhtml+xml</a>. Part of Microsoft&#8217;s obsession with backwards-compatibility, I guess. The MS dude at the IEBlog claims that he&#8217;s doing this to help XHTML&#8217;s long-term prospects &#8212; which seems like dubious logic to me, but then again, I don&#8217;t control how 85-90% of the world views the web.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jonny Axelsson</title>
		<link>http://www.davidlouisedelman.com/technology/joy-of-xhtml/#comment-66</link>
		<dc:creator>Jonny Axelsson</dc:creator>
		<pubDate>Fri, 28 Apr 2006 13:34:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.davidlouisedelman.com/?p=106#comment-66</guid>
		<description>XHTML creating world peace, or eliminating spam from the world, is going a few steps too far. XML (and XHTML) removes some nasty problems, as well as some problems that are not really problems, and it is more strict than it needs to be in some cases. A nasty problem is when tags are improperly intermingled, because there is no proper way to untangle it. WHAT WG is &lt;a href="http://whatwg.org/specs/web-apps/current-work/#parsing" rel="nofollow"&gt;working on a way&lt;/a&gt;, though.

A problem which is not usually a problem (but only covered by validating processors in HTML or XHTML) is when a invalid element is used. For instance you are not allowed to put text directly into a 'blockquote' in (X)HTML Strict, you must put it into a block element like 'p' inside 'blockquote'. If you don't do that nothing untowards will happen, any browser as well as Google can handle that.

A case where XML is stricter than ideally is the example of case-sensitivity. If you start an unordered list with an lower-case 'ul' and end it with an upper-case 'UL' this will make the XHTML handling grind to a
halt (not if you use 'UL' in both start and end tags, but it wouldn't be recognised as an unordered list anymore). For (X)HTML handling case-sensitivity would be easy since the elements are all US-ASCII, but there were trickier cases for other Unicode characters, forcing a strict case-sensitivity.

By the way, both Opera and Konqueror handle XML (and thus XHTML) by the rules, Lynx and other HTML browsers would fall by the wayside though, and while I haven't followed this part of the process it is possible that IE7 will do so too.</description>
		<content:encoded><![CDATA[<p>XHTML creating world peace, or eliminating spam from the world, is going a few steps too far. XML (and XHTML) removes some nasty problems, as well as some problems that are not really problems, and it is more strict than it needs to be in some cases. A nasty problem is when tags are improperly intermingled, because there is no proper way to untangle it. WHAT WG is <a href="http://whatwg.org/specs/web-apps/current-work/#parsing" rel="nofollow">working on a way</a>, though.</p>
<p>A problem which is not usually a problem (but only covered by validating processors in HTML or XHTML) is when a invalid element is used. For instance you are not allowed to put text directly into a &#8216;blockquote&#8217; in (X)HTML Strict, you must put it into a block element like &#8216;p&#8217; inside &#8216;blockquote&#8217;. If you don&#8217;t do that nothing untowards will happen, any browser as well as Google can handle that.</p>
<p>A case where XML is stricter than ideally is the example of case-sensitivity. If you start an unordered list with an lower-case &#8216;ul&#8217; and end it with an upper-case &#8216;UL&#8217; this will make the XHTML handling grind to a<br />
halt (not if you use &#8216;UL&#8217; in both start and end tags, but it wouldn&#8217;t be recognised as an unordered list anymore). For (X)HTML handling case-sensitivity would be easy since the elements are all US-ASCII, but there were trickier cases for other Unicode characters, forcing a strict case-sensitivity.</p>
<p>By the way, both Opera and Konqueror handle XML (and thus XHTML) by the rules, Lynx and other HTML browsers would fall by the wayside though, and while I haven&#8217;t followed this part of the process it is possible that IE7 will do so too.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
