当4.0浏览器出现后，虽然依旧bug多多且不完善，但IE4比IE3大大改良了对CSS的支持。Netscape 4在最后一刻也决定首次支持CSS。

坦率地说，Netscape 4对CSS的支持远远好于IE3（http://www. webreview.com/style/css1/leaderboard.shtml）。但是当今几乎没有人使用IE3，却有好几千万人仍然使用Netscape 4。这样，许多站点拥有者开始被迫支持Netscape 4——这是一个错误的支持。总的来说，这是一件好事情，设计和交互保持了一致性，这也是一件坏事，因为束缚了开发者的手脚，强迫他们写糟糕的代码和无用的标记。

3.4.1  默认样式的缺点

Netscape 4在支持CSS上有很多失败，主要的失败在于默认样式和缺乏继承。

CSS的设计目的是从结构中抽象出表现，并没有假定它要支持和显示多少元素，也没有假定哪种置标语言。而浏览器却经常做这些假定（一些现代浏览器使用CSS强迫假定一些默认样式并允许设计师的样式表覆盖它们）。在大多数浏览器的默认状态下，在没有CSS的时候，<h1>标题将是一个大而粗的字体，上下都保留一定空白。

CSS能让你改变哪些呢？使用CSS，<h1>可以是小的，斜体的，空白可自由留出，就像设计的那样。哎，在Netscape 4中就不行。默认情况下，它在设计师指定的CSS规则中加入默认规定的表现。如果你在CSS中设定大标题下面没有空白，Netscape 4还是会抢先在标题下方插入一个空白。

当设计师在标准的HTML标记上应用CSS时，他们很快发现IE4大体能表现出他们想要的，而Netscape 4则总是弄乱他们的布局。

一些设计师放弃了CSS，另外一些设计师从开始就工作在不断的问题中（很悲哀，包括我），避开结构标记，采用像<div class=”headline1”>语句代替<h1>。这样做解决了显示问题却损失了文档的结构和语义。因此，将短期利益放在长期生存之前带来了无数的问题，现在我们终于尝到了自己种下的苦果。

自从放弃破坏文档结构的习惯，到写这本书已经很长时间了，但是大多数的设计师和开发者依然用向前兼容Netscape 4的借口写垃圾标记，这是标准化实践过程中的遗憾。在努力使数据驱动的工作流规范化与合理化的过程中，的确会产生可访问性的问题。

那些在4.0浏览器时代开发的系统，如内容管理系统、发布工具和可视化Web编辑器（又称WYSIWYG编辑器）等，产生大量的无意义的垃圾标记，这给引导网站采用标准开发或者将原有内容转换到XML驱动的数据库，带来巨大的困难和高额的费用。一个大型站点由多个设计师和开发者共同创建维护，每个设计师可能使用不同的非标准的标签，这使得集中所有数据，按照更有用的方案重新格式化变得不可能（想像一下，一个已经建立索引的公共图书馆，不是用杜威图书分类法，而是按照奇怪的Joe、Mary和各种各样其他的分类，每个分类用他们自己制定的规则编辑整理，会乱成什么样子）。

在图形浏览器以外的领域，使用无意义的非结构标记也会使页面变得难以访问。对于一个Palm Pilot、Web智能电话或者屏幕阅读器的用户来说，<div class="headline1">只是一个文本，而不是一个标题。因此，我们必须购买或开发内容管理系统，将这批非标准标签转换为标准标签。否则我们只能强迫Palm Pilot、Web电话和屏幕阅读器用户浏览在结构上无意义的代码标记，并猜测我们的含义。

我们感谢Netscape 4（以及我们适应它的缺点的积极主动性）让我们陷入这场混乱。所以我们也不会奇怪，那些Netscape和Mozilla工程师需要在Mozilla项目中花费长达4年的时间，他们根本无法借鉴原有产品的代码。

3.4.2  缺乏继承

Netscape 4在理解和支持继承上也很失败。这个潜在的闪耀的继承概念给了CSS强大的力量，CSS通过授予的通用规则而格式化所有子标签，除非设计师特别指定某个子标签的样式规则，这样做的好处是可以减少带宽。

例如，用CSS你可以在body标签中定义一个字体、尺寸和颜色，同样的字体、尺寸和颜色将作用在body标签的所有子标签中，从<h1>到<p>以及更多。但是在Netscape 4中却不是这样，在Netscape 4中是2+2还是等于2+2，而不是等于4。

有一定经验的开发者在浏览器缺乏支持继承下徘徊时，就会写出多余的规则：

在上面的例子中，td、h1和p选择器是多余的，因为在任何符合标准的浏览器中，子标签的样式将自动继承父标签的样式。

经验不足的开发者会把规则写全，这样的方法是冗余和浪费带宽的：

这样的方法，它虽然浪费了用户和服务器的带宽，但也能使工作完成。另外的一些开发者则断定CSS不能工作在Netscape 4中，或者CSS有缺陷（他们的想法是错误的，但是有这样理解的人却很多）。

Netscape 4 还有其他CSS的缺点——足够填满一个大城市的黄页了。但是，它已经足以扰乱局面，也足以妨碍CSS标准的广泛采用。

3.4.3  混乱的交互行为

伴随着CSS技术实现的混乱，早期的浏览器也没有通过一个通用的脚本方法来促进交互行为的成熟。每一个支持脚本的浏览器都有一个对象模型，它可以规定哪种浏览器行为能够应用在页面上。Netscape 4有一个私有的document. layers模型，IE4也使用自己私有的document.all模型。这两个浏览器都不支持W3C DOM。那些想在站点中显示交互行为的开发者不得不写两种代码适应不同的浏览器，支持早期的浏览器（向前兼容）需要更多的代码和条件跳转，就像第2章描述的那样。

早期的浏览器甚至不能运行一个普通的脚本语言。在早期，Netscape发明了JavaScript，承诺将其开放为标准，这样其他浏览器开发商就能支持它。但是几年后，尽管他们答应开放，Netscape依然掌握着JavaScript的秘密，并把它看成是一个竞争优势（如果Navigator是支持JavaScript的惟一浏览器，为什么别人要在支持JavaScript稍差的浏览器上开发呢。所以Netscape有充分的理由这样做。如果处于相同情况，Microsoft也可能这样做。事实上，Microsoft已经采用私有的ActiveX技术这么做了）。

为了竞争，Microsoft对JavaScript进行了反向工程，按照他们的方法做一些改变，这在反向工程中是常见的。结果就是这种语言工作像JavaScript，但又不完全像JavaScript。这两种语言的差别足够把你搞糊涂。Microsoft称他们的脚本语言为JScript。其间，Microsoft提供了一个独立的ActiveX技术，设想是能在所有版本的IE浏览器中提供无缝的交互功能，但实际上只能正确工作在Windows平台上。

JScript，JavaScript，ActiveX：在跨浏览器和向前兼容的技术气氛下，开发者发现他们自己必须与多个技术“跳舞”，但是他们的节奏都不一样——客户不得不承担不断提高开发和测试费用。

3.4.4  最终的标准化脚本语言

最后，ECMA批准了一个JavaScript的标准版本，他们命名为ECMAScript（www.ecma.ch/ecma1/STAND/ECMA-262.HTM）。W3C也及时出版了标准的DOM规范。终于，Netscape和Microsoft都支持这两个规范。但是几年前两者仇敌般的对立已经使得许多开发者在私有的、不兼容的脚本技术和对象模型方面成为专家，也使许多站点拥有者以为Web发展总是诸侯纷争的，因此，还会有只支持IE的站点、残缺的检测脚本，另外一些案例中则放弃Web标准而采用像Flash的专利技术方案。

顺便说一句，如果你想了解ECMA代表什么，不要试图去访问这个令人讨厌、混乱的官方网站。ECMA是European Computer Manufacturers Association（欧洲电脑制造商联合会）的缩写，它是个好的标准的制定组织，而不像W3C只把标准称为“推荐”。糊涂的网站和使人困惑的标签是另一个标准在现代Web广泛普及困难的原因之一，我们将在下一节详细论述。