想要使用某种 CSS 特性，但是因为浏览器兼容性问题而没法使用？更糟糕一点，所有浏览器都支持这种特性，但支持度不完全，在某些情况下会有 bug 出现、支持性不一致，甚至于完全不兼容。如果你曾经遇到过上述情况（我肯定你一定遇到过），那你得好好关注 Houdini 。
Houdini 是 W3C 新成立的一个任务小组，它的终极目标是实现 css 属性的完全兼容。Houdini 提出了一个前无古人的的设想：开放 CSS 的 API 给开发者，开发者可以通过这套接口自行扩展 CSS，并提供相应的工具 允许开发者介入浏览器渲染引擎的样式和布局流程中 。
但是……这意味着什么呢？这个方案靠谱吗？不管是现在还是将来，Houdini 对开发者进行万展开发有什么帮助呢？
我将在后面的文章里尽可能地回答上面这三个问题。但在开始回答之前，要先搞清楚我们现在面临的问题是什么，以及为什么出现 Houdini 这样的解决方案。弄明白问题是什么之后，我再告诉大家 Houdini 将会如何解决这些问题，以及它目前的进展。最后，开发者们，你们还能了解具体如何做才能让 Houdini 尽早落地。
写文章也罢做 demo 也罢，每一次当我想要炫耀点 CSS 新花样的时候，总有人会说“这效果真是屌炸天！然而我们现在并不能好好用它，至少等个 10 年吧”。
虽然每每我都觉得这样的评论让人生气又没啥建设性，但依然承认大家的担心有理有据。纵观 CSS 历史，每一份特性草案都是经过了许多年才被广泛应用。而之所以会是“许多年”，就是因为要允许一个新特性被写入 CSS 标准需要经过一整套标准制定流程，然而就过了很多年……
我对于这个标准制定的流程肯定是毫无异议的，但你得承认，走完整个流程花儿都谢了。
flexbox 大概就是最好的例子，2009年，关于 flexbox 的草案第一次被提出，但直到今天开发者们还在抱怨着这个属性的浏览器兼容性问题。不过感谢上帝，随着现代浏览器的自动更新机制，这个问题总有解决的那一天。但是，按照现在的新属性发布流程，最新的浏览器也会和新属性提案仍然存在一个时间差。
不过同样在 web 世界里，对于如今的 JavaScript 来说好像不是什么事儿了：
在上面的流程图中，我们可以看到从想到一个新的 js 特性到运用在生产环境，大概只需要几天时间。讲真，我已经在使用 async 和 await 了，然而目前没有浏览器天生支持这两个方法吧。
估计现在你也大概感受到了 CSS 社区和 JS 社区的画风不同了：在 JS 社区里，你总能听到人们在抱怨它一天一个样 －－ 跑得太快追得太累；而 CSS 社区，人们却在叹息着花精力去学习新事物是件多么吃力不讨好的事儿 －－ 天知道什么时候才能用上新玩意呢。
脑海里闪过的第一个解决方案就是 CSS polyfill，只要 CSS polyfill 足够强大，相信 CSS 的发展速度赶超 JavaScript 不是梦。
然而，给 CSS 打补丁做起来有多难你都想不到，而且在大部分情况下，只要这么做了，性能肯定会受到影响。
JavaScript 是一种动态语言，它是如此之“动态”以至于有着让人惊叹的可扩展性，所以用 JavaScript 给 JavaScript 打补丁是可以轻松实现的，但 CSS 不是动态的呀。在某些情况下，你可以在构建过程中将一种形式的 CSS 转译成另一种形式（ PostCSS 就是一个典型的例子）。而一旦你的补丁是依赖于的 DOM 结构、某一个元素的布局或者它的定位的话，那补丁程序就需要在本地运行了。
不幸的是，要在浏览器中实现这种方案挺难的。
让我们来看看一个 HTML 文档从被浏览器接收到显示在屏幕上的全过程，下面这张图里被标为蓝色的部分就是 JavaScript 可以染指的环节了：
作为开发者，看着这张图心都凉了，我们根本控制不了浏览器解析 HTML 和 CSS 的过程，只能看着它生成 DOM 和 CSS object model (CSSOM)。没法控制级联（cascade）、没法控制浏览器布局元素的方式（layout）、也没法控制元素在屏幕上显示的过程（paint）、最后的合成（composite）也为力。
整个过程中，开发者能完全控制的唯一环节就是 DOM，另外 CSSOM 也可以部分控制到。即使如此，引用 Houdini 官网上的话来说，这种程度的暴露是“不确定的、兼容性不稳定的以及缺乏对关键特性的支持的”。
举个例子，浏览器中的 CSSOM 是不会告诉你它是如何处理跨源的样式表的，而且对于浏览器无法解析的 CSS 语句它的处理方式就是不解析了，也就是说——如果你要用 CSS polyfill 让浏览器去支持它尚且不支持的属性，那就不能在 CSSOM 这个环节做，只能自行解析一遍 DOM 树，找到
