Standarder

ACID，化学中意为酸，计算机中主要的含义是数据库原理中的事务数据库应该具有的四种基本性质（原子性，Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability））。在WEB标准领域，则是指由The Web Standards Project组织提出的一组浏览器测试程序。
目前ACID有三级，分别是ACID1，ACID2和ACID3。各级ACID测试的偏重点不一样。
ACID1
ACID1使用了一个符合HTML 4.0标准的无意义文档，旨在测试浏览器对CSS1的支持程度。ACID1的通过标准是，浏览器对测试页面的渲染应当完全符合ACID1的参考结果，不能有一像素的偏差。
ACID1的正确渲染参考结果：

IE 7.0.6001.18000测试ACID1的结果：

IE 8.0.6001.17184测试ACID1的结果：

Firefox 2.0.0.12测试ACID1的结果：

Safari 3.1(525.13)测试ACID1的结果：

Opera 9.26(8835)测试ACID1的结果：

可以看出，主流现代浏览器都能正确渲染ACID1。
ACID2
ACID2使用的测试代码，主要是那些已经是标准，但并未被主流浏览器渲染引擎实现的那些特性，其主要目的在于尽力使浏览器在发布之前先通过ACID2测试，以便推行WEB标准。
ACID2通过的标准是浏览器能正确渲染出如同参考结果一样的笑脸，并且不能包含红色块（红色块被设计为都应该被盖住。）实际测试中，我发现人脸鼻子上还会有一个onmouseover事件。
ACID2测试中的笑脸，每一行都进行一个不同的测试，以不同的方式绘出。其测试重点是：

第一行：position: fixed
第二行：position: absolute，attribute selectors, class selectors, absolute positioning, 和floating elements
第三行：width, overflow, universal selector, 和data URLs
第四和第五行：fixed backgrounds，分三层来渲染人眼，应当显示第二层，即fixed backgrounds，第三层的红色块应当被完全盖住。
第六到第九行：generated content和child selectors。
第十和第十一行：collapsing margins。
第十二行：line-height属性
第十三行：parser, cascading mechanism和selectors，主要测试浏览器能不能决定使用正确的CSS来渲染div。
第十四行：CSS表格。
第十四行之后：包含一个64X64像素的红色图片，不应当被显示出来。

ACID2的正确渲染参考结果：

IE 7.0.6001.18000测试ACID2的结果：

IE 8.0.6001.17184测试ACID2的结果(www.webstandards.org网站下)：

IE 8.0.6001.17184测试ACID2的结果(acid2.acidtests.org下)：

Firefox 2.0.0.12测试ACID2的结果：

Safari 3.1(525.13)测试ACID2的结果：

Opera 9.26(8835)测试ACID2的结果：

尴尬的结果，IE7的测试结果，红色泛滥，惨不忍睹。Firefox，就是那么几行差一点点。Safari能够完全正确地渲染，这个结果也可以比较现代浏览器对标准的支持程度，Safari和Opera最好，Firefox差一点，IE7，几乎是另一种语言。
需要注意的是，在webstandard.org下的测试页面，IE8很好地通过了测试，而在另一个地方的同样内容的页面，IE8却停在了某个中间状态。这个状态是Safari和IE8在正确通过的测试中都存在的一个中间状态，是在等待一张背景图片。不知IE8是针对webstandard.org域名专门做了优化，还是其他原因？有些报道称，IE8通过作弊通过ACID2测试。Safari倒是两个地方都正常通过。
ACID3
ACID3的测试重点在于浏览器对于Web 2.0网页应用程序的表现程度，可以被理解为渲染速度和精度。另外，ACID3还测试了webfonts。
ACID3的测试重点是：

DOM2 Core
DOM2 Events
DOM2 HTML
DOM2 Range
DOM2 Style (getComputedStyle, …)
DOM2 Traversal (NodeIterator, TreeWalker)
DOM2 Views (defaultView)
ECMAScript
HTML4 (<object>, <iframe>, …)
HTTP (Content-Type, 404, [...]

Read the rest of 浏览器的ACID Test

和你同坐一桌的，是几个设计师、一个艺术指导以及一个创新指导。大屏幕上播放着你们需要集体评价的一份设计。这将是你们第一次认识原始概念的时候。随着设计稿被一个个翻过，评论也一点点多来。

一个常见的短语是：细节之处见设计。唯有当一份设计给予某些细节，很多情况下是“那些不对的地方”，足够的重视，才能使得这份设计从”几乎合乎要求“到”合乎要求“，甚至超越要求。
我参加了一个会议，在这个会议上，设计师们都是第一次展示自己的设计，参加会议的设计师在屏幕上展示一副原型，他们通常认为这个原型就能达到完成的 90%到100%。但是对于那些追求细节的设计师来说，这份作品只算达到要求的50%到70%。你能看到那些基础工作，并且感觉到那种最终的设计就在你面前，但是同时，你也知道，这并不是完成的作品。
拥抱细节，其最终目的是让你能够审慎地思考，并且在第一轮就尽最大努力拿出你最好的设计。本质上说，你的作品随时能够演示给最终客户。那么，如何才能判断某个设计100%符合要求？你需要达到完美，去除客户脑中所有的疑问。设计师感到匆忙的原因大家都知道：你有一个最终期限，你有压力。但是如果你真正在乎你的作品和你的思想，你会自觉加班加点工作，也许会工作到夜里很晚，我们都曾经这样，然后你知道这样的努力会是你的作品绽放光芒。你知道那种感觉，每当你想的时候都会出现的感觉，”噢，我早就知道我应该试试那个。“为什么第一次的时候没有想到？不要非要等到别人来审查你的设计的时候，你才会想起那些你早已想到的灵感。
每个设计师都有一个装满小技巧的工具包，但是我必须强调的是，追求完美的审慎的眼光，在创作的时候与那些工具同样重要。
这里是一个能帮助你的站点完成完成完成的检查列表，不要留下一小块没用翻过来的石头，不要留下关于作品的一点点疑问，让它绽放光芒。
实验
我不能在第一次内部设计讨论的时候就拿出成熟的作品是很正常的。我通常用一些”素描“体现设计。一个这一次不工作的导航栏或者logo，下一次也许就能工作了。这就是所谓的”美丽的谎言“，在其他环境里安插某些元素，能够创造可能性。仅仅是抛些想法到讨论会上，而不是成为设计阻碍，看看会导致什么。起步往往就是完成的一半。
此外，不要害怕返工。如果一个东西达不到效果，放弃并抛弃它。如果你觉得某个导航条太麻烦了，记住你怎么做出来的，然后在下一个设计中应用这些方法。目标是精炼，一遍又一遍。
选择
设计中经常要做很多选择，包括类型到颜色，到全站风格的所有事情。某些时候，我喜欢把所有的想法都投入到设计中，看看组合在一起会是什么样的效果，某些时候我则喜欢从最简单开始。努力去做那些明智、简单的决定。如果做一件事情的时候，有一个更简单的实现方法，选择它。复杂的选择会使客户感觉繁复且不得人心，除非你能让复杂的东西看起来是简洁的。
保持一致
一旦你做了决定，坚持到底。如果你决定在侧边栏中用10像素隔离各个元素，却在更大的文本框里用了15像素，注意排版反映了这项决定。设计的时候坚持记笔记，这些笔记将会构成风格指南的基础部分。持续地表明态度，并且表示出你完全的理解，然后做出明确的决定。一致性应该是透明的。
完美性
完成你的设计。不要漏掉一个底栏或者别的一项细节。不要说，”这个元素将在后面实现，我现在没有时间“。创造时间。不要给别人攻击你的设计的机会，哪怕在一点点细节上，因为这往往会淹没了设计的其他大部分工作。细节体现了你的努力。创新指导和艺术指导们，尤其是客户，都会对这些细节很在意，所以，保证你的设计中重视了这些细节。
挺近，远离和退出：保持平衡
在做设计的时候，有时候退一步审视你的设计是必要的——哪怕是只有午饭时间和一刻钟休息的时候。做点别的事情。然后回来重新审视你的设计。注意你的第一印象。你的第一反应往往会和那些真正是第一次看到作品的人一样。记录笔记，然后根据这些印象对你的作品进行修订和更改。忽视某些元素有多么地”酷 “和”格调“，如果它不能对你的设计产生正面效应，扔掉它试试别的吧。总是退一步重新审视。
自我批评
如果你对你最近工作的团队很熟悉，或者熟悉你的客户和客户的需求，像审视一个快完成的作品一样审视你的作品，想想那些可能成为问题的部分吧。对你所作的决定准备一份坚实的答案。
简单的复杂：缺少就是多余
当我们讨论”缺少就是多余“的时候，我们通常说很多事情。例如，有些时候设计会需要缩小比例。它包含了太多元素。或者一个设计有如此多的颜色，直到把自己活活憋死。当做细节性的工作时，”缺少就是多余“是关于留下那些仅仅必要的东西，把它们变成同质的。让复杂性变得简单，一个非常复杂的设计往往是最没用的。一个设计应该是实用的、简单的和简单直接的，让复杂通过简洁性展示它的光芒。
困扰是健康的
如果我觉得一个导航条或者flash照片控件怪怪的，我会耐心的坐在那里，一点点调整，直到我找到某个何时的。设计是你自己给自己出的一道谜题，你有所有解题需要的钥匙，但是如何使用它们，就是你需要决定的了。完美不是你能够努力追求的事情，而靠近完美则不然。
我发现我会在一天之内的某些很奇怪的时候想起设计——洗澡的时候，做饭的时候，或者走过街角的商店的时候。小巧的，安静的瞬间往往成为我解决问题的突破点。这些时候往往是我想到解决方案的时候。这些时间可能无法付工资，但是却是你在真正下手做某个设计之前很好的练习时间。我并不经常用铅笔和纸画草图，我喜欢让一个设计在出现在屏幕上之前，首先我的思想中渗透出来。我想象着它看起来的感觉，和所有的细节。我品味那些细节。
细节工作并不简单。它需要花时间，和想象力。但是，却是一个很好的锻炼——它能够让你具备一双审慎的眼光，将来可能会帮助你和你下属的设计师。品味细节，让你的设计变得完美无缺。
原文：Design is in the Details by Naz Hamid

Read the rest of 细节中的设计

进 步总是有代价的。在web浏览器方面，用户要承受开发者由于对开发工具的滥用和任何针对用户所使用的浏览器的假定而带来的代价(尤其是假定成了 Internet Explorer, IE)。当那个被假定的浏览器发布了新的版本，修正了以前的bug，或者改变的某个特性的渲染方式(或者引进了新的特性)以及改变了某种行为，站点就会因 此而崩溃，而我们的客户、经理和用户会感到很失望。
我们可以用几个小时的时间来解释为什么我们的站点崩溃了，但是并不比一开始就避免它崩溃来的好。
一些背景知识
基于带有在CSS支持上有重大改进的Internet Explorer 7发布的冲劲，IE开发组开始着手为IE8制作一个全新的渲染引擎——一个可以尽可能多地遵循CSS 2.1标准的引擎。他们努力工作的一个极致表现是正确地渲染了Acid2测试。对于那些关注者来说，这意味着IE在不久的将来将生成出内容和数据URL，永久地放弃hasLayout，这一点已经得到确认。这一点将会使得它的渲染与同样通过Acid2测试的其他浏览器，如Safari, iCab, Konqueror和Opera，到同一起跑线上。(Firefox 3同样也通过了Acid2，但到撰写此文时并未发布。)
在开发新的渲染引擎过程中，IE开发组对IE 7的反馈很重视。一些标准的狂热者甚至一些微软fans都认为，在IE 7中对bug的修正和对CSS的支持增强方面，开发组做的并不够。但是数量更多的开发者则抱怨，他们原本看起来很好的网站，却在IE 7中不能正确渲染。在他的博客中，标准拥护者Roger Johanssen提出了三个导致错误的原因，鉴于他们对于支持标准的迫切要求，IE开发组发现了第四个原因：DOCTYPE开关，一个开启现代CSS布局核心的技术，因为保证兼容性的缘故，存在着致命地瑕疵。
DOCTYPE开关是坏的
早在1988年，Todd Fahrner就发明了一种能够使浏览器使用两套渲染模式的技巧：一种按照开发者的要求遵循标准，另一种则是为其他人准备的。这个概念非常简洁。当一个客户端遇到一个包含完整遵循了当前HTML标准(例如，HTML 2.0不会省略它)的DOCTYPE声明的文档时，它将假定作者知道她自己在做什么，然后使用遵循标准模式来渲染页面(布局元素使用W3C提倡的盒模型)。但是如果不包含DOCTYPE或者包含了一个不标准的DOCTYPE时，文档将会按照一种“奇异”模式进行渲染，例如，布局元素使用IE 5.x/Windows下的非标准的盒模型进行渲染。
这个概念于两年后首次应用于IE5/MAC平台上，并很快被其它浏览器制造商采用。追随标准的开发者们为了使网页通过标准验证，早已经将一个DOCTYPE包含在他们的网页中，因此浏览器根据这个特性来渲染页面，不会造成多余的代价。那些没有明确的标准化概念的开发者则发现，他们写的页面被浏览器特殊对待，因为他们自己以及他们使用的开发工具，都没能够插入正确的DOCTYPE。
不幸的是，两个关键性因素，共同导致了DOCTYPE成为了判断标准的标准：

由于A List Apart和The Web Standards Project的鼓励，由远见的开发者和开发工具开始在他们编写和生成的标记语言中插入合法、完整的DOCTYPE；
IE6的渲染行为已经有五年没有改变，导致很多开发者以为它的渲染行为是正确的，而且不太可能变化。

两个原因合起来共同导致了DOCTYPE被破坏，因为它有一个致命的缺点，它认为当你使用了DOCTYPE的时候，就意味着当它向标准靠拢的时候，你要为你自己的行为负责，因为你知道你自己是在做什么，并且希望渲染效果越精确越好。我们怎么知道渲染会失效？当IE7推出的时候，站点就惨不忍睹了。
当然，如Roger指出的那样，崩溃的站点中是因为它们使用了IE6特定的CSS技巧(hacks)。但是更多的灾难是由于它们的开发者仅仅在 IE6中检查网站的效果——或者仅仅想关注一下站点在IE6下看起来是什么样子的，因为他们仅仅在一个具备相同浏览器的环境中部署站点（比如，企业的内部 局域网内）。当然，你可以耸耸肩，说既然IE6的渲染错误是已经被很好地整理过的，这些开发者可以更了解这些错误，但是，这样的话，你就忽略了其实很多开 发者根本不曾明确地选择“标准模式”这个事实，或者根本就不知道有这么个模式的存在。
Chris Wilson，Internet Explorer的平台架构师，经常提到说，IE开发过程中的一条核心原则是，IE开发组做出的任何一个决定，不能“破坏现有网站”。遗憾的是，IE7恰 恰破坏了相当一部分开发者的网站。为了避免同样的错误再次发生，Microsoft向The Web Standards Project（我是其会员之一）和几个其他的追求标准的开发者求助，请他们提供一个更好的方法，能够允许开发者“适应到”符合标准的开发上来。这个目标 就是寻求一种方法，能够比DOCTYPE更清楚，并且能够被所有浏览器所实现，而不仅仅是IE。
美好的未来
在去年的SXSW上，我非常有幸地看到New York Public Library’s Carrie Bickner制 （她正好是ALA的作者的妻子，Jeffrey Zeldman）作的一个绝好的发光二极管标语，标语写，“保护我们的数字遗产和私人收藏”，探讨的是当图书馆和私人当试图保留电子存档时遇到的问题。大 部分的问题是文件格式和应用程序的问题：例如，Microsoft Office 2007，不能可靠地渲染一个Word 1.0文档，而大部分人一开始就认为它应该能够正常显示。这个标语引我深思，网络在创作力的推动下是如何改变的，以及网络在标准推行的过程中，将会如何继 续这个变化。
作为一个web标准的支持者，我希望看到浏览器在不停地加进新的特性的同时，能够继续增强对标准的实现，但是同时我认为，浏览器应该保护那些我们已经花了这么多努力——基于表格的布局等，做成的网站。当然，很多从“时间机器”里出来的因为DOCTYPE对 它们的良好保护，不会出现错误，但是，如果一个网站是基于IE6所谓的“标准”模型建设的呢？我们已经看到，很多这种情况，IE7是不会正确地渲染它们 的。这是不是意味着我们要保留一个IE6，以便当我们不能按照作者意图浏览这些网站的时候用？这恰恰是很多图书馆为了能够浏览老的文件所做的事情。IE8 即将诞生，我们面对着同样的潜在问题，就是那些按照IE7渲染引擎编写的文档。如何解决？
原文：Beyond DOCTYPE: Web Standards, Forward Compatibility, and [...]

Read the rest of 超越DOCTYPE: Web标准化，领先的兼容性，还有IE8

XHTML的最终要求是，使得所有网页和浏览器按照而且只按照XHTML 1.0 Strict这个最高标准来控制内容。
传统的FLASH媒体的插入是使用<embed>标签，可惜的是这个标签是不被W3C XHTML 1.0 Strict所认可的，在W3C的FAQ里有过描述。W3C认为，<embed>标记从来就不曾是标准的一部分，只是浏览器大战留下来的炮灰罢了（好像是Netscape一方的）。同时，这篇FAQ里还提到了关于这个问题的一篇著名文章，称为Flash Satay方法。这个方法由Drew McLellan提出，主要思想是通过一个只有一句AS语句的FLASH桥达到载入参数传进的Flash文件的办法。同时，使用<object>标签替代<embed>标签。
可惜的是，这个方法未免太复杂了一些。此外还有很多人想到使用JavaScript来动态加入<embed>的Flash内容，这无异于饮鸩止渴，将表现层和行为层混为一谈，我认为是绝不可取的办法。
Joen Asmussen的博客Noscope里评价了这两种方法，并且指出仅仅使用<object>标签，不使用桥Flash也可以达到在XHTML 1.0 Strict合法的前提下插入FLASH内容的效果。Hixie具体地描述了这个方法。可惜的是，他的代码在我这里只在IE中有效，而在Firefox里却有些问题。这应该是Wordpress自动完成标记的副作用。
经过我的实验，可以正常使用的代码如下所述：
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0" width="480" height="400">
    <param name="movie" value="movie.swf" />
    <param name="quality" value="high" />
    <param name="bgcolor" value="#FFFFFF" />
    <object data="movie.swf" width="480" height="400" type="application/x-shockwave-flash">
        <param name="quality" value="high" />
        <param name="bgcolor" value="#FFFFFF" />
        <param name="pluginurl" value="http://www.macromedia.com/go/getflashplayer" />
    </object>
</object>
为了在Wordpress里面直接用而避免编辑器进行不必要的转换，建议使用下面这个无换行版。
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0" width="480" height="400"><param [...]

Read the rest of 如何在XHTML 1.0 Strict合法的前提下插入FLASH内容