浅析CSS在DevTools 中架构演变
这片文章描述了devtools 架构在css层面所做的更改。
本文主要解释 css 在历史上如何在 devtools 中工作，以及如何在 devtools 中现代化我们的 css，以准备（最终）迁移到用于在 javascript 文件中加载 css 的 web 标准解决方案。
devtools 中 css 的先前状态
devtools 以两种不同的方式实现 css：
- 一种用于devtools遗留部分中使用的 css 文件
- 另一种用于 devtools 中使用的现代 web 组件。
对于第一种遗留部分的来说，我们翻开chromium源码，可以大致猜想它的实现：
chromium源码
devtools 中的 css 实现是多年前定义的，现在已经过时了。devtools 一直坚持使用该 module.json 模式，
那么我们来看下这个文件具体形式是如何的：
module.json
这些css文件会被放在同一个目录下，为了将添加到 devtools，您需要 registerrequiredcss 使用要加载的文件的确切路径进行调用。
那么它的调用如下：
constructor() {
…
this.registerrequiredcss('ui/legacy/components/quick_open/filteredlistwidget.css');
…
}
通过检索css文件的内容后，通过 appendstyle 函数将内容插入到 <style> 标签中，
const content = root.runtime.cachedresources.get(cssfile) || '';
if (!content) {
console.error(cssfile + ' not preloaded. check module.json');
}
const styleelement = document.createelement('style');
styleelement.textcontent = content;
node.appendchild(styleelement);
但是，假设我们引入现代 web 组件（使用自定义元素）时，我们最初决定在组件文件中通过内联 style> 使用css。这带来了自己的挑战：
- 缺少语法高亮支持：为内联css提供语法高亮的插件往往不如为写在.css文件中的css提供的语法高亮和自动完成功能好。
- 建立性能开销：内联css也意味着需要进行两次检查：一次针对css文件，一次针对内联css。如果所有的css都写在独立的css文件中，我们就可以消除这种性能开销。
- 减化体积的挑战。内联 css 不容易缩小，因此没有任何 css 被缩小。devtools 发布版本的文件大小也因同一 web 组件的多个实例引入的重复 css 而增加。
基于以上的问题，那有哪些可以解决的方案呢？
研究潜在的解决方案
问题可以分为两个不同的部分：
- 弄清楚构建系统如何处理 css 文件。
- 弄清楚 devtools 如何导入和使用 css 文件。
接下来我们看下，他们是如何为每个部分研究了不同的潜在解决方案，下面概述了这些解决方案。
导入 css 文件
在typescript文件中导入和利用css的目的是为了尽可能地贴近标准，在整个devtools中执行一致性，并避免在我们的html中重复css。我们还希望能够选择一个解决方案，使我们的变化能够迁移到新的网络平台标准，如css模块脚本。
由于这些原因，@import语句和标签似乎并不适合devtools。它们与devtools其他部分的导入不一致，会导致flash of unstyled content（fouc）的出现。迁移到css模块脚本会更难，因为导入必须明确地添加，并且与标签的处理方式不同。
const output = lithtml.html` <style> @import "css/styles.css"; </style> <button> hello world </button>`
const output = lithtml.html` <link rel="stylesheet" href="styles.css"> <button> hello world </button>`
总结的话，潜在的解决方案是使用 @import 或 <link> 。
相反，我们选择找到一种方法，将css文件作为cssstylesheet对象导入，这样我们就可以使用其adoptedstylesheets属性将其添加到shadow dom（devtools使用shadow dom已经有几年了）。
至于shadow dom 不清楚的，可以参考：https://developers.google.com/web/fundamentals/web-components/shadowdom
使用 css 的新基础架构
我们需要一种将 css 文件转换为 cssstylesheet 对象的方法，以便我们可以轻松地在 typescript 文件中对其进行操作。最后选择放弃rollup和webpack做转化，可能考虑的原因在于，构建过程中，将任何一个bundler 添加到生产构建中都可能存在潜在的性能问题。
我们与chromium的gn构建系统的整合使得捆绑更加困难，因此捆绑器往往不能很好地与当前的chromium构建系统整合。
相反，我们探索了使用当前 gn 构建系统为我们进行这种转换的选项。
新的解决方案涉及到使用adoptedstylesheets向特定的shadow dom添加样式，同时使用gn构建系统来生成可被文档或shadowroot采用的cssstylesheet对象。
// custombutton.ts
// import the css style sheet contents from a js file generated from css
import custombuttonstyles from './custombutton.css.js';
import otherstyles from './otherstyles.css.js';
export class custombutton extends htmlelement{
…
connectedcallback(): void {
// add the styles to the shadow root scope
this.shadow.adoptedstylesheets = [custombuttonstyles, otherstyles];
}
}
使用adoptedstylesheets有多种好处，包括：
- 它正在成为一个现代的标准。
- 防止重复的css。
- 只对shadow dom应用样式，这就避免了css文件中重复的类名或id选择器引起的问题。
- 易于迁移到未来的网络标准，如css模块脚本和导入断言。
该解决方案的唯一注意事项是，导入语句需要导入.css.js文件。为了让gn在构建过程中生成一个css文件，我们编写了generate_css_js_files.js脚本。构建系统现在处理每一个css文件，并将其转换为一个javascript文件，该文件默认导出一个cssstylesheet对象。因为我们可以导入css文件并轻松地采用它。此外，我们现在还可以轻松地对生产构建进行最小化，节省文件大小。
iconbutton.css.js 生成的例子：
const styles = new cssstylesheet();
styles.replacesync(
// in production, we also minify our css styles
/`${isdebug ? output : cleancss.minify(output).styles}
/*# sourceurl=${filename} */`/
);
export default styles;
后续计划
到目前为止，chromium devtools 中的所有 web 组件都已迁移到使用新的 css 基础架构，而不是使用内联样式。大多数遗留用法 registerrequiredcss 也已迁移到使用新系统。剩下的就是删除尽可能多的 module.json 文件，然后迁移当前的基础架构以在未来实现 css 模块脚本！
参考
[1]https://developer.chrome.com/blog/modernising-css-infra-in-devtools/
[3] https://developer.chrome.com/blog/migrating-to-web-components
到此这篇关于浅析css在devtools 中架构演变的文章就介绍到这了,更多相关css devtools架构内容请搜索以前的文章或继续浏览下面的相关文章，希望大家以后多多支持！