CSS 双斜线注解语法

现况

先来看看现在标准／浏览器到底支不支持双斜线单行注解：

span {
// font-weight: normal;
// line-height: 100%; color: black;
// 假注解
margin-left: auto;
}

span {
color: black;
}

上面上图（可以编辑）是输入的 CSS，下图是浏览器丢弃解析错误宣告后的结果。从这个例子的三个（伪）双斜线注解的解析结果可以观察出几件事情：

1. 在最常用双斜线注解的情形：注解掉一个宣告，结果会如同预期，这会让有些 CSS 新手以为 CSS 早已有双斜线单行注解了。
2. 实际上 // 并不是单行注解，而只是语法错误的宣告的一部分，它会连同到下一个 ; 或 }（宣告尾端字符）为止的字符串一起被省略，而 color: black; 是下一个宣告，因此不会受到影响。把 // 换成 ++ （动手试试吧！）或是其他会造成语法错误的东西会得到一样的结果。
3. 在不是注解掉某宣告而是加入额外说明的情形下，同 2. 的情形，浏览器会把 // 到下一个 ; 或 } 中间的东西当成错误，所以连 margin-left: auto; 一起丢了。

结论是除非整个团队都了解 // 并不是单行注解，而只在上面 1. 的情况使用以外，这里并不建议在 CSS 代码里使用这样的东西（虽然这个规则应该比辨别 JS 不用加分号的规则简单很多）。另外，使用 // 会让浏览器在控制台抛错。

这个提案为什么不好采纳？

双斜线注释这种程度的特性，真要实现起来大约也只是五行 C++ 代码，但是这里解释一下浏览器工程师为什么不愿意实现这种东西的逻辑。基本的关键因素就是“采纳这个提案对浏览器市占率造成的影响”，同样原理也适用于很多其他类似的标准问题上。


问题一：与 CSS 压缩工具不兼容

根据调查，YUI Compressor 与 Drupal 的默认 CSS 压缩器不支援单行注解，然而由于这些工具都会将换行符拿掉，可能造成上述 2. 的情况的发生，而造成实现单行注解的新浏览器反而漏掉了一些宣告（如 2. 的 color: black;），使得页面不正常显示。整个过程可能是这样的情形：


1.某 O 浏览器实现了单行注解。
2.某前端 F1 用了单行注解，可能考虑到了向后兼容，仅在 1. 的情况中使用。
3.某前端 F2 在没注意到 F1 用了单行注解的情况下，换了一个不支援单行注解 CSS 压缩工具。// 单行注解的使用从 1. 的情况变成了 2.。 
4.在 O 浏览器下，因为漏掉了跟单行注解同一行的宣告，造成页面显示不正常。
5.用户抛弃显示不正常的浏览器 O。

又，实现这个语法不同于实现一个新的 CSS 属性 ― 页面显示并不会升级，也就是说，冒险实现这个语法的浏览器将处在一个不利的地位。对抗这个问题的作法就是早早让这些工具支持单行注解。我在 W3C HTML5 中文兴趣小组的 wiki 中开了一个页面搜集各工具对单行注解的支援情形，欢迎大家给各开源项目贡献代码，也欢迎在 wiki 里贡献资料。

有一种说法是：使用正则的 CSS 压缩工具不容易支持单行注解，因为会把 url(http://www.example.com) 里的双斜线当作双斜线单行注解处理。不过不特别处理没引号的 url() 的 CSS 压缩工具恐怕早就无法处理 url() 里有 /* 的情形了（虽然出现这种状况的机率非常小）。以下是浏览器如何处理这种情况的演示：

span {
background-image: url(path/*file);
*/
}

span {
background-image: url("http://dev.oupeng.com/articles/path/*file");
}

问题二：与老旧网站不兼容

在现有的网站中，有可能有不靠谱的新手前端留下来的上述 3. 的情形，而这些网站可能刚好在 margin-left: auto; 不出现的时候显示正常。也就是说，支持双斜线单行注解的浏览器让 margin-left: auto; 出现反而会让这些网页坏掉。是个悲剧。

这种网站是否真的存在？有多少？在标准界尚不明确。有兴趣的人可以参考 wiki 上的指示做一下兼容研究，特别是希望搜寻引擎公司提供这些数据给标准组织。如果在哪发现了这种网页，也可以通知网页负责人一下，尽快解决这种悲剧。


总结

现在并不能说双斜线单行注解已经毫无希望，但是要采纳这类的提案还是有几项工作可以进行。Jens O. Meiert 有跟我说他会在谷歌内部看看能不能进行一些兼容研究，但目前尚未有下文。由于这并不是一个特别令人兴奋的新功能，浏览器工程师又相当缺乏，如果各位网页工程师对这个议题有兴趣，可以考虑透过上面的方法贡献一下。