微软IE官方博客称，IE9将会在下周一3月14日正式发布，距离第一个平台预览版正好合间隔12个月。微软将在当天太平洋时间晚上9点开放下载。IE9主要新特性包括支持HTML5，图像硬件加速，新JScript引擎，支持WOFF等等。刚刚发布RC版的Firefox 4预计也将会在最近两周发布正式版。
IE9将在3月14日推出
發佈留言
標籤彙整: HTML
Google 对 Chrome 放弃 H.264 视频编码一事做出 “狡辩”
Google在自己的Chromium Blog对最近宣称要让Chrome放弃对H.264 视频编码一事以自问自答的形式做出了解释。 閱讀全文
利用 Data URL 加速你的網頁
對優化網頁效能有研究的人都知道，首要的任務是盡量減少 HTTP 請求 (http request) 的次數，例如把多個 JavaScript 檔案合併，把多個 CSS 檔案合併，利用 CSS 精靈和合併的小圖示等等，但是很多人都不知道還有一個 data URL 的密技，讓我們直接把圖像的內容崁入網頁裡面，這個密技的官方名稱是 data URI scheme。
data类型的Url格式：把小数据直接嵌入到Url中
关于 HTML5 应用现状与前景的思考
新闻来源:sixrevisions.com
现在的 HTML5 就像当年崭露头角时的 Ajax，有人在做，但不知道叫它什么。最近，苹果在 HTML5 上大做文章，而著名的 Web 设计师 Eric Meyer 则提出了 Web Stacks 的概念。Alex Kessinger 是 Yahoo 的一名前端工程师，本文是他对 HTML5 应用现状与前景的思考。 閱讀全文
text/javascript vs application/javascript vs application/x-javascript
一些MIME类型的区别
text/javascript vs application/javascript vs application/x-javascript 这三个MIME 类型有什么区别？
text/xml和application/xml有什么不同？
寻找了相关资料: 閱讀全文
W3C 验证的是是非非
美博客批苹果与 Adobe：别拿开放说事
美国科技博客Mashable编辑克里斯蒂娜·沃伦 (Christina Warren)今天撰文称，苹果和Adobe原本就是科技行业最封闭的两家企业，但他们却同时拿开放做起了文章，并且借此抨击对方，这完全是一种伪善之 举。以下为文章全文：
Adobe与苹果就Flash及其在移动网络中的地位展开了争论，在此过程中，这两家企业都不约而同地提到了“开放”这个 词。苹果称，“开放” 是iPhone不支持Flash的原因之一；而Adobe也在回应中表示，“我们热爱选择”。看到历史上最封闭的两家科技企业竟然相互攀比谁更开放，的确 非常可笑。
了解我的人都知道，我喜欢直截了当，这一次也不例外：苹果和Adobe在使用“开放市场”、“自由”和“选择”这样的词汇时，根本就不诚实。在 这场争论中，将开放当做一种美德是一种虚伪的行为，原因在于这两家企业对相关技术的讨论完全是站在他们自己的立场上，根本没有所谓的“开放”可言。
只为利益而开放
苹果和Adobe希望探讨开放、坚持标准以及为开发者提供“自由”和“选择”等宏伟理想的重要性。但是真正实施起来，这两家公司都只会在对自己 有利时才会采取开放策略。
我并不是在批评这种决策：他们只是以商业为基础来选择性地支持“开放”，况且过于理想化的开放也并不实际。事实上，这也符合大多数公司的选择， 即使是那些对开源技术投入的资源比苹果和Adobe的总和还要多的企业，也不能免俗。
然而，无论是苹果还是Adobe，如果要对开放的立场进行辩护，那就未免太过荒谬，而且根本不符合实际。
下面就让我来解释一下原因。
开放网络与开放开发平台
在移动应用领域，我们经常会提到网络应用和本机应用。网络应用是完全在浏览器中运行的应用。二者之间的区别就好比利用iPhone访问 Gmail与使用内置的邮件应用收发邮件一样。
苹果和Adobe的冲突其实同时涉及这两个领域：
– 苹果不允许Flash作为浏览器插件在iPhone中运行。苹果的解释是，这会影响性能，而且苹果希望重点发展开放网络标准，而非封闭的插件。
– Adobe非常生气，因为苹果已经禁止使用Flash CS5跨平台编译器开发的本机应用进驻应用商店。
这是两个独立的问题，但都可以很好地说明，这两家公司在指责对方时，其实并不真正关心“开放”。
网络标准
具体到对开放网络标准的支持，许多网络标准拥护者都赞成苹果的立场：Javascript、CSS3和HTML5有着开放的规范，而且可以通过 许多不同方式部署到不同的平台中。
万维网联盟(以下简称“W3C”)是专门创建网络标准的国际组织。苹果、Adobe、微软和谷歌都是W3C的成员。
尽管Adobe可以辩称，通过Open Screen Project项目，Flash的确实现了开源，但Flash本身并不是一个开放标准。尽管Adobe在《Flash的真相》(The Truth about Flash)一文中引述了Gnash等开源的例子，但在源代码封闭的情况下却无法获得同样的效果，因为Flash的部分内容与DRM(数字版权管理)相 关，而其他内容控制机制则无法使用。去问问那些无法播放BBC iPlayer内容的XBMC用户就知道了。
与HTML5和CSS3以及与之相关的技术不同，Flash不是一种开放网络标准。Adobe或许免费提供了部分技术，也或许公布了部分SWF 标准，但是整个Flash生态系统并不是开放的，也不是一种网络标准。Adobe口口声声说他们支持自由选择，但是这种自由却并没有被拓展到他自己的技术 中去，这显然是一种伪善的行为。
定义本机代码
但苹果也并非全无过错。无论你是否同意苹果在跨平台编译器和兼容层上的立场，这仍然是一种自相矛盾的论调。
苹果反对在iPhone中使用Flash CS5等应用开发工具，因为这些工具最终是由Adobe一家公司控制的，而且有可能会导致iPhone的兼容性和性能出现问题。
这一点可以理解。但开发者同样值得同情，他们每年花费99美元购买Adobe的产品无非就是为了开发iPhone应用，而现在却无法使用这些工 具了。Adobe的员工甚至因此而对苹果大爆粗口，而Adobe也通过一些官方措施鼓励开发者转而为Android开发应用。
即使是一些与Flash无关的开发者也受到了这一事件的影响。就在本周，资深Mac软件开发者沃尔夫·伦萨奇(Wolf Rentzsch)宣布取消独立Mac开发者大会C4，部分原因就在于不满苹果对跨平台编译器制定的新规。
在这种情况下，苹果其实是在限制开发者的选择。这一事件本身没什么大不了，虽然会引起一些不满，但如果不是苹果自己跳出来讨论开放的重要性，便 不会存在任何伪善的成分。
别拿开放做文章
苹果和Adobe都不是开放软件、开放标准或开放开发平台的代表。但这并不意味着他们就是不好的。不过，如果将这种情绪化的内容引入到争论中只 会令问题更为复杂。
Adobe在这场争论中处于不利位置，因为它很容易成为目标。目前还没有任何一款移动设备在出厂时就能够完全支持Flash，而且有越来越多的 内容发布商开始转向HTML5视频，或者使用CS5以外的其他工具开发的本机应用来代替RIA(富互联网应用)。
移动网络与桌面网络并不完全相同，人们越早意识到这一点越好。我更愿意看到Adobe通过更多的第一手资料来展示Flash在移动设备上的表 现、该技术为何适合触摸界面以及嵌入式系统如何利用这一技术，而不是就视频的未来以及Flash是否适合本机移动应用而争论不休。
另一方面，我也非常希望苹果能够进一步开发WebKit，并将相应的功能整合到移动和桌面设备中去，借此来表明自己对开放网络和网络标准的支 持，而不是对其生态系统内的移动开发者进行事无巨细的管理。
在一个完美的世界中，无论这两家企业是否认同对方的模式，依旧可以在不攻击彼此的情况下走自己的路。可惜的是，我怀疑这种情况短期内不会发生。
微软IE9不支持XP 国产浏览器难把握“新商机”
近日，由于Windows XP用户无法使用最新的IE9浏览器导致微软遭到谷歌、雅虎等多家竞争对手的指责。而国内浏览器业内人士表示，讨论微软此举对中国浏览器市场的影响为时过 早，短期内中国浏览器市场格局不会有大的变动。尽管早在今年3月的MIX开发者大会上微软就表示XP用户将无法使用IE9浏览器，但是 外界，特别是XP用户仍抱有一线希望。而此次微软再次以 “绝不”来回应对于XP系统支持的问题算是捅了马蜂网。甚至有国外的技术人士大声呼吁：“我建议所有的XP用户都放弃IE，采用其他浏览器。”
实际上，对于微软来说，现在就坚持IE9不会支持Windows XP似乎实在是不明智之举。根据Net Applications的统计，今年4月IE市场占有率从3月份的60.65%进一步降至59.95%。这是微软IE多年来市场份额首次跌破六成。不论 在国内还是在国外，浏览器厂商都在蚕食微软IE浏览器的市场份额。
借口：要支持HTML 5新标准
实际上，微软拒绝在IE9中支持XP的理由，是因为IE9要支持HTML 5——一个即将推出的新版网络标记语言，将能够为用户提供许多新的功能，包括通过标准的方式来部署视频、动画、音频和线下存储空间。而现有的HTML标准 不包含这些功能。
微软方面强调，HTML 5是互联网的未来，所以决定全力“拥抱”。在此之前微软的IE8仅部分部署HTML 5标准，但并不完整。而这一直以来受到外界的诟病。
微软声称，完全支持HTML 5的IE9浏览器是一款“现代化的浏览器”，为此需要一款“现代化的操作系统”相匹配。微软的言下之意是Windows XP系统并不属于这类“现代化的操作系统”。
但其竞争对手谷歌的技术人士并不认同这种看法，“Opera和Mozilla也在浏览器中使用了硬件加速，而且所有浏览器都可以在XP中运 行”。
用意：逼迫XP用户升级
网页浏览器的竞争中从来不缺乏硝烟和战场，上世纪90年代，就市场占有率来说，Netscape（网景）的网页浏览器曾占首位，但在“第一次浏 览器大战”中被微软的IE所击败，并最终退出历史舞台，微软IE得以一枝独秀。近年来，在谷歌Chrome、火狐等浏览器的入侵下，支配浏览器市场多年的 微软正在飞快地失去市场份额。市场分析机构NetApplications发布的最新数据显示，今年4月份，谷歌Chrome浏览器份额继续强劲增长，由 6.1%增长至6.7%，主要蚕食了微软IE浏览器份额。火狐和Safari市场份额都出现小幅增长，分别达24.59%和4.72%。
基于这种态势，有“阴谋论者”认为，微软宣称IE9不支持Windows XP，实际上是为了加速淘汰XP操作系统。希望这部分固守XP的用户，如果想要享受IE9所带来的新体验的话，那么就必须放弃XP，能够转投 Windows7。而这将增加微软的收入。
Forrester分析师谢里·麦克雷什便是其中之一，他表示， “XP是与Office 2003和IE6同时代的产品，微软不想再延长这些产品的寿命。支持XP不符合微软的利益”。但同时表示这也给了火狐等竞争对手进一步蚕食IE市场份额的 机会，由于大量小企业和消费者仍然在运行Windows XP，微软的这一决定将为火狐等竞争对手提供机会。Mozilla和谷歌也在开发浏览器硬件加速技术，但它们的技术支持Windows XP。
变数：国产浏览器难破现有格局
微软因为自身长远利益而做出的决定，不仅在国外，同时也使国内浏览器市场未来的格局产生了某种微妙的变化。这是否是国产浏览器的绝好商机呢？
艾瑞咨询产业研究部副总监王芳对记者表示，微软IE浏览器在中国市场的占有率仍居首位且表现稳定。
根据艾瑞咨询4月份浏览器市场占有率调查报告，中国网民日均选择使用IE浏览器的市场占有率为66.94%，几个月来一直保持在这个水准，几乎 没有什么波动。
王芳强调，由于中国互联网每年有大量新用户增加，网络覆盖也扩展到二三线城市和城镇、乡村用户，大部分网民属于初级网络用户，上网时习惯使用操 作系统自带的IE浏览器，而自主判断和选择浏览器产品的高级用户不多。
因为浏览器是互联网行业最重要的入口，谁要能够占住这个入口，就可以在商业上有无限可能，因此国内包括搜狐、腾讯、360、傲游等都推出了自己 的浏览器。不过面对微软IE 9放弃对XP的支持，国内公司的态度显得非常低调。
奇虎360方面表示，IE浏览器因为是Windows操作系统中自带的，由于操作习惯和使用惯性，IE在中国浏览器中的龙头地位很难被其他竞争 对手撼动。即使微软做出最新IE9不支持Windows XP的决定，也不会在短期内形成对中国市场的冲击。
而傲游浏览器的公关负责人表示，微软这一举动看似给了其他浏览器厂商机会，但由于微软其他版本的IE在用户中使用率还很高，地位也很稳固，现在 说中国浏览器市场格局将有大变动还为时过早。
有分析认为，对于浏览器“用户只有体验不错，才会长期使用。这是一个双向选择的过程，真正的决定权还在网民本身”。商报记者 罗添 实习生 张绪旺/文
Adobe, 微软论剑 Flash, Silverlight 与 HTML5
大约3年前，微软推出 Silverlight 1.0，那时，Adobe 携 Flash 拥兵自重，尽管微软对 Silverlight 的推广力度非常强，却并没有撼动 Adobe 的霸主地位，或许市场为二者都保留了空间，如今 HTML5 风声鹤唳，informationweek.com 召集微软和 Adobe 就 Flash，Silverlight 和 HTML5 做了一番辩论。 閱讀全文
Google放弃Gears拥抱HTML5
Google Gears是为浏览器开发的新型插件，使得网页应用可以离线使用，比如离线使用Gmail，存取其中的邮件。但是Google已经下定决心跟 Google Gears 说永别了。Google为什么抛弃Gears？并不是说 Google Gears不够流行不够强大，而是浏览器已经可以通过HTML5这个新的标准来支持Google Gears能做到的那些事情，而且可以让浏览器保持简洁性。
Google已经在最近的Chrome版本里添加了对Database API的支持（它类似Gears的数据库API），对本地和共享workers的支持（类似于Gears里交叉worker的概念），对本地存储API和 Web Sockets API的支持。而未来新版本的Chrome浏览器里也会有类似LocalServer API和Geolocation地理信息等类似API的支持。
由于现在还没有太简单的方法将之前的Gears应用移 植到HTML5应用，所以Google还是会继续支持Gears直到大家差不多都将Gears应用部署成HTML5应用为止，但是Gears不会再有新的 功能了，特别重要的是，Google不会支持Gears在Mac OS X Snow Leopard和后续操作系统里在Safari浏览器里的使用，对Firefox和IE的支持则会继续，包括马上到来的Firefox 3.6。
ViaGoogle Code BlogandZDNet Blog
Pic viaLemenem
谷奥-探寻谷歌的奥秘[http://www.google.org.cn]
Adobe试图颠覆HTML5：做自己应该做的事
HTML5规范的编辑者之一，现供职于Google的Ian Hixie在个人博客上声称，尽管Adobe的多位巨头都曾公开表示支持HTML5，但是现在Adobe却在阻止HTML5规范的发布。 这不奇怪，因为HTML5规范中视频标签(video tag)的部分是不利于Adobe利益的，今天Adobe不颠覆HTML5，回头HTML5就会颠覆Adobe Flash技术，Adobe要是这么痛快就对HTML5点头就怪了。 閱讀全文
漫画：混乱的标记语言XHTML2/HTML5（附中文版翻译）
W3C最近宣布将于今年年底解散XTHML2工作组。一石激起千层浪，很多误解和谣言四起，江湖一片血雨腥风，搞得网页设计师人人自危，好像世界末日即将到来。其实，这只是个误解，看完下面的这幅漫画，大家就了解了。完全可以放心，然后回家洗洗睡了。
非原创，来源网络：英文版源文地址：漫画英文版源文地址，这里是英文原版漫画
感谢我的同事Kevin Jaw的翻译。他的博客地址是：Kevin Jaw的博客
Google 加入反 IE6 联盟：IE6 真的能被消灭吗？
剿杀 IE6 的战斗仍在继续， 一家重量级公司的加入为这场战斗增加了决胜的砝码，Google 宣布，从 2010 年 3 月 1 日起，Google Docs 和 Google Sites 将不再支持 IE6。如今，宣布不支持 IE6 的公司已经构成了一份长长的名单，然而，IE6 是真的那么轻易被剿灭吗？
Google 在其官方博客中写道：
很多公司都停止支持 IE6 等旧浏览器，我们也将从 Google Docs 和 Google Sites 开始加入这一行列。从3月1日起，这些产品中的某些重要功能在这些旧浏览器中将无法正常使用。
关于 IE6 的一些问题以及它为什么被剿杀，可以参阅以下文章：
然而 IE6 真的那么容易被消灭吗？
这段文章来自 thenextweb.com，作者讲述了为什么 IE6 仍然存在以及为什么它不那么容易被消灭。
IE 确实被开发者痛恨，它已经过时，且不支持最新 Web 技术和标准，然而却拥有庞大的用户基础，这主要是由那些没有及时升级他们的软件系统的公司导致的。现在，Google 也加入到反 IE6 运动，然而 IE6 并不那么容易被消灭。
Google 从 Google Docs 和 Google Sites 开始停止对 IE6 的支持，然而，使用 Google Sites 的公司寥寥无几，而在企业领域 Google Docs 和微软 Office 相比，仍不足为道。虽然 Google 最终会陆续停止其它产品对 IE6 的支持，但必须知道，很多企业坚持使用 IE6 的原因是他们有很多旧的 Web 应用是建立在 IE6 基础上的（译者注：IE6时代曾诞生过大量只支持 IE6 的企业 Web 应用，如 BS 版的 ERP，OA 和 CRM 系统），除非 Google 在搜索主业中停止对 IE6 的支持，否则，企业用户市场仍然会保留 IE6。
最终，或许微软才是真正能将 IE6 消灭的公司，很多公司正在计划向 Windows 7 迁移，Windows 7 包含最新的 IE 浏览器，甚至根本没 带浏览器，这将敦促企业用户重新考虑那些只支持 IE6 的 Web 应用的存留问题，而在当前，他们可以不要 Google 的那些服务，却不能不要IE6，另外，Google 的 Google Chrome Frame 可以帮助 IE6 用户绕过目前存在的问题。
译者注：在国内，IE6 庞大的用户基础还来自网银和政府网站这两个根深蒂固的 IE6 拥趸，而这两个 IE6 拥趸只所以抱住 IE6 不放的原因是，他们的大量应用是基于 IE6 ActiveX 控件的。
本文来源：
http://mashable.com/2010/01/29/google-ie6/
http://thenextweb.com/us/2010/01/30/google-kill-ie6/
中 文翻译来源：锐商企业CMS网站内容管理系统官方站
HTML 5 令人期待的 5 项功能
HTML 5 是超文本置标语言下一个重要版本，HTML 自1999年发布 HTML 4.01 以来，其开发一直处于停顿状态，而1999年至今正好是 Web 飞速发展的时间，现在的 HTML 版本已经无法适应现在的 Web 内容与应用。HTML 5 旨在提高 HTML 的交互行，支持当前多样的，复杂的 Web 内容。同时，它也会解决 HTML 4 Web 应用功能上的欠缺。
一点历史背景
HTML 5 的讨论开始于2003年，当时，W3C 对由 Web Hypertext Application Technology Working Group (WHATWG) 开发的 HTML 5 草案表示出兴趣，WHATWG 创始于2004年，由苹果，Mozilla 基金会，以及 Opera 公司的 代表组成。此后，W3C HTML Working Group 于2007年成立并着手开发 HTML 5。目前，开发工作仍在进行中，并将于2012年向 W3C 提交初步意见，不过现在已经有不少浏览器部分支持 HTML 5。本文介绍 HTML 5 的5大令人激动的新功能。
1. 一些帮助我们描述内容的新标签
Web 内容的多样性让 HTML4 力不从心，在描述一个网页时，HTML4 如下 表现：
HTML 5 将如下表现：
这样，浏览器就知道一个网页的各个部分各代表什么，比如 <nav> 部分是导航，而 <article> 部分是主要内容 。除了更漂亮的 代码与语义标签，这种改变还带来更多好处，比如，搜索引擎可以更准确地知道一个网页的哪部分内容更重要。关于 HTML 5 新标签，IBM有详细的论述。
2. 改进的 Web 表单处理
HTML 5 推出 Web Forms 2.0，为开发提供许多新选项和新功能，以更简单更有效地处理表单的输入与发布。Web Form 2.0 最令人兴奋的功能是输入验证。目前，我们需要通过 JavaScript 或服务器端的逻辑，实现同样的功能。
比如有下面这样一个表单:
在 HTML4 我们需要这样写代码，然后使用 JavaScript 或服务器端的脚本进行验证：
而 HTML5 中的 required 与 email 属性可以直接实现验证，如下：
3. 为 Web 开发提供 API
HTML 5 将提供多个 API，如音频和 视频标签可以让开发者不借助第三方工具直接播放 Web 视频和音频：
4. <canvas>标签将允许直接在上面用脚本绘图
人更容易从图片获得信息，如，下面的信息通过表格和圆饼图两种方式显示，效果明显不一样：
然而以往要实现这种效果，只能使用静态图片，无法对图片进行调整。使用 <canvas> 标签，你可以实时修改参数对图形进行修改，比如，根据用户的投票，实时生成圆饼图。
5. 用户可以编辑网页的部分内容并实现同网页的交互
HTML 5 将支持用户的交互，contenteditable属性允许你设定网页的哪一部分可以编辑，在基于 Wiki 的 站点，这非常实用。
延伸阅读
- You can read the latest working draft of HTML 5 specifications on the W3C website （HTML 5最新工作草案）.
- Learn about the major differences between HTML 4 and HTML 5 on the W3C website（HTML4/5的主要区别）.
- IBM developerWorks has an excellent in-depth article on new elements in HTML 5.（IBM有一篇关于 HTML 5 的 深度 研究文章）
- Read about the people in charge of developing HTML 5 specifications on the W3C HTML Working Group website.（W3C HTML 工作组成员）
- Find out what you can do to help HTML 5 development on the WHATWG wiki website.（如何为 HTML 5 提供帮助）
本文国际来源：http://www.readwriteweb.com/archives/5_exciting_things_in_html_5.php
中文翻译来源：COMSHARP CMS 官方网站
语义一致与合理命名，及常见错误
转自http://www.junchenwu.com/2006/01/buttoninput.html
一句话概括主题：<button>具有<input type="button" ... >相同的作用但是在可操控性方面更加强大。
HTML 4.01规范的Forms部分指名表单有以下几种控制类型：buttons, checkboxes, radio buttons, menus, text input, file select, hidden controls, object controls. 其中除了buttons/menus/object controls之外，都是由<input>完成。
我这里说的是<button>和<input>。
<button>和<input>
规范中指名：可以用<button>和<input>来做表单按扭。不同的按钮类型请参考这些元素的详细定义。要注意的是<button>比<input>支持更丰富的表现功能。
一些区别
大家都知道<input>可以这样用（实际上是一定要这样用）：<input type="submit" value="OK" />，一定要这样闭合。而不是：<input type="submit" value="OK" ></input>。因为起始标签为必须，而关闭标签是禁止的。
<button>比<input>更厉害的地方就在于它可以包含内容。它的值并不是写在value属性里，而是包含在标签中。如：<button>OK</button>。<button>的起始标签和关闭标签都是必须的。这样你便获得了样式化的主导权。
你可以这样写：<button><strong>OK</strong>, I do.</button>，甚至是插入图片：<button><img src="button.gif" alt="" />, it's great.</button>。有点类似于<input type="image">，但是显然强大多了。
最后要注意的是，被<button>包含的图片，不能使用热点地图，即不能<img src="foo.gif" usemap="..." />，这是不合法的。当然也不能再包含诸如input, select, textarea, label, button, form, fieldset, iframe,和isindex（不推荐使用）元素了。
(X)HTML Strict 下的嵌套规则
下面是一份在 HTML 4 Strict 和 XHTML 1.0 Strict 下必须遵守的标签嵌套规则，比如你不能在 <a> 里面再嵌入一个 <a> 这样的约定。
说明：
- 为了方便读者阅读，本文中的标签使用了大写（根据 XHTML 的规则，元素名必须小写，比如
<html>而不应是<HTML>） - 小写的单词表明一组或一系列 HTML 标签
- 每一项条目（标签）后都跟随一组标签列表，如果没有这个列表，那么表明该条目（标签）内部不允许包含任何标签。这意味着该条目内部只能包含纯文本内容（#PCDATA，见下文）。如果注明 (empty)，这意味着该条目内部不允许包含任何形式的内容。对于 flow，inline，block，OBJECT 和 BODY，其内部允许包含的内容在文中会单独给出。
- #PCDATA 的意思是“parsed character data”，即纯文本内容（不包括任何 HTML 标签，但是转义内容可以存在，比如
ä和ä） - CDATA 的意思是“character data”，这意味着不包括转义内容的纯文本内容，详细内容可以参考CDATA Confusion
- excluding … 意即不得直接或者间接的包含所列的元素
allowednesting
注1. 以上内容基于 [HTML 4.01 Specification] 的 Strict DTD。JunChen 翻译自 Allowed nesting of elements in HTML 4 Strict (and XHTML 1.0 Strict)
注2. 对于 XHTML 1.0，基本上一致，不同点如下：
- 对于
<script>和<style>的内容，在 HTML 4 里是CDATA而在 XHTML 里是#PCDATA - 在 XHTML 中，
<table>标签后可以紧跟一个<tr>，而在 HTML 4.01 里，不允许这样，不过<tbody>标签又是可以省略的。意思就是说，如果代码中的<table>后紧跟<tr>，对于 HTML 4.01，会隐性的生成一个<tbody>标签，而在 XHTML 里面就没有。这会影响到样式表使用tbody作为选择器。
Transitional vs. Strict Markup
推广Web Standards的人经常说XHTML比HTML更加严格，当然从某种意义上说是的，比如它要求所有的标签关闭并且所有的属性都用引号。但其实XHTML 1.0还分两种（加上Frameset DOCTYPE的话算三种，本文不讨论），Transitional（过渡型）和Strict（严格）DOCTYPEs。并且HTML 4.01也有同样的文档声明。
从字面上就可以看出来意思：Transitional DOCTYPEs只是为了实现从旧时代到新时代的过渡，而且Strict DOCTYPEs是默认的文档声明， 对构造HTML 4.01和XHTML 1.0都适用。
使用Transitional DOCTYPE一般是由于代码中含有过多陈旧的写法，并且一下子很难完全转换到Strict DOCTYPE来。但是Strict DOCTYPE才应该是你的目标。它鼓励甚至有时是强迫你把结构与表现区分开来，把表现层的代码都写在CSS里。HTML 4 Document Type Definition： –
本HTML 4.01 Strict DTD不包括表现层属性和标签，W3C将逐渐淘汰这些属性和标签，您完全可以使用样式表来实现。您应该使用Strict DTD，如需获得表现层属性和标签的支持，请使用Transitional DTD。
用Strict DOCTYPE还有一个好处，即可以让浏览器使用它们最严格、（一定程度上）最符合标准的模式来渲染页面。
Tommy Olsson在Web Standards Group的Ten questions for Tommy Olsson一文中很好的阐述了使用Strict的好处：
我觉得，使用Strict DTD，无论是
HTML 4.01 Strict还是XHTML 1.0 Strict，远比讨论是用HTML还是XHTML重要的多。它代表了未来互联网的质量。它将结构和表现分开，使得维护一个站点非常容易。
对于刚开始接触web standards和正确的、语义化的结构的人，认清Transitional和Strict DOCTYPEs的区别非常重要。更多详细列表请参考：XHTML: Differences between Strict & Transitional、Comparison of Strict and Transitional XHTML和XHTML1.0 Element Attributes by DTD。
对于准备向Strict进发的人来说，两者的有些区别很可能会使开发者犯错误，接下来我将会谈到。
在Strict DOCTYPEs下不支持的标签
centerfontiframesrikeu
在Strict DOCTYPEs下不支持的属性
align(表格相关的支持：col,colgroup,tbody,td,tfoot,th,thead, andtr)languagebackgroundbgcolorborder(table支持)height(img和object支持)hspacename(在HTML 4.01 Strict中支持，XHTML 1.0 Strict中的form和img不支持)noshadenowraptargettext,link,vlink, 和alinkvspacewidth(img,object,table,col, 和colgroup都支持)
内容模型的区别
元素类型的内容模型描述了什么样的元素类型实例可以被包含。这一点上，两种文档声明的最大区别在于blockquote, body, 和form元素仅能够包含块级元素，如：
- 文本和图像不允许直接包含在
body中，必须被p或者div等块级元素包含 input元素不能直接是form元素的下一层blockquote元素内的文本，必须被p或者div等块级元素包含
将所有的表现都交给CSS，恪守Strict标准
在向Strict DOCTYPEs过渡的过程中，了解每个元素是做什么的比知道每个元素长啥样有效的多。
首先考虑结构和语义，然后再担心表现。
IE8和网页标准
W3C终于发布了第一个HTML5草案，大家还沉溺在HTML2XHTML转换的快乐和痛苦中时，却又突然发现，HTML5和XHTML2，到底谁是未来？……，当然，HTML5和XHTML2会保持最大兼容性，W3C和WASP肯定比我们更清楚这一点的重要性。不过如果都“最大兼容”了，为何不统一呢？HTML那种不标准的代码解析起来可不怎么好玩。
我想抱怨的是，W3C的效率那是相当出名（就像IE实现标准的效率），现在第一个草案，正式定稿最早是2010年，这么算起来，要等IE支持（我坚信那时IE仍是主流浏览器），恐怕我们的显示设备原理和效果都升级换代了。到时再用一份“妥协”过的“标准”——拜托，这可是IT产业。很多美好的标准或技术，从我们开始期盼，到我们都不再编码，它都不会实现。
其实HTML5这事儿没多大动静，闹得正欢的是IE8实现“超级标准模式”的事儿，IE开发团队为了让只认识IE的，用IE6/7的所谓“符合标准”代码，错误的实现他们想要的样式的网页作者们不用修改他们的网页，决定让IE8在“标准模式”下实现IE7的显示结果，而实现“更正确”的标准需要在网页中加入一段META信息。
嗯，技术一点来说，IE6依靠DOCTYPE来区分怪癖模式（IE5.5或更早版本的绘制网页方式）和标准模式，但IE6实现的“标准模式”依然有许多错误，而当IE7改进“标准模式”时，这些“错误的标准模式的代码”就会展现出错误的样式。为了避免该问题再发生在IE8身上，IE团队决定使用一个META标签或HTTP包header来告诉浏览器，用“超级标准模式”来绘制网页，而现在的标准网页将默认为IE7的绘制方式。
再直白（或讽刺）一点，如果ACID2测试网页要想在IE8下正确表现，ACID2测试需要修改网页，加上一个META信息，告诉IE8用“超级标准模式”。真CCTV。
为过去的部分错误网页，IE要牺牲未来的网页。微软总是在用一个错误掩盖另一个错误，所以，我们总是要疲于解决浏览器间（准确地说是IE和其他浏览器）的兼容性问题。“不破坏现有网络”总是被当作微软的借口，事实上他们每次发布新版IE都“履行”了这点，总是有新bug推翻了这个借口。
当然，这个想法看上去，不是完全没有好处，至少我们可以让网页在IE下始终显示如一（来兼容MS犯下的错误）。可是，当IE9修正了IE8的错误标准时，我们该怎么办？如果还是需要IE条件注释或CSS HACK来解决的话，那这个标签有什么意义？还是说，微软以为这个标签就可以让大家都总是平滑听话的升级到最新的IE，就像Opera社区那样？
想让IE永远用最新的版本绘制网页？
<meta http-equiv=”X-UA-Compatible” content=”IE=edge” />
或者用HTML5的doctype
<!DOCTYPE html>
（IE6/7将以标准模式处理）
或者HTTP包header
X-UA-Compatible:IE=edge
反对的理由
- 未来的IE9/9+能否真的正确兼容过去的版本？
- IE的体积会不会越来越大？比如1G？
- 浪费互联网流量资源。
- 如果实现多引擎间交互，比如主网页和内嵌iframe用不同版本的引擎时？
- 微软在鼓励大家用非标准代码开发网页？
- 期间的小版本如何处理？IE史上发生过补丁改变绘制的事情。
- 更多的安全漏洞？（绝大多数病毒都是通过IE网页漏洞传播的吧……）
部分评论：
是时候宣布浏览器间兼容性已经破产？
我们总是为MS修复网页，而不是MS为网页修复IE。
如果干掉IE，那么我们就没这么多问题了。
综合：A List Apart2篇，John Resig,Dean Edwards,Safari,Mozilla,456 Berea Street消息
使用热门选择：元标记(Meta tags)和网页搜索
发表者：John Mueller, 网站管理员趋势分析员，苏黎世
原文：Answering more popular picks: meta tags and web search
发表于：2007年12月4日，星期二，上午11时53分
如果你能写好和维持准确的元标记（例如，描述性标题和为搜索机器人提供的信息），谷歌就可以更准确地爬行、索引并在搜索结果中显示你的网站。元标记为各种各样的客户端（例如浏览器和搜索引擎）提供信息。请记住，每一个客户端可能只解析对该客户端有用的元标记，而忽略了其他元标记（虽然它们有其他用处）。
下面是谷歌如何解析以下 HTML 页的元标记：
<!DOCTYPE …><head>
<title>传统瑞士奶酪火锅食谱
<title>
谷歌使用此标记，网站管理员应非常注意它的准确性
<meta name=”description”
content=”奶酪火锅是 …”>
谷歌使用此标记，我们的搜索结果会显示它
<meta name=”revisit-after”
content=”14 days”>
谷歌不使用此标记，其他主要搜索引擎也不使用
<META name=”verify-v1″
content=”e8JG…Nw=” />
可选，谷歌网络管理员工具用到此标记
<meta name=”GoogleBot” content=”noOdp”>
<meta …>
<meta …>
</head>
可选
<meta name=”description” content=”对本页的描述”>此标记提供了对当前页面一个简短描述。在很多情况下该描述会作为页面摘要（snippet）显示在谷歌的搜索结果中。详情请参阅我们的博客文章“使用更好的元描述来改善页面摘要”以及帮助中心的文章“如何更改网站的标题和描述”。虽然描述元标记是可选的，并且不会影响到您的排名，一个好的描述可以产生一个更好的页面摘要，这反过来又可以帮助提高我们的搜索结果质量和你的网页的访问者数量。
<title>页面标题</title>从技术上讲，标题标记并不是一个元标记，它经常与”description”标记一起使用。此标记的内容（即标题）一般显示在搜索结果中（当然，当用户使用浏览器来浏览网页或察看书签时也能看到页面标题）。我们的博客文章”针对访问者，还是针对搜索引擎？“尤其是”充分利用网页标题”中有关于标题标记的更多信息。
<meta name=”robots” content=”…, …”>
<meta name=”googlebot” content=”…, …”>这些元标记控制搜索引擎如何抓取和索引页。 “robots”元标记指定的规则适用于所有搜索引擎，”googlebot”元标记指定的规则只适用于谷歌。谷歌可以理解以下值（当指定多个值时，用逗号将它们分开） ：
* noindex: 防止网页被索引（见”使用元标记拦截或删除网页“)
* nofollow: 不要通过当前页的链接来寻找并抓取新的网页（也见”使用元标记拦截或删除网页“)
* nosnippet: 在搜索结果中显示当前页时，不要显示页面摘要（见”防止显示或删除页面摘要“)
* noodp: 在为本页产生标题或页面摘要时，不要使用开放式目录项目（又名dmoz.org）中的文本（见”如何更改网站的标题和描述？“)
* noarchive: 在显示本网页于搜索结果中时，不要显示一个”网页快照”链接（见”防止显示或删除缓存的网页“)
* unavailable_after:[日期]:在指定的日期和时间后从搜索结果中删除这个网页（见”机器人排除协议：现在更灵活“)
当你完全省略此标记或当你指定content= “all”时，默认规则是”index, follow”。”使用 robots 元标记”中有关于”robots”元标记的更多信息。作为一个说明，你现在也可以在你的页面首部通过”X-Robots-标签”HTTP 头指令来指定这一信息。这特别有用，尤其是当你想微调抓取和索引诸如 PDF、图片或其他类型的非 HTML 文件时。
<meta name=”google” value=”notranslate”>当我们认识到一个页面的内容并不是用用户可能想读的语言所写时，我们往往在搜索结果中提供一个链接以自动翻译你的网页。一般来说，这让你有机会提供独特和令人折服的内容给一个更广大的用户群。不过，在特定情况下，你可能不想你的网页被翻译。用这个元标记，你可以表明你不想让谷歌提供一个翻译此页的链接。这个元标记一般不影响该页为任何特定语言的排名。更多的信息请参阅”谷歌翻译常见问题解答“。
<meta name=”verify-v1″ content=”…”>这是一个谷歌网站管理员工具的特定元标记，它是被用在你网站的高层页面，以在网站管理员中核实一个网站的所有者（另一种核实方法是上传一个HTML文件）。你为这个标记所设置的 “content=”的值是由你的网站管理员工具帐户提供的。请注意，这一元标记的 content 值（包括大小写）必须和你的帐户提供给你的值完全一样，这和你是否从 XHTML 改变标记为 HTML 无关，也和你标签的格式是否与你的网页相符无关。详情请见” 如何通过向网站主页中添加元标记来验证网站？”
<meta http-equiv=”Content-Type” content=”…; charset=…”>这个元标记定义该页的内容类型和字符集。使用这个元标记时，content 属性的值必须放在引号中;否则字符属性可能被错误理解。如果你决定 使用这个元标记，不用说，你应该确保你的内容实际上用的是指定的字符集。”谷歌的网络作者统计“里有一些关于这个元标记的使用的有趣数据。
<meta http-equiv=”refresh” content=”…;url=…”>这个元标记在一定的时间后将用户指引到一个新的 URL，有时它被用来作为一种简单的重定向形式。不是所有浏览器都支持这种重定向。它也可能混淆用户。对显示在搜索引擎结果中的某一页面，如果你需要改变它的 URL，我们建议您使用服务器端的 301 重定向。此外，W3C 的”网页内容易读性技巧和故障指南 2.0“把它列在应该被废弃的标记中。
(X)HTML 和大小写
谷歌既能阅读 HTML 式的元标记，也能阅读 XHTML 式的元标记（无论网页用的是哪种编码）。此外，元标记的大小写一般并不重要–我们把<TITLE> and <title>看作是同样的。但是，”verify-v1″元标记是一个例外，它是区分大小写的。
revisit-after 网站地图的 lastmod 和 changefreq 标记
偶尔，网络管理员不必要地包含了”revisit-after”标记以加快一个搜索引擎的爬行速度，不幸的是，这个元标记大多数情况下是被忽略的。如果你想 让搜索引擎知道你更改页面的信息，你可以提交一个 XML 格式的网站地图。在该文件中，你可以说明你网站的最后修改日期(lastmod)和 URL 页面的改变频率(changefreq)。
如果您想要更多的例子，或有对如上所述的元标记有任何疑问，请到我们的谷歌网站管理员讨论组参与讨论。