CSS Houdini：用浏览器引擎实现高级CSS效果(css代码怎么在浏览器运行)

推荐整理分享CSS Houdini：用浏览器引擎实现高级CSS效果(css代码怎么在浏览器运行)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:浏览器对css的解析顺序,浏览器加载css原理,css mini,浏览器对css的解析顺序,css浏览器,浏览器加载css原理,css代码怎么在浏览器运行,css代码怎么在浏览器运行,内容如对您有帮助，希望把文章链接给更多的朋友！

vivo 互联网前端团队-Wei Xing

Houdini被称之为Magic of styling and layout on the web，看起来十分神秘，但实际上，Houdini并非什么神秘组织或者神奇魔法，它是一系列与CSS引擎相关的浏览器API的总称。

在了解之前，先来看一些Houdini能实现的效果吧：

反向的圆角效果（Border-radius)：

动态的球形背景（Backgrond）：

彩色边框（Border）：

神奇吧，要实现这些效果使用常规的CSS可没那么容易，但对CSS Houdini来说，却很easy，这些效果只是冰山一角，CSS Houdini能做的有更多。（这些案例均来自Google Chrome Labs，更多案例可以通过Houdini Samples查看）。

看完效果，再来说说Houdini到底是什么。

首先，Houdini的出现最直接的目的是为了解决浏览器对新的CSS特性支持较差以及Cross-Browser的问题。我们知道有很多新的CSS特性虽然很棒，但它们由于不被主流浏览器广泛支持而很少有人去使用。

随着CSS规范在不断地更新迭代，越来越多有益的特性被纳入进来，但是一个新的CSS特性从被提出到成为一个稳定的CSS特性，需要经过漫长地等待，直到被大部分浏览器支持时，才能被开发者广泛地使用。

而Houdini的出现正是洞察和解决了这一痛点，它将一系列CSS引擎API开放出来，让开发者可以通过JavasScript创造或者扩展现有的CSS特性，甚至创造自己的CSS渲染规则，给开发者更高的CSS开发自由度，实现更多复杂的效果。

有人会问，实际上很多新的CSS特性在被浏览器支持之前，也有可替代的JavaScript Polyfill可以使用，为什么我们仍然需要Houdini呢？这些Polyfill不是同样可以解决我们的问题吗？

要回答这个问题也很简单，JavaScript Polyfill相对于Houdini有三个明显的缺陷：

1.不一定能实现或实现困难。

CSSOM开放给JavaScript的API很少，这意味着开发者能做的很有限，只能简单地操纵DOM并对样式做动态计算和调整，光是去实现一些复杂的CSS新特性的Polyfill就已经很难了，对于更深层次的Layout、Paint、Composite等渲染规则更是无能为力。所以当一个新的CSS特性被推出时，通过JavaScript Polyfill不一定能够完整地实现它。

2.实现效果差或有使用限制。

JavaScript Polyfill是通过JavaScript来模拟CSS特性的，而不是直接通过CSS引擎进行渲染，通常它们都会有一定的限制和缺陷。例如，大家熟知的css-scroll-snap-polyfill就是针对新的CSS特性Scroll Snap产生的Polyfill，但它在使用时就存在使用限制或者原生CSS表现不一致的问题。

3.性能较差。

JavaScript Polyfill可能造成一定程度的性能损耗。JavaScript Polyfill的执行时机是在DOM和CSSOM都构建完成并且完成渲染后，通常JavaScript Polyfill是通过给DOM元素设置内联样式来模拟CSS特性，这会导致页面的重新渲染或回流。尤其是当这些Polyfill和滚动事件绑定时，会造成更加明显的性能损耗。

Houdini的诞生让CSS新特性不再依赖于浏览器，开发者通过直接操作CSS引擎，具有更高的自由度和性能优势，并且它的浏览器支持度在不断提升，越来越多的API被支持，未来Houdini必然会加速走进web开发者的世界，所以现在对它做一些了解也是必要的。

在本文，我们会介绍Houdini的APIs以及它们的使用方法，看看这些API当前的支持情况，并给出一些在生产环境中使用它们的建议。

Houdini的名称与一位著名美国逃脱魔术师Harry Houdini的名称一样，也许正是取逃脱之意，让CSS新特性逃离浏览器的掌控。

上文提到CSS Houdini提供了很多CSS引擎相关的API，根据Houdini提供的规范说明文件，API共分为两种类型：high-level APIs和low-level APIs。

high-level APIs：顾名思义是高层次的API，这些API与浏览器的渲染流程相关。

提供了一组与绘制（Paint）过程相关的API，我们可以通过它自定义的渲染规则，例如调整颜色（color）、边框（border）、背景（background）、形状等绘制规则。

提供了一组与合成（composite）渲染相关的API，我们可以通过它调整绘制层级和自定义动画。

提供了一组与布局（Layout）过程相关的API，我们可以通过它自定义的布局规则，类似于实现诸如flex、grid等布局，自定义元素或子元素的对齐（alignment）、位置（position）等布局规则。

low-level APIs：低层次的API，这些API是high-level APIs的实现基础。

这些APIs的支持情况在不断更新中，可以看到当前最新的一次更新时间是在2021年5月份，还是比较活跃的。（注：图片来源于Is Houdini ready yet?）

对比下图2018年底的情况，Houdini目前得到了更广泛的支持，我们也期待图里更多绿色的板块被逐渐点亮。

大家可以访问Is Houdini ready yet?看到Houdini的最新支持情况。

下文中，我们会着重介绍Typed Object Model API、CSS Properties & Values API、Worklets和Paint API、Animation API，因为它们目前具有比其他API更好的支持度，且它们的特性已经趋于稳定，在未来不会有很大的变更，大家也能在了解它们之后直接将它们使用在项目中。

在Houdini出现以前，我们通过JavaScript操作CSS Style的方式很简单，先看看一段大家熟悉的代码。

我们可以看到CSS样式在被访问时被解析为字符串返回，设置CSS样式时也必须以字符串的形式传入。开发者需要手动拼接数值、单位、格式等信息，这种方式非常原始和落后，很多开发者为了节省性能损耗，会选择将一长串的CSS Style字符串传入cssText，可读性很差，而且很容易产生隐蔽的语法错误。

Typed Object Model与TypeScript的命名类似，都增加了Type这个前缀，如果你使用过TypeScript就会了解到，TypeScript增强了类型检查，让代码更稳定也更易维护，Typed Object Model也是如此。

相比于上面晦涩的传统方法，Typed Object Model将CSS属性值包装为Typed JavaScript Object，让每个属性值都有自己的类型，简化了CSS属性的操作，并且带来了性能上的提升。通过JavaScript对象来描述CSS值比字符串具有更好的可读性和可维护性，通常也更快，因为可以直接操作值，然后廉价地将其转换回底层值，而无需构建和解析 CSS 字符串。

在Typed Object Model中CSSStyleValue是所有CSS属性值的基类，在它之下的子类用于描述各种CSS属性值，例如：

通过它们的命名就可以看出这些不同的子类分别用于表示哪种类型的CSS属性值，以CSSUnitValue为例，它可以用于表示带有单位的CSS属性值，例如font-size、width、height，它的结构很简单，由value和unit组成。

可以看到，通过对象来描述CSS属性值确实比传统的字符串更易读了。

要访问和操作CSSStyleValue还需要借助两个工具，分别是attributeStyleMap和computedStyleMap()，前者用于处理内联样式，可以进行读写操作，后者用于处理非内联样式（stylesheet），只有读操作。

当然attributeStyleMap和computedStyleMap()还有更多可用的方法，例如clear、has、delete、append等，这些方法都为开发者提供了更便捷和清晰的CSS操作方式。

根据MDN的定义，CSS Properties & Values API也是Houdini开放的一部分API，它的作用是让开发者显式地