几乎成为CSS的语言

当Tim Berners-Lee在1991年宣布HTML时，还没有设计页面样式的方法。如何呈现给定的HTML标记由浏览器决定，通常由用户的首选项提供重要输入。然而，创建一种标准的方式让页面“建议”它们可能更喜欢的风格呈现方式似乎是个好主意。

但是CSS在五年内不会引入，在十年内也不会完全实现。这是一段紧张的工作和创新的时期，这导致了许多竞争的造型方法，而这些方法很容易就可以成为标准。

虽然这些语言在今天显然并不常用，但我觉得想一想当时的世界是很有趣的。更令人惊讶的是，即使在今天，这些选项中的许多其他选项也包含开发人员希望出现在CSS中的特性。

1993年初，Mosaic浏览器还没有达到1.0版本，而那些已经存在的浏览器只处理HTML。没有任何方法可以指定HTML的样式，这意味着无论浏览器决定h1>；应该是什么样子，这就是您得到的。

那年6月，Robert Raisch向www-talk邮件列表提出了一项建议，即创建一种“与Web文档一起传递文体信息的易于解析的格式”，该格式将被称为RRP。

您完全不知道这段代码在做什么，这是情有可原的。在gzip之前的时代，当连接速度徘徊在14.4k左右时，让这种新格式的内容尽可能简洁是有意义的。这条特殊的规则是将字体系列(Fa)设置为Helvetica(He)，将字体大小(Si)设置为18磅。

这个提案中遗漏了一些有趣的东西，没有提到单位，所有的数字都是根据它们的上下文来解释的(例如，字体大小总是中点)。这可以归因于RRP更多地被设计为“对呈现器的一组提示或建议”，而不是一种规范。这被认为是必要的，因为相同的样式表需要在普通的行模式浏览器(如Lynx)和日益流行的图形浏览器上都能运行。

有趣的是，RRP确实包含了一种指定栏目布局的方法，直到2011年才会出现在CSS中。例如，三列，每列宽度为‘80个单位’，如下所示：

它有点难于解析，但并不比空格差多少：现在可能是rap。

值得注意的是，RRP不支持我们今天与样式表关联的任何“级联”。一个给定的文档一次只能有一个活动样式表，这是考虑设计文档样式的一种合乎逻辑的方式，即使它对我们今天来说是陌生的。

Marc Andreessen(Mosaic的创建者，后来成为最受欢迎的浏览器)知道RRP建议，但Mosaic从未实施过。相反，Mosaic很快(有点悲哀地)沿着使用HTML标签定义样式的道路前进，引入了像<；font>；和<；Center>；这样的标签。

那么，为什么你不干脆从摆在桌面上的众多样式表提案中选择一个来实现呢？如果操作得当，这将在很大程度上解决问题。

然后我告诉人们，好吧，你可以学习这种语言来写文档，然后你可以学习这种语言，让你的文档看起来像你想要的样子。哦，他们会喜欢的。

与流行的看法相反，Mosaic并不是第一个图形浏览器。它早于ViolaWWW，这是一款最初由佩佩-袁卫在短短四天内编写的图形浏览器。

培元创造了一种样式表语言，它支持我们今天在CSS中习惯的一种嵌套结构形式：

在本例中，我们将颜色选择应用于主体，并具体设置出现在主体内的H1的样式。PWP没有使用重复选择器来处理嵌套，而是使用了圆括号系统，这让人联想到Stylus和Sass等语言使用的缩进系统，而现在一些开发人员更喜欢这种缩进系统而不是CSS。这使得PWP的语法至少在一个方面比CSS语言更好，CSS语言最终将成为Web的语言。

PWP还引入了引用我们今天仍在使用的外部样式表的方法，这一点也值得注意：

不幸的是，ViolaWWW的编写主要是为了与仅在Unix系统上流行的X WindowingSystem一起工作。当Mosaic被移植到Windows上时，它很快就让Viola黯然失色。

HTML是那种只有计算机科学家才会喜欢的东西。是的，它表达了文档的底层结构，但文档不仅仅是结构化的文本数据库；它们具有视觉效果。HTML完全消除了文档设计者可能拥有的任何视觉创造力。

正如您可能知道的，我们所知道的HTML最初是基于一种称为SGML的前互联网语言。1987年，美国国防部决定研究是否可以使用SGML来更容易地存储和传输他们处理的海量文档。就像任何好的政府项目一样，他们没有浪费时间想出一个名字。该团队最初被称为计算机辅助后勤支持团队，然后是计算机辅助采购和后勤支持团队，最后是持续采购和生命周期支持计划。不管怎么说，名字的首字母都是CAL。

CALS团队创建了一种用于样式化SGML文档的语言，称为FOSI，它无疑是一种缩写，它代表了四个单词的某种组合。他们为这种语言发布了一个规范，它既全面又难以理解。它不包括我最喜欢的一张永远存在于网络上的无意义的信息图表。

互联网的一条不可违反的规则是：如果你能在这个过程中证明某人是错的，那么你总是会做更多的事情。1993年，就在培元提出建议的四天后，史蒂文·希尼(Steven Heaney)提出，与其“重新发明轮子”，不如使用FOSI的变体来设计网络样式。

FOSI文档本身就是用SGML编写的，考虑到已经熟悉SGML变体HTML的Web开发人员，这实际上是一个逻辑上的举动。示例文档如下所示：

<；outspec>；<；docdesc>；<；charlist>；<；font size="；12pt"；bckol="；White"；fontol="；Black"；>；<；/charlist>；<；/docdesc>；<；e-i-c gi="；H1&。白色"；>；/e-i-c>；<；e-i-c gi="；h2"；>；<；font size="；20pt"；bckol="；红色&34；，fgol="；白色&34；>；<；/e-i-c>；<；e-i-c>；<；/e-i-c>；<；e-i-c gi="；cmd kbd屏幕列表示例"；>；<；FONT style="；monoser"；>；<；/e-i-c>；<；/outspec>；

如果你对什么是docdesc或charlist感到有点困惑，那么www-talk的成员也是如此。给出的唯一上下文信息是e-i-cc意思是“上下文中的元素”。然而，FOSI值得注意的是引入了emunit，它现在已经成为比您更了解CSS的人设计样式的首选方法。

正在上演的语言冲突实际上和编程本身一样古老。这是函数式“LISP风格”语法与更多声明性语言的语法之争。培元自己形容自己的句法是“口齿不清”，但真正的口音变体上台只是时间问题。

尽管FOSI非常复杂，但它实际上被认为是格式化文档问题的中间解决方案。长期计划是创建一种基于函数式编程语言方案的语言，它可以实现您能想象到的最强大的文档转换。这种语言被称为DSSSL。用撰稿人乔恩·博萨克(Jon Bosak)的话说：

将DSSSL与脚本语言放在同一个袋子里是错误的。是的，DSSSL是图灵完全的；是的，它是一种编程语言。但是脚本语言(至少我使用这个术语的方式)是过程性的，而DSSSL绝对不是。DSSSL完全是功能性的，并且完全没有副作用。DSSSL样式表中从不发生任何事情。样式表是一个巨大的函数，它的值是对格式化文档的抽象的、与设备无关的、非过程性的描述，它作为显示区域的规范(如果您愿意，可以说是一个声明)提供给下游呈现过程。

(DEFINE(CREATE-HEADING-HEADING-FONT-SIZE)(使段落字体大小：HEADING-FONT-SIZE FONT-WEIGHT：'；粗体))(元素H1(创建-标题24pt))(元素H2(创建-标题18pt))。

并在您的样式中使用数学构造，例如，对表的行进行“条带化”：

作为激起嫉妒的最后一种方式，DSSSL可以将继承值视为变量，并对其进行数学运算：

不幸的是，DSSSL确实有一个致命的缺陷，这个缺陷会困扰所有与Scheme类似的语言：太多的括号。此外，当它最终发布时，它可以说是一个太完整的规范，这使得它对浏览器开发人员来说是令人畏惧的。DSSSL规范包括210多个单独的可样式属性。

该团队确实继续创建了XSL，这是一种用于文档转换的语言，它同样令人困惑，但肯定会更受欢迎。

CSS不包括父选择器(一种根据父选择器包含的子项设置其样式的方法)。Stack Overflow海报长期以来一直在哀叹这一事实，但事实证明，它的缺席是有很好的理由的。特别是在互联网的早期，人们认为在文档完全加载之前页面可以呈现是至关重要的。换句话说，我们希望能够在构成页面底部的HTML完全下载之前将HTML的开头呈现给页面。

父选择器意味着样式必须随着HTML文档的加载而更新。像DSSSL这样的语言完全过时了，因为它们可以对文档本身执行操作，而这些操作在呈现开始时并不完全可用。

第一个提出这个问题并提出可行语言的贡献者是伯特·博斯(Bert Bos)在1995年3月。他的提案还包含“笑脸”表情的早期版本：-)。

他的语言还有一个很酷的特性，可以定义像Links这样的特性在样式表本身中是如何工作的：

在本例中，我们指定link元素的目标是其href属性的值。这个想法，像链接这样的元素的行为应该是可控的，在几个提案中很受欢迎。在erapre-JavaScript中，没有一种现有的方法来控制这类事情，因此将其包括在这些新的提案中似乎是合乎逻辑的。

1994年，一位名叫C·M·斯珀伯格-麦昆(C.M.Sperberg-McQueen)的绅士提出了一项功能性建议，在功能上包括相同的行为：

(样式a(block#f)；格式为内联短语(蓝色)；如果有，请使用蓝色(单击(Follow(attval'；href)；单击后，跟随url

他的语言还引入了Content关键字，作为控制样式表中HTML元素内容的一种方式，这个概念后来被引入到CSS2.1中。

在我谈论成为CSS的语言之前，值得一提的是另一种语言方案，因为它在某种程度上是早期Web开发人员的梦想。

在当时的命名约定中，PSL96是1996年版的“表示规范语言”(Presentation Specification Language)。PSL的核心看起来像CSS：

然而，它很快就变得更有趣了。例如，您可以不仅根据为它们指定的大小(宽度)来表示位置，还可以根据浏览器呈现的实际(实际宽度)大小来表示它们：

您还会注意到，您可以使用左侧同级元素作为约束。

还可以将逻辑表达式添加到样式中。例如，要仅设置具有href的锚定元素的样式，请执行以下操作：

A{if(getAttribute(self，"；href"；)！="；"；)则fgColor="；Blue"；；underlineNumber=1；endif}。

该样式可以扩展到做我们今天借助类来完成的所有事情：

LI{if(ChildNum(Self)==round(NumChildren(Parent)/2+1))Then VertPos：Top=Parent.Top；HorizPos：Left=LeftSib.Left+Self.Width；Else VertPos：Top=LeftSib.Actual Bottom；HorizPos：Left=LeftSib.Left；endif}。

对这样的功能的支持或许可以真正实现将内容与样式分离的梦想。不幸的是，这种语言由于可扩展性太强而受到困扰，这意味着它的实现在不同的浏览器之间有很大的不同。此外，它是在学术界的一系列论文中发表的，而不是在www-talk邮件列表上发布的，而大多数功能工作都是在www-talk邮件列表上完成的。它从未集成到主流浏览器中。

至少在名字上会直接导致CSS的语言被称为CHSS(层叠HTML样式表)，由Hakon W Lie在1994年提出。

请注意规则末尾的百分比。这个百分比指的是当前样式表在多大程度上“拥有”这个值。例如，如果以前的样式表将H2字体大小定义为30pt，所有权为60%，而此样式表将H2S样式定义为20px40%，则这两个值将根据它们的所有权百分比进行组合，以获得约26pt的值。

这一建议是如何在基于文档的HTML页面时代提出的，这是相当清楚的，因为基于折衷的设计在面向OURAP的世界中是不可能奏效的。尽管如此，它确实包含了样式表应该层叠的基本思想。换句话说，应该可以将多个样式表应用于同一页。

就其最初的表述而言，这一想法通常被认为是重要的，因为它使最终用户能够控制他们所看到的内容。原始页面将有一个样式表，Web用户将有他或她自己的样式表，这两个样式表将组合在一起呈现页面。支持多个样式表被视为维护Web个人自由的一种方法，而不是支持开发人员的一种方式(开发人员仍在手工编写单个HTML页面)。

用户甚至可以控制他们对页面作者的建议有多大的控制权，如提案中的ASCII图所示：

就像这些提案中的许多一样，它包含的功能在几十年内都不会出现在CSS中，如果曾经出现过的话。例如，可以根据用户环境编写逻辑表达式：

年龄&>；3D？Backround.color=PALAR_黄色：backround.color=WhiteDISPLAY_HEIGHT>；30 cm？Http://NYT.com/style：http://LeMonde.fr/style。

在对未来的一种乐观的科幻愿景中，人们相信你的浏览器会知道给定的内容与你有多相关，从而允许它以更大的尺寸向你展示：

Hakon Lie继续简化了他的建议，并与Bert Bos合作，在1996年12月发布了CSS规范的第一个版本。最终，他会写关于CSS创建的博士论文，这对我写这篇文章有很大的帮助。

与许多其他方案相比，CSS的一个值得注意的事实是它的简单性。它可以很容易地解析、很容易编写和很容易阅读。与互联网历史上的许多其他例子一样，对于初学者来说，最容易掌握的技术才是获胜的，而不是那些对专家来说最强大的技术。

这本身就提醒人们，这种创新在很大程度上是偶然的。例如，添加对上下文选择器(Body Ol Li)的支持只是因为Netscape已经有了一种方法，可以从超链接的图像中去除边框，而且似乎有必要实现流行浏览器所能做的所有事情。(=。该功能本身给CSS的实现增加了很大的延迟，因为当时大多数浏览器在解析HTML时并没有保留标签的“堆栈”。这意味着必须重新设计解析器以完全支持CSS。

像这样的挑战(以及非标准HTML标签的广泛使用来定义样式)意味着CSS直到1997年才能使用，直到2000年3月才得到任何单一浏览器的完全支持。正如任何开发人员都会告诉你的那样，直到几年前，也就是CSS发布15年多之后，浏览器支持才接近标准兼容。

如果Netscape 4忽略了应用于<；body&>元素的CSS规则，并在页面上的每个结构元素上添加了随机数量的空格，如果IE4的<；body&>填充正确但却糟糕透顶，那么编写什么样的CSS才是安全的呢？有些开发人员选择根本不编写CSS。其他人写了一个样式表来弥补IE4的缺陷，写了一个不同的样式表来弥补Netscape 4的错误。

Internet Explorer3发布时支持CSS(有点糟糕)是出了名的。为了竞争，决定Netscape 4也应该支持这种语言。不过，与其在第三种语言(考虑HTML和JavaScript)上加倍努力，还不如通过将CSS转换为JavaScript并执行它来实现它。更好的是，他们决定这个“JavaScript样式表”中间语言应该对Web开发人员开放。

EVALUATE_STYLE(){if(color=="；red"；){fontStyle="；italic"；；}Else{fontWeight="；粗体"；；}}tag.UL.ply=EVALUATE_STYLE()；

我们应该简化风格和脚本之间的分界线的想法当然是合理的，现在甚至在Reaction社区中正在经历某种形式的复兴。

JavaScript本身在当时还是一种非常新的语言，但是通过Smerverse工程，Internet Explorer已经在IE3中添加了对它的支持(称为“JScript”)。更大的问题是，社区已经团结在CSS周围，而此时，Netscape被大多数标准社区视为欺凌弱小。当网景向标准委员会提交JSSS时，它被置若罔闻。三年后，Netscape 6放弃了对JSSS的支持，它(基本上)悄无声息地死去了。

由于W3C的一些公开羞辱，Internet Explorer5.5在2000年推出，几乎完全支持CSS1。当然，正如我们现在所知，BrowserCSS的实现至少在未来十年内都存在巨大的缺陷，很难使用。今天，幸运的是，情况已经有了很大的改善，允许开发人员最终实现一次编写代码的梦想，并相信它将在不同的浏览器之间(几乎)运行相同的功能。

我个人从所有这一切中得出的结论是，我意识到管理我们当前工具的许多决定是多么武断和有背景的。如果CSS的设计方式仅仅是为了满足1996年的约束，那么也许这就给了我们20年后做一些稍微不同的事情的许可。

在我们的下一篇博客文章中，我们揭露了使铜线从莫尔斯代码演变到10Gbps Cat6以太网的巨大创新。订阅下面的内容，当它发布时会收到通知。