通过阅读规范学习 CSS
最近，我有机会采访了Vitaly Friedman，这次采访是为今年九月即将举行的View Source 大会做准备。我们聊到的内容之一就是关于新的 CSS。
我的好朋友魏是一位非常优秀的科技作家，她积极参与开源项目的文档编写工作。她撰写了大部分React-Redux文档，并且是Docusaurus的核心维护者之一。
一位亲密的朋友如此热衷于文档编写，这让我对软件开发的这一方面有了更多思考，我个人认为这一方面被严重低估了。
注：写完之后我才意识到这篇文章比我预想的要长，所以简单来说就是：不要害怕阅读 CSS 规范。它们对理解 CSS 非常有帮助。
另外，你，没错，就是你，也可以为 CSS 的发展做出贡献。
警告，故事时间到……
我曾在各种不同的组织工作过，从代理机构到初创公司再到大型企业，也曾参与过对文档处理有着截然不同态度的团队。
我最难忘的经历是在一家初创公司，该公司专注于将机器学习技术应用于来自拥有海量数据但缺乏专业知识来处理这些数据的组织的大型数据集。
新加坡团队一直在开发一个机器学习平台，但由于新加坡办事处关闭，该项目未能完成。
但是，那一年与经验丰富、技术精湛的高级工程师们共事，他们每个人都是各自领域的专家，这段经历让我学到的软件工程知识比我之前所有工作经验加起来还要多。
它们之间的一个共同点是都强调清晰全面的文档记录。
CSS规范也算是文档吧。
Codrops有一个非常棒的CSS 参考资料库，主要由才华横溢的Sara Soueidan撰写。在 Sara 转而从事其他项目后，我协助她完成了一些后续条目。我对 CSS Grid 如此熟悉，是因为我撰写了相关的条目。
我写的每一篇文章都让我有理由仔细研读相关的 CSS 规范，此外，我还研究了所有涵盖相同内容但表达方式不同的教程和博客文章。
但规范始终是我唯一的权威来源，它让我能够清晰地辨别文章或博客文章中的信息是否完全准确。现在，我写的每一篇关于 CSS 的博客文章都会参考规范，而且我常常能从中发现一些以前不知道的东西。
Vitaly 在我们的采访中提到的一件事是，有些人觉得规范令人生畏，因为它看起来像是一份非常专业的文档，里面有很多难以理解的段落。
对我来说，这说法有一定道理，尤其是在CSS3之前编写的规范，当时为了便于开发和维护，决定将规范拆分成不同的模块。我也曾有过这样的经历：反复阅读同一段文字，却仍然一头雾水。
我还有一个优势，那就是英语流利，因此我处于一个有利的位置，能够比那些英语不是母语的人更快、更容易地理解规范中的信息。
话虽如此，当 Vitaly 问我，如果当初开始从事网页开发工作，我希望自己知道的一件事是什么时，我的回答是，我希望从一开始就知道要阅读 CSS 规范。
CSS工作组投入了大量时间和精力，力求尽可能全面地定义 CSS 的行为方式。
引用Elika Etemad（又名 fantasai）的话：
你不需要是程序员或计算机科学专业的学生才能理解CSS规范。你不需要年满18岁或拥有学士学位。你只需要非常严谨、非常坚持不懈、非常细致。
开始制定规范
幸运的是，已经有很多文章和资源专门用于帮助人们轻松阅读 W3C 规范。如果您从未访问过W3C 的 CSS 主页，我建议您从那里开始。
它会不断更新 CSS 工作组的最新动态、已正式更新的规范，以及相关活动和会议的新闻。
了解 CSS 的历史也很有益处，因为它能帮助我们了解 CSS 在过去二十年中的发展历程，以及为什么某些东西会发展成今天的样子。
2016 年 12 月 17 日是 CSS 诞生 20 周年，W3C 发布了一个纪念网站“ CSS 二十周年”，以庆祝这一里程碑。
CSS 工作组已完成的所有规范和草案的完整列表，是了解所有最新进展的最佳途径。至于如何实际阅读规范，J. David Eisenberg撰写的《如何阅读 W3C 规范》可能是最佳入门读物。
Elika 的《理解 CSS 规范》一书提供了一个很好的路线图，指明了应该首先学习哪些规范，并且还重点介绍了一些我们有兴趣参与的项目。
为CSS的开发做出贡献
在我的网页开发生涯中，最幸运的事情之一就是结识了从事浏览器、规范和网络平台相关工作的人。
仅仅通过与他们的闲聊，我就获得了许多宝贵的见解，这些见解塑造了我对这个我选择投身其中的行业的看法。
我第一次见到Rachel Andrew是在她来新加坡参加2016 年 CSSConf.Asia大会的时候，她欣然同意参加Talk.CSS 周年特别节目的小组讨论。
我认为她是一位真正的 CSS 倡导者，她一直鼓励像你我这样的 Web 开发人员向规范编写者和浏览器供应商提供反馈，并帮助为 Web 平台的发展做出贡献。
对我而言，CSS 过去是、现在是、将来也永远是我最喜欢的开源项目。
撰写/讨论 CSS
尝试 CSS 功能，尤其是较新的功能，然后写下或说说它的工作原理、它如何解决特定用例或不能解决特定用例，这不仅对可能遇到类似情况的其他开发人员非常有帮助，而且对规范作者和浏览器供应商也很有帮助。
如果我们仅仅因为某些新功能尚未得到广泛支持就避而远之，就会陷入恶性循环，最终导致这些功能更难获得浏览器的广泛支持。浏览器厂商在决定CSS功能的优先级时，确实会关注相关的讨论热度。
我有时会想，开发者们是不是忘了浏览器也是软件项目，是由像你我一样的工程师开发和维护的。任何软件项目都一样，功能和bug都需要优先级排序，因为即使像谷歌和微软这样的大公司规模庞大，负责浏览器开发的团队规模也并不大。
当 CSS 网格在 2017 年首次推出时，它引起了很大的轰动，而Patrick Kettner的一条推文促使我写了一篇关于我们行业中的善意（以及有时缺乏善意）的简短笔记。
我的意思是，请尽可能多地尝试新功能。你不必在生产环境中使用它们，只需做一些小项目或者在 CodePen 上演示一下，看看它们是如何运作的，就足够了。如果你有时间，写个简短的文档，即使是要点式的也可以。浏览器厂商都在关注着你的反馈。
在 CSS 工作草案仓库中提出问题
CSS规范并非由一群身穿黑袍的神秘人在幽暗的地下洞穴中围着冒泡的大锅吟唱而制定。它们是在公开透明的环境下完成的。任何人都可以通过邮件列表www-style@w3.org参与讨论，您可以在这里订阅。
如果你不喜欢邮件列表，那么在GitHub上提交 issue也是个不错的选择。所有 CSS 的工作草案都在 GitHub 上编写和开发，所以跟踪它的进展，看看规范是如何在整个开发过程中演变的，真的很有意思。
诚然，很多讨论都是在规范制定者、浏览器厂商和各自领域（可访问性、国际化、排版等）的专家之间进行的，但也有像你我这样的开发者询问具体的用例并要求澄清。
理想情况下，你应该清晰具体地描述你的使用场景，并尽可能提供一个能够最好地说明问题的简化测试用例。大多数情况下，会有人能够帮助你，或者可以推荐一些能够提供帮助的人。
对我来说，仅仅是阅读我感兴趣的问题就足够令人着迷了，因为它们通常围绕着我从未想过的用例展开，从中我更加体会到在规范制定过程中所投入的思考。
向相应的浏览器厂商提交错误报告
我特别感兴趣的CSS属性之一是writing-mode`.`。公平地说，它可能最适用于我们这些使用东亚语言（例如中文或日语）的人。但这并不意味着不使用东亚语言的人就不能从中受益。
竖排文字在平面设计领域由来已久，Jen Simmons 有很多演示作品展示了如何将竖排文字运用到艺术指导式的版面设计中。不过，我有点跑题了。本节主要讨论浏览器漏洞。
由于网页上的垂直文字布局使用频率远低于其他一些 CSS 特性，因此一些 bug 并未得到彻底修复。但我当时正在对垂直布局进行大量的实验，并在 Firefox 中遇到了一个非常奇怪的 bug。
关于整个过程的详细信息，请参阅这篇博文。我已在 Firefox 的问题日志中提交了该 bug，并在下一个版本中修复了它。这简直让我难以置信。不过，我也听好几个朋友说过，当他们遇到奇怪的问题时，往往不会想到这可能是浏览器的 bug。
所以我想强调的是，有时候，当你的 CSS 出现异常行为时，要考虑到这可能是浏览器的 bug。请帮助浏览器厂商检查这是否是已知的 bug，如果没有，请提交一个 bug 报告。
以下是主要浏览器的所有问题日志列表：
此外，还有一个名为Web Compat 的志愿者主导的倡议，旨在帮助简化提交浏览器兼容性错误报告的过程。
Web平台测试项目
我是在2017年参加奥斯汀的Mozilla全员大会时了解到Web平台测试项目的，当时有人谈到了这个项目。后来，Rachel Andrew在24ways上发表了一篇文章，提供了参与该项目（编写测试）的详细步骤指南。
引用她在文章中的话：
你需要真正理解某个功能，才能准确地设计出测试方法，检验它在不同引擎中是否有效。这项工作并不光鲜亮丽，但却非常有意义。除了能提升自身能力，加深对平台的了解，从而做出贡献之外，你还能切实推动规范的完善。
这方面我还没有开始探索，但它绝对是我人生愿望清单上的项目，希望将来我能为此做出贡献。
总结
虽然时间很长，但我希望这能阐明为什么阅读 CSS 规范对于深入理解 CSS 非常有帮助，同时也能突出 Web 开发人员如何为塑造 Web 平台做出贡献。
相关阅读和链接
- W3C：层叠样式表
- 如何阅读 W3C 规范
- 了解 CSS 规范
- CSS：层级、快照、模块……
- CSS工作组编辑器草案
- web平台测试文档
- web平台测试仪表板
- Web平台规范的测试套件
- 送给未来自己的圣诞礼物：测试网络平台
- 精益求精：重新定义 CSS 的技术可能性