日期:2013-12-06  浏览次数:20776 次

我使用XHTML有些年了,但直至去年夏天我才着眼于如何正确使用,那就是说,以application/xhtml+xml的MIME类型来伺服(server)它。我知道我碰到问题的一些,但问题远非如此。就如你即将发现的一样,当你开始使用真正的XHTML,你会遭遇很多似乎细小但让人困惑的问题。

请留意这不是一篇讨论支持或反对使用XHTML的文章。我只是写下我所知道的潜在的易犯错误,并且让你本人来决定本人的选择:HTML 4.01,为所有浏览器伺服为text/html的XHTML 1.0或者为能够处理其的浏览器伺服为application/xhtml+xml而其他浏览器则伺服为text/html的XHTML 1.0。否则有些东西会完全不一样。

每当我遭遇到它们发生的场合,我开始了解一个又一个的问题。有些情况下我必须花很多时间来查找问题并且在找到处理办法之前求助于其他人。但我在其中学到不少东西,我将把我曾经使用XHTML后应该知道的都通知你。

留意我这里提及的问题只会发生在能正确处理application/xhtml+xml MIME类型的用户代理中,而因此XHTML被作为XML。这也可能是这里不提及XHTML的晚期使用的缘由——很少有人使用这样的浏览器,所以几乎不会有人因只伺服为text/html的XHTML所烦忧。

今天,实际上把XHTML伺服为application/xhtml+xml正慢慢变得平常。我所知道的理由有两个:

1. 使用Firefox,Mozilla,Opera。Safari和其他兼容XHTML浏览器的人数添加了很多,所以你不再仅仅为本人和伙伴这样做。嗯。或许你就这样做,当将影响更多人。
2. 在web开发者之间,对XHTML的真正面目是什么的觉醒越来越多了。使用XHTML曾经有多次多时的热烈的讨论,尤其是伺服为text/html的时候。如果你参与了任何一次讨论,你知道我在说什么。

假如你,像我,决定实现某些类型的content negotiation和在传送XHTML的时候使用正确的媒体类型,你需求知道什么能(和将)在你发布的文档中发生,并且知道怎样避免问题的发生。对于对content negotiation同进行content negotiation的脚本例子有兴味的读者,我推荐你阅读Content Negotiation和Serving up XHTML with the correct MIME type(本站早有翻译:使用正确的MIME类型伺服XHTML)。还有很多这品种型的文章,但这是我读到的最精彩的两篇。

每一个基本的教程都有一些HTML和XHTML的明显区别:元素和属性名字使用小写,属性值总要用引号。不要使用简化属性,确保所有的元素都有结束标签和没有不正确的嵌套等等。但是,当XHTML伺服为application/xhtml+xml时还需求知道更多东西。
良构是必须的

文档必须是良构(well-formed)的XML(跟合法的(valid)XHTML不必然相反)。对错误没有妥协,没无机会。如果文档不良构,符合标准的浏览器(当前我知道Mozilla,Firefox,Netscape,Camino,Opera,Safari和OmniWeb——相当多的浏览器除了IE)将会显示一条错误信息和在某种方式或其他方式上中止处理文档。

此外,这还意味着不再未编码的“&”号。
XML声明可能是必须的

如果要使用除了UTF-8或者UTF-16字符编码,XML声明是必须的除非HTTP头曾经提供编码。

在HTTP头中能否要指定字符编码有些模糊,Architecture of the World Wide Web, Volume One: Media Types for XML如此陈述

总体上,不应该在协议头为XML数据指定字符编码由于数据本身已描述。

另一方面,XHTML 1.0, Second Edition: Character Encoding说:

为了让文档使用指定的字符编码,最好的办法是保证web服务器发送正确的头。

就是说,在XML声明中指定字符编码是好的习惯:

<?xml version="1.0" encoding="UTF-8"?>
只要五个实体是安全的

只要五个预定义的实体(<、>、&、 "和')的支持是有担保的。其他的可能完全被忽略或者直接输出。比如,如果XHTML文档包含如 或者”的实体,Safari会生成。直接地。Opera反而选择忽略未知的实体,同时Mozila家族会认得这些实体并且就像HTML中“如果文档援用公共的映射浏览器伪DTD目录中的标识符并且没有单独声明的文档” 来处理。

使用UTF-8字符编码是备受推荐的最好实践,让你(几乎)可以使用你需求键入文档的任意字符,不需求实体或者字符编号。如果你不能或不愿使用UTF-8,数字式的字符编号是可以支持和安全使用的。
SGML式注释的内容可能会被忽略

SGML注释(HTML风格注释, <!-- 注释 -->)可能会(并且会)被浏览器当作注释,就算是在script或者style元素内部使用。

在HTML中,普遍地把sript和style块的内容装入注释中,为的是在不认识script或者style元素的浏览器中隐藏他们,并且在页面上把其内容生成平白文本。

在XHTML中,这样做会惹起浏览器忽略掉注释里的任何内容。

在老旧的浏览器中隐藏script和style元素的实践是退回到1990年代中期的一个习惯。我的经验是,有如此表现的浏览器是十分稀有的,所以你可以安全地忽略它们,并且停止在脚本和款式中装入SGML式注释,就算你使用的是HTML。
脚本和款式元素的内容也被当作XML

款式和脚本元素是PCDATA(parsed character data,解析字符数据)块,不是CDATA(character data,字符数据)块。因此,在其内看起来像XML的任何东西都会被当作XML来解析,并且会引发错误除非是良构的。

为了在stylee或者script块中使用<、&或者--,你需求用CDATA部分来包裹其内容:

1. <script type="text/javascript">
2. <![CDATA[
3. ...
4. ]]>
5. </script>

在CDATA部分内,你可以任何顺序的字符,它们不会被当作XML来解析(除了结束CDATA部分]]>。)

需求以text/html发送的文档中,CDATA部分的起始和结束标签需求注释掉,以便在不能处理CDATA部分的浏览器中隐藏:

1. <script type="text/javascript">
2. // <![CDATA[
3. ...
4. // ]]>
5. </script>

1. <style type="text/css">
2. /* <![CDATA[ */
3. ...
4. /* ]]> */
5. </style>

如果要确保够老的浏览器隐藏CDATA部分,需求使用更为复杂的方法,像在Ian Hickson的Sending XHTML as text/html Considered Harmful中描述的那样:

1. <script type="text/javascript">
2. <!--//--><![CDATA[//><!--
3. ...
4. //--><!]]>
5. </script>

1. <style type="text/css">
2. <!--/*--><![CDATA[/*><!--*/
3. ...
4. /*]]>*/-->
5. </style>

一个更好的办法可能是在发送text/html的文档前使用content negotiation脚本来删除任何CDATA部分。

当然,最聪明和安全的途径是把所有的CSS和JavaScript都挪动到外部文件中,但不总是理想的做法。
没有会自动补全的元素

在HTML中,假如表格的tbody元素漏写的话浏览器会自动补全,而XHTML不会。如果你没有清楚地添加tbody,它就不会出现。在编写CSS选择器和JavaScri