为什么CSS是这样的呢？

作为万维网联盟(W3C)的技术总监，我经常谈论CSS的强大特性和功能。但时不时地，我会被问到不好的部分。为什么CSS有功能X，而功能Y有更多的功能呢？为什么功能Z如此难以使用？基本上，CSS小组的想法是什么？

CSS在1994年首次亮相，当时Web浏览器还是一项非常新的、相对未开发的技术。人们仅仅是看到世界各地其他计算机上的文档就很兴奋-而且不仅是纯文本的，而且还有标题和列表！增加对演示的更好控制大多被视为次要目标。

当时常用的两个浏览器，Internet Explorer和Netscape Navigator，具有完全不同的文档对象模型，并且对于在何处添加表示控件存在广泛的分歧：向HTML添加一些属性，通过脚本更改样式，或者，最不受欢迎的选项，创建完全不同的表示语言。对于一个从大学扩展到普通公众的网络来说，最后一个选择被认为过于学术性。

作为一种不时髦的选择，CSS的成功很重要的一点是，它被视为简单和直接的-实际上，对于主要是网络代码的内容来说，这是一个小小的补充。一个功能更丰富的提议很可能在第一个障碍就失败了：如果没有人实现它，那么CSS就不会对快速发展的互联网产生任何影响。

问题是为什么CSS会是现在这样？“。是一个合理的选择。而且，我从CSS的第一天开始就参与其中，所以我(有时很痛苦地)意识到了答案。CSS随着时间的推移缓慢而递增地增长，已经演变成现代网络的一个功能齐全、必不可少的部分。但尽管我们尽了最大努力，令人沮丧或令人困惑的功能仍然存在，而且很可能会继续增加。因此，对于现在和未来的用户来说，了解CSS为什么是这样的，并了解我经常被问到的功能背后的背景故事是很有用的。

CSS的一些最早的特性，在当时是必要的，后来造成了无数的问题，并积极地阻碍了对CSS的改进。

对于熟悉FlexBox和Grid的现代设计师来说，CSS的第一个布局特性Float非常原始。将图像完全向左(或向右)移动，文本将显示在右侧(或左侧)，而不是直接跳过图像并留下难看的空白。仅此而已。

至关重要的是，使用HTML表格不能轻松实现此效果-至少在您仍计划修改文本的情况下不是这样-而且表格是增强布局的主要竞争对手。在最初开发时，Float对页面的外观产生了真正的影响，因此被广泛使用。它几乎没有提供额外的控制，甚至在稍微复杂的情况下也严重不足，这是一个稍后需要解决的问题。

这就是“目前足够好”的哲学解释了为什么CSS中的颜色最早是在RGB中指定的-已经知道这是一种不直观的、用户不友好的语法-即使有更好的系统也是如此。工程师可以理解RGB，不需要设备校准，并且是您发送给图形驱动程序的内容。一些小细节，如一致性、可用性和获得合适颜色的简易性，可以在以后解决。很久很久以后，事实证明。

一旦功能到位，稍微改进它比添加一个新的、更好的、但完全不同的功能做同样的事情要容易得多。

例如，这解释了为什么最初在CSS中通过扩展Float的角色来指定列表标记。(列表标记是向左浮动的，因此列表项文本在其周围向右换行。)。这一努力被放弃了，取而代之的是列表样式的Position属性，该属性的定义目前具有以下不太鼓舞信心的内联问题：这是CSS2中的胡说八道，需要一个真正的定义。

这也解释了为什么在CSS中指定颜色的前两个改进-命名颜色系统和色轮极轴表示法-比同时提出的更好但更复杂的系统要好得多。它们是轻微的改进，被视为易于实施。

你想象鲜艳的深蓝色、“非常深的绿色”或淡淡的浅红橙色是什么样子？这些是Toby Berk和合著者在IEEE Computer Graphics and Applications(IEEE计算机图形和应用程序)1982年发表的一篇论文中描述的颜色命名系统(CNS)的示例，我在1996年9月建议CSS采用该论文。

将这些与兰花、“Gainsboro”或宝莱坞形成对比。这些是X11颜色的示例，它们在2000年添加到SVG中，然后在2003年添加到CSS中。用形容词修饰或提炼这些颜色名称是不可能的，就像在CNS中一样；你基本上需要记住或参考整个颜色列表。

那么发生了什么？在早期，对大型颜色列表的标准化存在阻力：内存小而昂贵，特别是在智能手机之前的新兴手持设备上。然后，当这种抵触情绪消退时，Unix工作站X11的名称已经蔓延到更流行的Mac和PC实现。最后，将CNS颜色转换为s RGB的完整算法没有在原始论文中发表，我联系原始作者的努力也没有成功。这个想法失去了动力，我们转而选择了阻力最小的道路。

几个世纪以来，艺术家们一直熟悉圆形彩虹排列颜色的概念。将这个轮子延伸到中心的黑色、灰色和白色，并向边缘逐渐增加更鲜艳的颜色，也有类似的悠久历史。不太常见的情况是，色轮设计师小心地将轮子周围的颜色均匀分布，使它们看起来不会在任何一个区域聚集在一起。1929年出版的孟塞尔颜色书(Munsell Book Of Color)是第一本在这方面取得成功的书

1976年，国际照明委员会(或CIE，其法语名称国际委员会的缩写)标准化了源于物理测量的颜色的三维表示，对应于人眼看到颜色的方式。在这个被称为CIELAB的系统中，两种颜色之间的距离与它们在视觉上的不同程度直接相关，这一概念被称为知觉一致性。由此衍生出的色轮CIE LCH(代表亮度、色度、色调)将孟塞尔色彩系统的可用性优势与科学严谨和对任何有色目标的直接物理测量结合在一起。

不幸的是，当CSS工作组在2002年将色轮系统添加到CSS中时，取而代之的是极差的HSL(代表色调、饱和度、亮度)系统，该系统缺乏CIE LCH的感知一致性。在它中，亮黄色和深蓝色具有相同的HSL亮度，色调在某些地方聚集在一起，但在其他地方却分布得很广。采用的原因是希望拥有某种色轮系统，不依赖显示器校准，以及使HSL值转换为RGB比CIE LCH更简单的数学运算。由于HSL已经在其他程序中广泛使用，HSL似乎可以很容易地添加到CSS中，但是当开发人员使用CSS预处理器在CSS中实现设计系统时，缺点-主要是非感知一致性-将受到沉重打击。(这也是CSS Color 5启动的原因，也是为什么四位合著者中有两位是设计系统和专家的原因。)。

有时，一个特性被添加到CSS草稿中，但没有人有时间或专业知识来审查它。通常，在规范开发的候选推荐(CR)阶段，测试实现会捕获麻烦的特性。但并不总是如此。

一个值得注意的例子是unicode-range的语法，它用于指示您不想使用的字体中的字符范围。这是应Unicode联盟在1997年5月的请求而添加到CSS2中的。当时，Unicode是全新的，有点实验性。为了将Unicodes与更常见的ASCII或拉丁文-1代码区分开来，人们使用前缀U+。(现在已经没有人这样做了。)。在接下来的一个月里，我想出了一个紧凑的语法来表示范围；它假设您有Unicode规范的副本可供参考，并且熟悉十六进制表示法和通配符。

如果您认为此语法不好(确实是这样)，请考虑唯一的替代方案是Unicode 1.1版的完整位图：

经过一周的邮件列表讨论，没有任何改进建议，大家一致认为我的语法现在已经足够好了。(哈！)。我们将其添加到规范中，认为以后总是可以改进它。(这是在CR测试成为一件事之前的几年。)。23年过去了，我们仍然在使用它，我仍然为使用它而道歉。

实际的实现测试发生在2013到2018年间，CSS字体级别为3，它解决了很多错误，并精确地定义了角落案例。即便如此，这种语法还是很笨拙，特别是对于范围不连续的语言，比如中文。它需要在CSS解析器中进行特殊处理，并且随着添加的字符越来越多，跟踪Unicode规范修订的工作也会给样式表作者带来负担。不是很好。

对一些建议进行了审查，看起来不错，并付诸实施。几年后，他们的缺点变得越来越明显。

最好的例子是Display属性。这主要用于指定特定元素是应该呈现为段落、前后各有新行(块)，还是应该呈现为一系列样式文本作为段落的一部分(内联)。1996年8月的CSS初稿也没有添加任何内容，完全禁用了呈现。从那时起，增加了更多的价值。

尽管脚本语言和动态修改还没有变得普遍，但回过头来看很容易就会发现这个问题。假设我使用脚本将值设置为None来隐藏它。后来，我想把它揭开，但是现在房产的原值已经没有了。

此外，较新的值(如inline-block)清楚地表明，该属性做两件事：更改元素周围的其他元素的外观(inline-block在外部看起来就像inline)，以及更改元素对其子元素的外观(inline-block在内部看起来就像block)。更不用说我之前提到的隐藏/不隐藏行为了。

幸运的是，CSS有一种机制来处理这组相关属性：速记。速记是一种一次设置多个指针值的方法。因此，在将来，CSS可以添加三个普通属性，例如，Display-Outside、Display-Inside和Display-Hidding；后者将取代None和Not-None值。然后，现有的Display属性将成为设置三个字段LongHands的值的速记形式。

并不是说速记属性就是灵丹妙药。第一个CSS提案中最初的速记属性之一是字体，其目的是模仿传统的排版速记符号来设置与字体相关的多个属性。以此为例：

这里，700是0到999刻度范围内的字体粗细，12pt是字体大小，14pt是前导(行间大小)，引号中的字符串是字体系列名称。重量可以省略，默认为400。如果能省略尺寸就好了，但我们不能这么做。为什么？因为，不幸的是，CSS允许省略引号。

由于姓氏恰好以数字开头，这会给速记带来歧义。

尽管我已经强调了CSS的许多缺点，但请不要灰心丧气。我有振奋人心的消息来鼓舞士气(至少有一点)。首先，在被忽视了20多年之后，CSS Color4中的LCH现在正由苹果在Safari中实现。也有将其添加到Chrome中的举措。依赖于感知上均匀的颜色空间的颜色修改功能最终将能够利用LCH。其次，CSS工作组目前正在设计一项提案，为Unicode范围添加Unicode脚本代码和数字。它将允许开发人员编写易于记忆且免维护的CSS，如Unicode-Range：Japan。第三，所有CSS工作组规范及其相关问题现已在GitHub上维护了五年多。任何感兴趣的公众成员都可以为解决问题或指出错误做出贡献。专家说：你帮不上忙！