三个公式 — CSS 到底是什么

Three formulas — what CSS really is

把整个 CSS 引擎压缩到三行

The whole engine in three lines

每一篇沉浸式都从三个公式开始。CSS 也不例外。下面三行写完之后,后面 30 章只是把每个箭头展开。

Every immersive starts with three formulas. CSS is no exception. The next 30 chapters are just each arrow, unpacked.

// FORMULA ① — what a stylesheet IS
Stylesheet  =  ordered list of (Selector, Declaration+) rules
            +  an outer at-rule envelope (@media, @layer, @container, ...)

// FORMULA ② — what cascade DOES
ComputedStyle(element)  =  cascade(
                              for each property P:
                                argmaxspecificity, order, importance
                                  ( declarations of P matching element )
                            )  +  inheritance  +  initial defaults

// FORMULA ③ — what the engine OPTIMIZES
StyleRecalc(node)       =  ∩r ∈ rules  (r touches node) → O(matched · log dom)
                           guarded by InvalidationSet  ← Ch20 makes this O(dirty)

① 一个 stylesheet 就是有序的"选择器 + 声明列表"对。顺序很重要——这是 cascade 决定胜负的依据之一。
② ComputedStyle 是对每个 CSS 属性独立跑一遍 argmax: 在所有匹配这个元素的声明里,按 specificity → 顺序 → !important 的优先级挑一个最高的;然后从父节点继承没显式声明的属性;最后补 initial value。
③ DOM 改了一点东西(class 变了、子节点加了),引擎要回答"谁要重算"。朴素答案是每个元素都跑一遍 cascade(O(N × rules))。Blink 用 InvalidationSet 把它压到只跑真正脏的节点——这是 Ch20 的主题。

① A stylesheet is an ordered list of "selector + declarations" pairs. Order matters — it's one of cascade's tie-breakers.
② ComputedStyle runs an argmax per CSS property: from all declarations that match this element, pick the highest one by specificity → order → !important; then inherit unset properties from the parent; finally fill in initial values.
③ The DOM changes — a class flips, a node is inserted. The engine must answer "who needs a recalc". The naive answer is every element re-runs cascade (O(N × rules)). Blink shrinks this to only truly dirty nodes using InvalidationSet — the subject of Ch20.

CSS 不是"样式表" — 是四种东西合一

CSS isn't a "stylesheet" — it's four things in one

读完本文你会发现"CSS"这个词其实指代四件本质不同的事:

By the end you'll see "CSS" actually denotes four distinct things:

家谱 — CSS 的 30 年

A family tree — 30 years of CSS

1996 CSS1 · 2026 nesting · 中间踩过的坑

1996 CSS1 · 2026 nesting · the dead-ends in between

CSS 是Web 上最古老但最活跃的标准之一。1996 年 Håkon Wium Lie 在 W3C 发布 CSS1,初版只有 50 个属性。今天 Chromium 实现的 CSS 属性 / at-rule / 函数加起来已经超过 650 个。下面这张图把 1996-2026 的关键节点拉直,把已死的提案也画进去——你会看到 CSS 跟任何活语言一样,踩过很多坑。

CSS is one of the oldest Web standards still actively evolving. Håkon Wium Lie shipped CSS1 in 1996 with 50 properties. Today Chromium implements over 650 CSS properties + at-rules + functions. The figure below maps 1996-2026's key landmarks — including the dead branches. Like any living language, CSS has stepped on plenty of rakes.

六代 CSS · 设计哲学的转向

Six generations · the philosophical pivots

在渲染管线里的位置 — CSS 不是孤岛

Position in the pipeline — CSS isn't an island

从 HTML parser 到 Compositor · CSS 占哪几段

from HTML parser to Compositor · CSS owns which segments

CSS 引擎不是独立服务——它嵌在 Chromium 的整套渲染管线里。下面这张图把姊妹篇《字节码到像素》的 13 段流水线拉出来,标出 CSS 占的哪几格。读完之后你会知道:CSS 不只是 "Style" 那一段,它的触手伸到 Layout、Paint、Compositor。

The CSS engine isn't a standalone service — it's embedded in Chromium's full rendering pipeline. The figure below pulls in the 13-stage pipeline from its sibling, "Bytecode to Pixels", and highlights which boxes are CSS. By the end you'll see: CSS isn't only the "Style" box — its tentacles reach into Layout, Paint, Compositor too.

三层模型 — author / user / UA

Three layers — author / user / UA

cascade 输入的三个来源 · 谁优先于谁

three sources feeding cascade · who beats whom

浏览器拿到的 CSS 不只一份。当 Blink 给一个 DOM 节点算 ComputedStyle 时,同时 在看三套样式表:

The browser never sees just one stylesheet. When Blink computes ComputedStyle for a DOM node, it's looking at three sets of rules at once:

UA 样式 — 你以为是浏览器"自然"的那些

UA stylesheet — the "natural" browser behaviour

在 Chromium 里,没有"自然"这种事——一切看起来"天生如此"的样式都写在某个文件里。比如:

In Chromium, there's no "natural" — anything that looks "just how things are" is written in a file. For example:

// third_party/blink/renderer/core/html/resources/html.css · 真实片段
// 你以为 h1 字大 / 加粗 / 自动加 margin 是"浏览器默认行为"
// 不,它就是下面这几行 CSS

h1 {
  display: block;
  font-size: 2em;
  margin-block: 0.67em;
  font-weight: bold;
  unicode-bidi: isolate;
}

// <button> 看起来是"原生按钮",其实也只是 ~15 行 CSS:
button {
  appearance: auto;     // ← 这一句把绘制委托给 host OS theme
  padding: 1px 6px;
  background-color: buttonface;  // system color keyword · Ch28
  color: buttontext;
  cursor: default;
  box-sizing: border-box;
  ...
}

User 样式 — 你可能从来没用过的那一层

User stylesheet — the layer you've probably never used

User 层在现代浏览器里几乎被遗忘——但它仍然存在,而且在级联里夹在 UA 和 Author 之间。你能怎么写 user 样式?三个途径:

The user layer is almost forgotten in modern browsers — but it's still there, sandwiched between UA and Author in the cascade. Three ways to write user CSS:

Author 样式 — 99% 的真实场景

Author stylesheet — the 99% case

本文 99% 的内容都是关于 Author 样式怎么工作。所以这一章不再细讲它——你写的每一句 CSS,从 Ch6 起会被全部展开。这里只列出 author 样式的四个入口:

99% of this article is about how Author styles work, so we don't dwell here — every CSS line you write gets unpacked from Ch6 onward. Just listing the four entry points:

html.css 真实内容 · 前 80 行

html.css real content · first 80 lines

// third_party/blink/renderer/core/html/resources/html.css · Chromium 130 verbatim opener

@namespace "http://www.w3.org/1999/xhtml";

/* Document defaults */
html {
  display: block;
  -webkit-text-size-adjust: auto;
  -webkit-touch-callout: default;
}

/* The body always has a background — even when transparent. */
body {
  display: block;
  margin: 8px;
}

/* Headings */
h1 {
  display: block;
  font-size: 2em;
  margin-block: 0.67em;
  font-weight: bold;
  unicode-bidi: isolate;
}
:is(article, aside, nav, section) h1 {
  font-size: 1.5em;          /* h1 inside sectioning content gets smaller — html5 spec */
  margin-block: 0.83em;
}

/* The famous default-margin chain */
h2 { display: block; font-size: 1.5em;  margin-block: 0.83em; font-weight: bold; }
h3 { display: block; font-size: 1.17em; margin-block: 1em;    font-weight: bold; }
h4 { display: block;                  margin-block: 1.33em; font-weight: bold; }
h5 { display: block; font-size: 0.83em; margin-block: 1.67em; font-weight: bold; }
h6 { display: block; font-size: 0.67em; margin-block: 2.33em; font-weight: bold; }

/* The infamous <p> default margin */
p {
  display: block;
  margin-block: 1em;       /* THIS is what reset CSS targets first */
}

/* Block containers — many use display: block + margin defaults */
address, article, aside, div, footer, header, hgroup, layer, main, nav, section {
  display: block;
}

/* Tables — the LARGEST single block of UA CSS (~300 lines) */
table {
  display: table;
  border-collapse: separate;
  border-spacing: 2px;
  border-color: gray;          /* the only place "gray" still appears as default */
  box-sizing: border-box;
}

/* Buttons — appearance: auto delegates rendering to host OS theme */
button {
  appearance: auto;
  padding: 1px 6px;
  background-color: ButtonFace;     /* system color keyword · CSS Color 4 */
  color: ButtonText;
  cursor: default;
  box-sizing: border-box;
}

/* Form controls — delegated to OS via appearance: auto */
input, select, textarea {
  appearance: auto;
  font: -webkit-small-control;
  color: FieldText;
  background-color: Field;
  letter-spacing: normal;
  word-spacing: normal;
  text-transform: none;
}

The Card — 一段贯穿全文的 CSS

The Card — the through-line stylesheet

4 行 CSS · 1 次鼠标悬停 · 9 道工序

4 lines · 1 hover · 9 stages

/* card.css · the specimen we'll follow for the next 17 chapters */

:root {
  --brand: oklch(70% 0.15 250);
}

@layer base {
  .card {
    padding: 0.5rem;
    background: var(--brand);
  }
}

.card:hover {
  background: color-mix(in oklch, var(--brand), white 20%);
  transition: 200ms;
}

@container (min-width: 400px) {
  .card { padding: 1rem; }
}

为什么是这 4 行

Why these 4 lines

看起来平平无奇——其实没有比这更密的 4 行。它同时激活 7 个现代特性,每个特性对应文章的一个 Act:

Looks unassuming. In fact no four lines pack more. It simultaneously activates 7 modern features — one per Act of the article:

几乎覆盖了 2017 后的所有核心新特性。把这 4 行讲透,等于把 Chromium CSS 引擎讲透。

It hits nearly every major CSS feature shipped after 2017. Explain these 4 lines completely and you've explained Chromium's CSS engine completely.

The Card 的一生 · 9 道工序故事板

The Card's life · 9-stage storyboard

为了让 Ch6-25 的 STAGE 卡片有同一条时间线,把 The Card 的"从字节到像素"切成 9 个时间点。每一章 STAGE 卡上会注明它讨论的是哪一格。

To give Ch6-25's STAGE banners a single shared timeline, The Card's "from bytes to pixels" journey is sliced into 9 moments. Each chapter labels which cell it captures.

三个时间点 · The Card 的一生切成三个 ACT

Three moments — The Card's life cut into three acts

把流水线压缩成用户感知的三个时刻,你能更直观地感受成本:

Compressed into three user-perceptible moments, the cost becomes intuitive:

第一击 · ACT III 的纳秒级时间线

The first hover · ACT III at nanosecond resolution

用户鼠标移到 .card 上的那一瞬间——Chromium 在约 0.6 ms内跑完整套交互流水线(M2 MacBook · Chrome 130 中位数)。下面这张图把每一步钉到时间轴上:

The instant the cursor enters .card — Chromium runs the interactive pipeline in ~0.6 ms (median, M2 MacBook + Chrome 130). The figure pins each step to the clock:

实战 · 拿到 The Card 的全栈追踪

Practical · capturing The Card's full-stack trace

// 1. Drop card.css into a fresh page
<link rel="stylesheet" href="card.css">
<div class="container">
  <div class="card">hello</div>
</div>

// 2. Open DevTools → Performance → record
//    Hover over the .card  → stop recording

// 3. Filter Performance flame chart by these events:
await page.evaluate(() => {
  performance.getEntriesByType("resource")
    .filter(e => e.name.endsWith(".css"))
    .forEach(e => console.log(`fetch:`, e.duration));   // stage ①-②
});

// 4. Read RecalcStyle / UpdateLayoutTree timings — that's stages ④-⑦
// 5. After hover, look at InvalidateStyle event — that's stage ⑧
// 6. Animation::Update + cc::Animation::Tick events — stage ⑨ (compositor vs main)

tokenizer — 字符流变 token 流

Tokenizer — characters into tokens

CSSTokenizer.cc · 17 种 token · 状态机

CSSTokenizer.cc · 17 token types · the state machine

CSS 引擎拿到的第一刀是 tokenizer——它不理解 selector、不知道 cascade、对 @rule 一无所知。它只做一件事: 把 UTF-16 字符流切成 token 流。然后 parser(Ch7)拿这些 token 拼成 AST。

The engine's first cut is the tokenizer — it doesn't understand selectors, doesn't know cascade, knows nothing about at-rules. It does one job: split a UTF-16 character stream into a token stream. The parser (Ch7) then assembles tokens into an AST.

// third_party/blink/renderer/core/css/parser/css_parser_token.h
// CSS 的 17 种 token 类型 (Chromium 130) — 全部来自 W3C css-syntax-3

enum class CSSParserTokenType : uint8_t {
  kIdentToken,         // 普通标识符 · "card" "hover" "oklch"
  kFunctionToken,      // "var("  "oklch("  "color-mix("
  kAtKeywordToken,     // "@layer"  "@container"  "@media"
  kHashToken,          // "#main"  "#brand-color"  (id selector / hex color)
  kStringToken,        // "Helvetica, sans"  (quoted)
  kBadStringToken,     // 未闭合 string — 错误恢复模式 Ch9
  kUrlToken,           // url(./bg.png)
  kBadUrlToken,
  kDelimiterToken,     // 单字符 · ">" "+" "~" "&" "*"
  kNumberToken,        // 70  0.15  -5
  kPercentageToken,    // 70%  -50%
  kDimensionToken,     // 1rem  0.5em  200ms  90deg
  kWhitespaceToken,    // 空格 / 换行 / tab
  kCDOToken,           // "<!--"  (HTML 注释 兼容遗物)
  kCDCToken,           // "-->"
  kColonToken,         // ":"
  kSemicolonToken,     // ";"
  kCommaToken,         // ","
  kLeftBracketToken,   // "[" — attribute selector
  kRightBracketToken,  // "]"
  kLeftParenthesisToken, // "("
  kRightParenthesisToken, // ")"
  kLeftBraceToken,     // "{"
  kRightBraceToken,    // "}"
  kEOFToken,
};

The Card 的前 12 个 token

The first 12 tokens of The Card

把主线第一行 :root { --brand: oklch(70% 0.15 250); } 喂给 tokenizer,输出是这样:

Feed the main-line's first line :root { --brand: oklch(70% 0.15 250); } to the tokenizer and the output is:

tokenizer 是个状态机 · 6 个核心状态

It's a state machine · 6 core states

CSS tokenizer 在 spec 上叫"consume a token",在实现上是个 6 状态的有限状态机。每次调 NextToken(),它从当前位置开始按 css-syntax-3 §4.3 的规则跑一遍,返回一个 token。

The CSS tokenizer is called "consume a token" in the spec; in code it's a 6-state finite-state machine. Every call to NextToken() runs the css-syntax-3 §4.3 rules from the current position and returns one token.

tokenize 时不做的事

What tokenizing does not do

真实的 ConsumeQualifiedRule 主循环

Real ConsumeQualifiedRule loop

// core/css/parser/css_parser_impl.cc · simplified, the heart of CSS parsing

StyleRule* CSSParserImpl::ConsumeQualifiedRule(CSSParserTokenStream& stream,
                                              AllowedRulesType allowed) {
  // ① CONSUME THE PRELUDE (selector list, ending at "{" or ";")
  const wtf_size_t prelude_start = stream.Offset();
  while (!stream.AtEnd() &&
         stream.UncheckedPeek().GetType() != kLeftBraceToken) {
    stream.ConsumeIncludingWhitespace();   // build up selector tokens
  }

  if (stream.AtEnd()) return nullptr;   // no "{" found — invalid rule, discard

  // ② PARSE THE PRELUDE INTO A SELECTOR LIST
  CSSSelectorList* selector_list = CSSSelectorParser::ParseSelector(
      stream.RangeUntilOffset(prelude_start, stream.Offset()), context_);
  if (!selector_list->IsValid()) {
    // invalid selector — drop the WHOLE rule incl. declarations · Ch9 forgiveness
    ConsumeBlockContents(stream, /*allow_nested=*/false);
    return nullptr;
  }

  // ③ CONSUME THE BLOCK "{ declarations }"
  CSSParserTokenStream::BlockGuard guard(stream);   // auto-skip to matching "}"

  HeapVector<CSSPropertyValue> properties;
  ConsumeDeclarationList(stream, properties);

  // ④ BUILD THE CSSStyleRule
  return StyleRule::Create(*selector_list,
      CSSPropertyValueSet::Create(properties, context_->Mode()));
}

// ConsumeDeclarationList loops over "ident: value;" until "}":
void CSSParserImpl::ConsumeDeclarationList(CSSParserTokenStream& stream,
                                            HeapVector<CSSPropertyValue>& out) {
  while (!stream.AtEnd()) {
    switch (stream.UncheckedPeek().GetType()) {
      case kWhitespaceToken: case kSemicolonToken:
        stream.UncheckedConsume(); break;
      case kIdentToken:
        ConsumeDeclaration(stream, out, /*important_allowed=*/true);
        break;
      case kAtKeywordToken:
        ConsumeNestedRule(stream, out);    // CSS Nesting · Ch27
        break;
      default:
        // drop bad token, resync at next ";" — Ch9
        ConsumeErrorBlock(stream); break;
    }
  }
}

parser + CSSOM — token 流变规则树

Parser + CSSOM — tokens into a rule tree

CSSParser · StyleSheetContents · CSSRule 家族

CSSParser · StyleSheetContents · the CSSRule family

parser 把 tokenizer 吐出来的 token 流拼成 规则树——也就是 W3C 叫的 "CSSOM"。它解决两件事: ① 把 token 序列识别成 selector / declaration / at-rule 的结构;② 把这棵树挂在 Document.styleSheets 上,让 JS 可以读改。

The parser stitches the tokenizer's stream into a rule tree — what W3C calls the "CSSOM". It does two jobs: ① identify token sequences as selector / declaration / at-rule structures; ② attach the tree to Document.styleSheets so JS can read and mutate.

CSSOM 的 7 个核心类

CSSOM's 7 core classes

// third_party/blink/renderer/core/css/css_rule.h · simplified hierarchy

class CSSRule { ... };                       // abstract base

  class CSSStyleRule : public CSSRule {       // .card { padding: 0.5rem }
    CSSSelectorList  selectors_;                // the ".card" part
    Member<CSSPropertyValueSet> properties_; // the "padding: 0.5rem" part
  };

  class CSSLayerBlockRule : public CSSRule {  // @layer base { ... }
    String name_;                                // "base"
    HeapVector<Member<CSSRule>> child_rules_;  // child rule list
  };

  class CSSContainerRule : public CSSRule {    // @container (...) { ... }
    CSSContainerQuery query_;                  // "(min-width: 400px)"
    HeapVector<Member<CSSRule>> child_rules_;
  };

  class CSSMediaRule · CSSImportRule · CSSKeyframeRule ... // 19 total in Chromium 130

// the outer container, what Document.styleSheets[0] returns
class StyleSheetContents {
  HeapVector<Member<CSSRule>> child_rules_;     // top-level rules
  KURL base_url_;
  ParserContext context_;
  bool has_failed_parser_;                          // ← still false even with errors
};

The Card 解析完是这棵树

The Card, parsed

parse 不是编译—— 它是形状识别

Parse isn't compilation — it's shape recognition

这一点对从 JS / Java 引擎过来的人最反直觉。CSS parser 跑完后,大多数 declaration 的值还是字符串。"oklch(70% 0.15 250)" 没有被算成 sRGB; "var(--brand)" 没有被替换;"0.5rem" 没有被乘以 16 变成 px。所有这些都要等到 cascade 阶段(Ch15-19)再做,因为:

This is the most counterintuitive bit for anyone coming from JS / Java engines. After CSS parsing, most declaration values are still strings. "oklch(70% 0.15 250)" isn't yet sRGB; "var(--brand)" isn't substituted; "0.5rem" isn't multiplied by 16 to px. All of that waits for cascade (Ch15-19), because:

JS 也能改 CSSOM · 但只在一个口子

JS can mutate the CSSOM · through one window

// JS-facing surface — these are CSSStyleSheet IDL methods that bypass the .css fetch path

const sheet = document.styleSheets[0];          // → CSSStyleSheet (wrapper around StyleSheetContents)
sheet.insertRule('.danger { color: red }', 0);   // → re-runs Ch6+Ch7 on this snippet
sheet.cssRules[0].style.padding = '2rem';      // → property mutation, triggers Ch20 InvalidationSet
sheet.deleteRule(0);                            // → remove rule, invalidate every element it matched

// Constructable Stylesheets (2020) — bypass <link> / <style> entirely
const sheet2 = new CSSStyleSheet();
sheet2.replaceSync('.box { color: blue }');
document.adoptedStyleSheets = [sheet2];           // shadow-DOM friendly

@import 与加载顺序 — render-blocking 的根源

@import & load order — why CSS is render-blocking

stylesheet 加载链 · 串行陷阱

the import chain · the serialization trap

CSS 是render-blocking 的——所有 stylesheet 必须 加载并 parse 完,Blink 才允许第一次 paint。@import 让这个问题变得更糟,因为它在 stylesheet 里再触发另一个 stylesheet 的加载,形成串行瀑布。下面这张图把"@import 让 FCP 变慢"这件事讲清楚。

CSS is render-blocking — every stylesheet must be fetched and parsed before Blink permits the first paint. @import makes this worse by triggering another stylesheet fetch from inside a stylesheet — a serial waterfall. The figure below explains why @import slows down FCP.

CSS render-blocking 的真实定义

What "render-blocking" actually means

很多人以为 "CSS render-blocking" 意思是 "CSS 没下载完整页白屏"。这不准确。准确说法是: Blink 不会触发第一次 paint,直到 所有当前已知的非 disabled stylesheet 都加载 + parse 完。这里有几个 非显然 的副作用:

A common belief: "CSS render-blocking" means "whole page is white until CSS arrives". Not quite. More precisely: Blink withholds the first paint until all currently known non-disabled stylesheets have loaded and parsed. Several non-obvious consequences:

错误恢复 — CSS 的"宽容"是怎么实现的

Error recovery — how CSS's "forgiveness" works

drop bad tokens · resync at ; or }

drop bad tokens · resync at ; or }

CSS 跟 JS 最大的工程哲学差别: parse error 不停止解析。JS 看到一个语法错误整段 script 失效;CSS 看到一个错误的 declaration,丢掉它,继续读下一个。这种"forgiveness"不是设计偷懒——它是 Web 向后兼容性的核心,Tim Berners-Lee 和 Håkon Wium Lie 在 1996 年明确写入 spec。

The biggest philosophical divergence from JS: parse errors do not halt parsing. JS sees one syntax error and the whole script dies. CSS sees a bad declaration, drops it, and reads the next one. This "forgiveness" isn't laziness — it's the foundation of Web backward compatibility, written into the spec by Tim Berners-Lee and Håkon Wium Lie in 1996.

4 种错误恢复策略 · 按粒度

4 recovery strategies · by granularity

/* CSS does not stop on errors. Each block here exhibits a recovery strategy. */

.card {
  color: hsl(0);                /* ✗ ① bad value — only 1 arg                  */
  padding: 1rem;                 /*     ↑ drop "color: hsl(0);" → keep padding   */
}

.card::wxyz                          /* ✗ ② unknown pseudo-element                   */
.btn { color: blue; }              /*     ↑ drop whole rule incl. .btn part!       */

@unknown-rule ...;                    /* ✗ ③ unknown at-rule → drop                    */

.ok { color: green; }              /* ✓ parser resumes — this rule still applies   */

恢复算法的真实代码

The recovery algorithm

// core/css/parser/css_parser_impl.cc · simplified — 模拟错误恢复主循环

while (!stream.AtEnd()) {
  auto rule = ConsumeQualifiedRule(stream);
  if (rule) {
    style_sheet->AppendChildRule(rule);
  } else {
    // rule failed — skip past the next "}" or end of input
    while (!stream.AtEnd() && stream.PeekTokenType() != kRightBraceToken) {
      stream.ConsumeIncludingWhitespace();
    }
    if (stream.PeekTokenType() == kRightBraceToken) stream.ConsumeIncludingWhitespace();
  }
}

// ConsumeQualifiedRule itself contains similar resync inside — at ";" for declarations

CSSOM ↔ DOM — 两棵树怎么挂

CSSOM ↔ DOM — how two trees attach

Document.styleSheets · element.computedStyleMap

Document.styleSheets · element.computedStyleMap

CSS 引擎处理的不是一棵树,是两棵: DOM 树(Document → Element → ...)和 CSSOM 树(Document.styleSheets → CSSStyleSheet → CSSRule → ...)。它们独立构造,然后在 cascade 阶段被编织到一起——每个 DOM 节点最终挂一个 ComputedStyle,这个 ComputedStyle 是 CSSOM 跑下来的结果。

The CSS engine doesn't deal with one tree — it deals with two: the DOM tree (Document → Element → ...) and the CSSOM tree (Document.styleSheets → CSSStyleSheet → CSSRule → ...). They build independently, then get woven together during cascade — each DOM node ends up with a ComputedStyle attached, the output of running CSSOM against it.

JS 看到 CSSOM 的三个口子

Three JS entry points into the CSSOM

StyleEngine 的入口 · UpdateActiveStyleSheets

StyleEngine entry · UpdateActiveStyleSheets

// core/css/style_engine.cc · simplified — runs on every style-affecting DOM change

void StyleEngine::UpdateActiveStyleSheets() {
  TRACE_EVENT0("blink", "StyleEngine::UpdateActiveStyleSheets");

  // ① Collect all stylesheets currently attached to the document
  HeapVector<Member<CSSStyleSheet>> new_sheets = CollectActiveStyleSheets();

  // ② Diff against previously active set
  ActiveSheetsChange change = CompareWith(active_user_style_, new_sheets);

  switch (change) {
    case ActiveSheetsChange::kNoChange:
      return;

    case ActiveSheetsChange::kActiveSheetsAppended:
      // fast path: only NEW sheets added at the end → no invalidation walk needed
      AppendActiveSheets(new_sheets);
      break;

    case ActiveSheetsChange::kActiveSheetsChanged:
      // slow path: rebuild RuleSet, invalidate ALL elements that may match changed rules
      RebuildRuleSet();
      InvalidateForRuleSetChange(*old_, *new_);
      break;
  }

  active_user_style_ = new_sheets;
  MarkStyleDirty();   // schedules StyleRecalc on the next frame
}

// Per-element style resolution — runs on every dirty element in the next frame
ComputedStyle* StyleResolver::ResolveStyle(Element& element) {
  // ① Pull candidate rules from RuleSet — Ch13's bloom + bucket lookup
  MatchedPropertiesVector matched =
      rule_set_->CollectMatchingRulesForElement(element);

  // ② Run the 8-step cascade — Ch15
  StyleCascade cascade;
  for (const auto& m : matched)
    cascade.AddMatchedProperties(m);
  cascade.Apply();

  // ③ Resolve var() — Ch18
  ComputedStyle* style = cascade.GetStyle();
  ResolveCustomProperties(style);

  // ④ Compute final values (font-size / em → px, color-mix evaluation) — Ch19
  FinalizeComputedStyle(style, element);

  // ⑤ Attach to element
  element.SetComputedStyle(style);
  return style;
}

选择器 parser — 字符串变 selector 链

Selector parser — string into a selector chain

CSSSelector · 链表 · 组合器

CSSSelector · linked list · combinators

".card:hover" 在 CSSOM 里不是一个字符串——是一条链表。每个 CSSSelector 节点代表一个"简单选择器",通过 tag_history_ 指针串起来。组合器(空格、>、+、~)夹在简单选择器中间。

".card:hover" in CSSOM isn't a string — it's a linked list. Each CSSSelector node represents one simple selector, threaded by a tag_history_ pointer. Combinators (whitespace, >, +, ~) sit between simple selectors.

// core/css/css_selector.h · simplified

class CSSSelector {
  MatchType match_;          // Tag | Class | Id | AttributeExact | PseudoClass | PseudoElement | ...
  AtomicString value_;       // "card" / "hover" / "div"
  PseudoType pseudo_type_;   // PseudoHover / PseudoFocus / PseudoHas / PseudoIs / ...
  RelationType relation_;    // SubSelector | Descendant | Child | DirectAdjacent | IndirectAdjacent
  Member<CSSSelector> tag_history_;  // → next simple selector in the chain
  Member<CSSSelectorList> selector_list_;  // for :is() / :has() / :where() — inner list
};

".card:hover" 解析出来是 2 个节点

".card:hover" decodes into 2 nodes

// Parsing ".card:hover" gives a 2-node linked list:

[node 0] match=PseudoClass · pseudo_type=PseudoHover · relation=SubSelector  →
[node 1] match=Class · value="card" · relation=SubSelector · tag_history=null

// Note: parser stores in right-to-left order on disk, but reads left-to-right.
// The "rightmost simple selector" is head of the linked list — Ch12 explains why.

SelectorChecker — 右到左匹配的精髓

SelectorChecker — the right-to-left match

单元素 · O(选择器长度) · 早剪枝

single element · O(selector length) · early prune

SelectorChecker 回答一个问题: "这个 DOM 元素匹这条选择器吗?"。直觉是从左到右走——选择器写的是 div .card,那就先找 div,再看里面的 .card。实际上 Blink 反着来: 先看当前元素是不是 .card,匹配的话再向上走看祖先里有没有 div。这就是 "right-to-left matching",CSS 引擎的第一性原理。

SelectorChecker answers one question: "does this DOM element match this selector?". The intuition is left-to-right — the selector says div .card, so find the div, then look inside for a .card. In reality Blink goes backwards: check whether the current element is .card first; if yes, walk upward looking for a div ancestor. This is "right-to-left matching", the first principle of every CSS engine.

真实的 MatchSelector 源码

Real MatchSelector source

// third_party/blink/renderer/core/css/selector_checker.cc (~line 220) · simplified

enum class MatchStatus { kSelectorMatches, kSelectorFailsLocally, kSelectorFailsAllSiblings };

MatchStatus SelectorChecker::MatchSelector(
    const SelectorCheckingContext& context, MatchResult& result) {

  // ① CHECK CURRENT COMPOUND (the rightmost simple-selector group)
  if (!CheckOne(context, result)) {
    return MatchStatus::kSelectorFailsLocally;
  }

  // ② IF NO MORE COMPOUNDS — DONE (this was the leftmost)
  if (context.selector->Relation() == CSSSelector::kSubSelector)
    return MatchStatus::kSelectorMatches;

  // ③ RECURSIVELY MATCH PARENT/SIBLING ACCORDING TO COMBINATOR
  SelectorCheckingContext next_context = context;
  next_context.selector = context.selector->TagHistory();

  switch (context.selector->Relation()) {
    case CSSSelector::kDescendant:
      // walk up parent chain — bail when any ancestor matches the parent selector
      for (next_context.element = context.element->parentElement();
           next_context.element;
           next_context.element = next_context.element->parentElement()) {
        if (MatchSelector(next_context, result) == kSelectorMatches)
          return kSelectorMatches;
      }
      return kSelectorFailsLocally;

    case CSSSelector::kChild:
      // only check direct parent
      next_context.element = context.element->parentElement();
      return next_context.element ? MatchSelector(next_context, result)
                                  : kSelectorFailsLocally;

    case CSSSelector::kDirectAdjacent:
      next_context.element = ElementTraversal::PreviousSibling(*context.element);
      return next_context.element ? MatchSelector(next_context, result)
                                  : kSelectorFailsLocally;

    case CSSSelector::kIndirectAdjacent:
      // scan all preceding siblings
      for (next_context.element = ElementTraversal::PreviousSibling(*context.element);
           next_context.element;
           next_context.element = ElementTraversal::PreviousSibling(*next_context.element)) {
        if (MatchSelector(next_context, result) == kSelectorMatches)
          return kSelectorMatches;
      }
      return kSelectorFailsAllSiblings;

    case CSSSelector::kRelativeDescendant:    // :has() forward
    case CSSSelector::kRelativeChild:
    case CSSSelector::kRelativeDirectAdjacent:
    case CSSSelector::kRelativeIndirectAdjacent:
      return MatchHasPseudoClass(context, result);  // special — Ch14

    default:
      return kSelectorFailsLocally;
  }
}

RuleSet 的真实 add 路径

RuleSet's real add path

// core/css/rule_set.cc · simplified — what runs when a new stylesheet enters CSSOM

void RuleSet::AddRule(const RuleData& rule_data) {
  // ① IDENTIFY THE RIGHTMOST SIMPLE SELECTOR (the "key")
  const CSSSelector* selector = rule_data.Selector();   // head of linked list (= rightmost)

  switch (selector->Match()) {
    case CSSSelector::kId:
      id_rules_.Add(selector->Value(), rule_data); break;

    case CSSSelector::kClass:
      class_rules_.Add(selector->Value(), rule_data); break;

    case CSSSelector::kTag:
      // store by lowercased tag name; "*" goes to universal bucket
      if (selector->TagQName().LocalName() == g_star_atom)
        universal_rules_.push_back(rule_data);
      else
        tag_rules_.Add(selector->TagQName().LocalName().LowerASCII(), rule_data);
      break;

    case CSSSelector::kAttributeSet:
    case CSSSelector::kAttributeExact:
      attribute_rules_.Add(selector->Attribute().LocalName(), rule_data); break;

    case CSSSelector::kPseudoClass:
      // pseudo-class rules go into specialized buckets
      if (selector->GetPseudoType() == CSSSelector::kPseudoHover)
        hover_rules_.push_back(rule_data);
      else if (selector->GetPseudoType() == CSSSelector::kPseudoHas)
        has_rules_.push_back(rule_data);    // Ch14
      else
        universal_rules_.push_back(rule_data);   // fall back
      break;

    default:
      universal_rules_.push_back(rule_data);
  }

  // ② BUILD THE ANCESTOR BLOOM (FIG 13·1)
  rule_data.descendant_invalidation_set->ComputeAncestorBloom(selector);

  // ③ REGISTER WITH INVALIDATION FEATURE SET (Ch20)
  features_->CollectFeaturesFromRuleData(rule_data);
}

// Probe: matching an element against the RuleSet

RuleSet::RuleSpan RuleSet::CandidatesForElement(const Element& e) {
  RuleSpan candidates;
  candidates += universal_rules_;
  if (e.HasID()) candidates += id_rules_.Get(e.IdForStyleResolution());
  for (const AtomicString& cls : e.ClassNames())
    candidates += class_rules_.Get(cls);
  candidates += tag_rules_.Get(e.LocalNameForSelectorMatching());
  for (QName attr : e.PresenceAttributes())
    candidates += attribute_rules_.Get(attr.LocalName());
  if (e.HoverState()) candidates += hover_rules_;
  return candidates;   // typically 5-20 entries out of 10 000 rules
}

跨引擎对照 · selector 匹配的三种实现

Cross-engine · three selector-matching implementations

Bloom filter / RuleSet — 决定"哪几条规则要检查"

Bloom filter / RuleSet — deciding "which rules to even check"

为什么 10k 规则也不慢

why 10k rules still aren't slow

Ch12 讲了"给定一条规则,如何匹一个元素"。但一个页面可能有10 000 条规则(典型 SPA),每帧给 5000 个元素跑 cascade 时,如果对每个元素 × 每条规则 都跑 SelectorChecker,那是 5 000 万次匹配。现实是 Blink 每帧只跑几千次 SelectorChecker——10 000× 的差距来自 RuleSet 索引 + Bloom filter。

Ch12 explained "given a rule, match it against an element". But a real page often has 10 000 rules (typical SPA), and each frame must cascade ~5000 elements — naively, element × rule = 50 million matches. Reality: Blink runs only a few thousand SelectorChecker invocations per frame — a 10 000× pruning win, courtesy of RuleSet indices + Bloom filter.

两层索引 · 元素 → 候选规则

Two-layer index · element → candidate rules

// core/css/rule_set.h · simplified

class RuleSet {
  // Layer 1: hash maps keyed by the rightmost simple selector
  HashMap<AtomicString, RuleData[]> id_rules_;          // "#main" → [rules]
  HashMap<AtomicString, RuleData[]> class_rules_;       // "card" → [rules]
  HashMap<AtomicString, RuleData[]> tag_rules_;         // "p" → [rules]
  HashMap<String, RuleData[]> attr_rules_;
  RuleData[] universal_rules_;                          // "*" rules — checked for everyone

  // Layer 2: per-rule ancestor bloom filter (32 bits)
  // For each rule, hash all its compound ancestors into 32 bits.
  // At match time, hash the element's ancestor chain too, AND them.
  // If zero → ancestor cannot match → skip rule.
};

// MATCHING AN ELEMENT (simplified)
RuleData[] candidates;
for (String cls : element.classList())
  candidates += rule_set.class_rules_.get(cls);
for (String attr : element.attributeNames())
  candidates += rule_set.attr_rules_.get(attr);
candidates += rule_set.tag_rules_.get(element.tagName());
candidates += rule_set.id_rules_.get(element.id());
candidates += rule_set.universal_rules_;

for (RuleData rule : candidates) {
  if (!BloomFilterAcceptsAncestors(rule, element)) continue;  // fast prune
  if (SelectorChecker::Match(rule.selector, element))    // real check (Ch12)
    apply(rule);
}

Bloom filter 怎么工作 · 4-hash 32-bit

How the bloom filter works · 4-hash 32-bit

Blink 的 ancestor bloom 是一个每个元素一份的 32-bit 位图。元素的每个祖先(class / id / tag)按 4 个哈希函数定 4 个比特。匹配规则时,把规则的"祖先需求"(也是 32-bit bloom)和元素的 bloom AND 一下: 如果规则要的比特 ⊄ 元素有的比特,规则不可能匹——立刻跳过。

Blink's ancestor bloom is a 32-bit bitmap per element. Every ancestor (class / id / tag) hashes through 4 hash functions, setting 4 bits. To match a rule, AND the element's bloom against the rule's "ancestor requirement" bloom: if the rule's required bits aren't all in the element's bits, the rule cannot match — skip immediately.

:has() / :is() / :where() — 选择器的两次大跃迁

:has() / :is() / :where() — selector's two leaps

selectors-4 · 2023 ship · 反向选择器

selectors-4 · 2023 ship · backward selectors

2023 年 :has() 在所有浏览器同时 ship 是 CSS 30 年里最重要的能力跃迁。它给选择器加了一个之前不存在的语义维度: 从子树往上看。:is() / :where() 是与之配套的错误恢复升级。

When :has() shipped in every browser in 2023, it was CSS's biggest capability leap in 30 years. It gave selectors a semantic dimension that didn't exist before: looking upward from a subtree. :is() / :where() are the matching error-recovery upgrades.

/* :has() examples — all impossible before 2023 in pure CSS */

form:has(input:invalid)     { border-color: red; }          /* form 有非法 input → 给 form 红边 */
ul:has(> li.active)          { padding: 1rem; }            /* ul 有 active 子 li → padding */
article:has(h2 + p)          { font-size: 1.1rem; }        /* article 内有 h2+p 序列 */

/* The "upward" semantics. :has() lets selectors look down a subtree. */
/* This wipes out an entire category of JS use cases. */

跨引擎对照 · cascade 实现的三种风格

Cross-engine comparison · three cascade flavours

Cascade — 8 步决定谁赢

Cascade — 8 steps to a winner

"谁的属性值最终生效"

"whose property value wins"

SelectorChecker(Ch12)告诉你"这条规则匹中了"。但当 10 条规则同时匹中、且都声明了 color 时,哪条赢? 这就是 cascade 的工作: 跑一个 8 步的优先级算法,每个属性独立选出一个 winner。

SelectorChecker (Ch12) tells you "this rule matched". But when 10 rules all match and all declare color, which wins? Cascade's job: run an 8-step priority algorithm, per property, to pick a single winner.

StyleCascade.cc · 8 步代码层面是 12 个 priority 字段

StyleCascade.cc · 8 spec steps map to 12 priority fields

// third_party/blink/renderer/core/css/resolver/cascade_priority.h · simplified

// CascadePriority is a 64-bit struct that packs all the tie-breakers from
// FIG 15·1 into one comparable integer.
// Higher value = wins.

struct CascadePriority {
  // Bits laid out big-endian to enable lexicographic compare via <:
  uint64_t important : 1;          // !important reverses origin order
  uint64_t origin : 3;             // UserAgent / User / Author / Animation / Transition
  uint64_t tree_order : 16;        // shadow-tree depth · author scope
  uint64_t layer_order : 16;       // @layer ordering · unlayered = max
  uint64_t specificity : 24;       // (a,b,c) packed as 8+8+8 bits
  uint64_t position : 4;           // order of appearance (fallback)

  bool operator<(const CascadePriority& o) const {
    return AsBits() < o.AsBits();   // single 64-bit compare
  }
};

// StyleCascade::Apply() · simplified main loop
void StyleCascade::Apply(CascadeFilter filter) {
  CascadeMap & map = matched_properties_;   // declaration set per property

  for (CSSPropertyID id : map.Properties()) {
    CascadePriority best = CascadePriority::Min();
    CSSPropertyValue winner;

    for (auto& entry : map.FindRevert(id)) {
      if (entry.priority > best) {
        best = entry.priority;
        winner = entry.value;       // single argmax per property
      }
    }

    state_->StyleBuilder().SetProperty(id, winner);
  }
}

Specificity — (a, b, c) 真实算法

Specificity — the (a, b, c) tuple math

不是 (a, b, c, d),不是 256 进制

not (a, b, c, d), not base-256

特异性(specificity)的算法在网上有无数错版本。常见错误: ① 说是 "(a, b, c, d)" 元组(其实 selectors-3 起就是 (a, b, c) 三元组,inline style 是另一个 tier);② 说每位是 256 进制(不是,只是按位元组比较);③ 把 !important 算在 specificity 里(不对——!important 在 cascade step ①,Ch15 详)。

Specificity is the most-misexplained algorithm on the web. Common errors: ① calling it "(a, b, c, d)" tuple (actually since selectors-3 it's a (a, b, c) triple — inline style is a separate cascade tier); ② claiming each digit is base-256 (nope, just component-wise tuple comparison); ③ putting !important in specificity (wrong — !important lives in cascade step ① per Ch15).

真正的算法

The actual algorithm

// selectors-4 §16 · Specificity is a (a, b, c) triple:
//   a = count of ID selectors in the selector
//   b = count of class selectors + attribute selectors + pseudo-classes
//   c = count of type selectors + pseudo-elements
// Comparison: lexicographic — compare a first, then b, then c.
// Universal "*", combinators ">", "+", "~", " " all count 0.

.card                          → (0, 1, 0)
.card:hover                    → (0, 2, 0)  ← :hover is a pseudo-class, counts in b
div.card                       → (0, 1, 1)
#main .card                    → (1, 1, 0)  ← #id is one a, .class is one b
.a .b .c .d .e .f .g .h .i .j .k  → (0, 11, 0)  ← NOT (0, 1, 1) — no overflow!
::before                       → (0, 0, 1)  ← ::pseudo-element counts in c, NOT b

// Tie-break in cascade step ⑤ (Ch15):  (1,0,0) > (0,99,99)  because a is compared first.

三个常见误判

Three common errors

CSSSelector::GetSpecificity 真实代码

CSSSelector::GetSpecificity actual code

// core/css/css_selector.cc · simplified GetSpecificity walk

unsigned CSSSelector::Specificity() const {
  unsigned a = 0, b = 0, c = 0;

  // Walk the entire compound chain (head → tail via tag_history_)
  for (const CSSSelector* sel = this; sel; sel = sel->TagHistory()) {
    switch (sel->Match()) {
      case kId:
        ++a; break;

      case kClass:
      case kAttributeExact:
      case kAttributeSet:
      case kAttributeHyphen:
      case kAttributeList:
      case kAttributeContain:
      case kAttributeBegin:
      case kAttributeEnd:
        ++b; break;

      case kPseudoClass:
        // :is() / :where() / :has() — pick MAX inside
        switch (sel->GetPseudoType()) {
          case kPseudoIs:
          case kPseudoHas:
          case kPseudoNot: {
            unsigned max_a = 0, max_b = 0, max_c = 0;
            for (const CSSSelector* sub : sel->SelectorList()) {
              auto [sa, sb, sc] = sub->DecomposeSpecificity();
              if (SpecificityTuple{sa, sb, sc} > SpecificityTuple{max_a, max_b, max_c}) {
                max_a = sa; max_b = sb; max_c = sc;
              }
            }
            a += max_a; b += max_b; c += max_c; break;
          }
          case kPseudoWhere:    // :where() adds 0!
            break;
          default:
            ++b;             // :hover, :focus, :checked etc — count as class
        }
        break;

      case kTag:
        if (sel->TagQName().LocalName() != g_star_atom)
          ++c;               // "*" counts 0
        break;

      case kPseudoElement:
        ++c; break;          // ::before / ::after — pseudo-element counts in c
    }
  }
  // PACK into 32-bit: 8 bits a (cap 255) | 8 bits b | 16 bits c
  return (a << 24) | (b << 16) | c;
}

@layer — 级联层 · 终结 specificity 战争

@layer — cascade layers · ending specificity wars

2022 ship · 把 specificity 装进盒子

2022 ship · specificity in a box

@layer 是 2022 年 ship 的结构化 cascade。它在 Ch15 cascade 第 ④ 步——比 specificity 高一级。意思: 不同 layer 里的规则不用比 specificity,layer 顺序就分了胜负。

@layer shipped in 2022 as structured cascade. It sits at Ch15's cascade step ④ — one tier above specificity. Meaning: rules in different layers don't bother comparing specificity; layer order already decided who wins.

/* Layers are declared, then ordered. */

@layer reset, base, theme, utilities;     /* declares order — first = lowest priority */

@layer reset {
  .btn#submit { background: gray; }    /* (1,1,0) — high specificity, but in low layer */
}

@layer utilities {
  .btn { background: blue; }            /* (0,1,0) — low specificity, but in HIGH layer */
}

/* Result: button is BLUE.
   Even though .btn#submit has higher specificity (1,1,0) vs (0,1,0),
   @layer "utilities" wins over @layer "reset" by step ④ before step ⑤ even runs. */

CSSVariableData::ResolveTokenRange · 真实代码

CSSVariableData::ResolveTokenRange · real code

// core/css/css_variable_data.cc · simplified var() resolution

bool CSSVariableData::ResolveTokenRange(
    const StyleResolverState& state,
    CSSParserTokenRange range,
    Vector<CSSParserToken>& out_tokens,
    HashSet<AtomicString>& visiting) {     // ← cycle-detection set

  while (!range.AtEnd()) {
    const CSSParserToken& token = range.Peek();

    if (token.FunctionId() == kVarFunction) {
      range.ConsumeIncludingWhitespace();           // eat "var("
      AtomicString var_name = range.ConsumeIdent();

      // ① cycle detect
      if (!visiting.insert(var_name).is_new_entry) {
        // already visiting this variable → cycle!
        return false;
      }

      // ② resolve recursively
      CSSVariableData* var_data = state.CustomProperty(var_name);
      Vector<CSSParserToken> substituted;
      bool ok = false;
      if (var_data) {
        ok = ResolveTokenRange(state, var_data->TokenRange(),
                                substituted, visiting);
      }

      // ③ pop from visit set (DFS unwind)
      visiting.erase(var_name);

      if (ok) {
        out_tokens.AppendVector(substituted);
      } else {
        // ④ failed — try fallback (var() second arg)
        if (range.Peek().GetType() == kCommaToken) {
          range.ConsumeIncludingWhitespace();
          if (!ResolveTokenRange(state, range, out_tokens, visiting))
            return false;
        } else {
          return false;     // no fallback → guaranteed-invalid
        }
      }
      range.ConsumeIncludingWhitespace();   // eat ")"
    } else {
      out_tokens.push_back(range.Consume());
    }
  }
  return true;
}

@layer 实现 · CascadeLayer + LayerMap

@layer impl · CascadeLayer + LayerMap

// core/css/cascade_layer.h · simplified

class CascadeLayer {
  String name_;                            // "base" / "theme" / "" (anonymous)
  uint32_t order_;                          // resolved order index — lower = earlier = lower priority
  HeapVector<Member<CascadeLayer>> sublayers_; // @layer theme { @layer dark { ... } }
};

class LayerMap {
  HashMap<String, Member<CascadeLayer>> by_name_;
  HeapVector<Member<CascadeLayer>> in_order_;     // determined by declaration order
  Member<CascadeLayer> implicit_unlayered_;       // the "naked" bucket · always highest
};

// When parser encounters @layer reset, base, theme; it CREATES (or finds) these layers
// in the order they appear. Subsequent @layer reset { ... } blocks reopen the same layer.

void LayerMap::DeclareOrder(const Vector<String>& names) {
  for (size_t i = 0; i < names.size(); ++i) {
    CascadeLayer* layer = EnsureLayer(names[i]);
    layer->order_ = i;     // "reset" gets 0, "base" gets 1, "theme" gets 2
  }
  // implicit_unlayered_->order_ = std::numeric_limits<uint32_t>::max()
  // (so it always wins layer comparison)
}

// Cascade step ④ — comparing two declarations' layers:
bool LayerWins(const CascadeLayer* a, const CascadeLayer* b) {
  return a->order_ > b->order_;
}

Custom Properties — 把 CSS 变成动态语言

Custom Properties — CSS becomes dynamic

CSSVariableData · 延迟解析 · 循环检测

CSSVariableData · lazy resolution · cycle detection

--brand: oklch(70% 0.15 250) 在声明时不会被解析。Blink 把整段 oklch(...) 字符串塞进 CSSVariableData 对象,挂在 :root 的 ComputedStyle 上。等到某个元素用 background: var(--brand) 时,Blink 才查 --brand 的值、展开到 oklch(...)、再 parse成 sRGB。

--brand: oklch(70% 0.15 250) isn't resolved at declaration time. Blink stuffs the whole oklch(...) string into a CSSVariableData object hanging off :root's ComputedStyle. When an element uses background: var(--brand), Blink looks up --brand, substitutes the oklch(...), then parses it as sRGB.

// var() resolution — simplified

:root           { --brand: oklch(70% 0.15 250); }   /* string stored verbatim */
.card           { background: var(--brand); }       /* "lookup + substitute" needed */
.card.dark      { --brand: oklch(40% 0.15 250); }  /* overrides at .card.dark — Blink walks up inheritance */

/* RESOLUTION ORDER for .card.dark element:                                      */
/*   1. Look up --brand on .card.dark's ComputedStyle → "oklch(40% 0.15 250)"     */
/*   2. Substitute into background → "oklch(40% 0.15 250)"                       */
/*   3. Parse as CSS color → sRGB / OKLCH                                        */
/*   4. Store as actual ComputedStyle.background                                 */

循环引用怎么处理

Cycles · how Blink handles them

:root {
  --a: var(--b);
  --b: var(--a);    /* ✗ cycle → CSS spec: treat both as guaranteed-invalid */
}

.card {
  background: var(--a);                /* result: initial value (transparent) */
  background: var(--a, red);          /* fallback! var() takes default arg */
}

:root { --w: 70%; }
.a { width: var(--w); }                       /* width: 70%  ✓ */
.b { background: hsl(var(--w), 50%, 50%); }    /* hsl(70%, 50%, 50%) — invalid! 70% isn't a hue */

四种值 — specified / computed / used / actual

Four values — specified / computed / used / actual

每个属性有四个不同状态的值

every property has four stages of value

"width: 50%" 在 CSS 内部其实有四个不同的值——分别对应"用户写的"、"cascade 选出来的"、"跟 layout 配合算的"、"真正应用的"。理解这四种是理解所有"为什么 getComputedStyle 返回 px 不是 %"类问题的钥匙。

"width: 50%" actually has four different values inside CSS — corresponding to "what the user wrote", "what cascade picked", "what layout produced", and "what actually applies". Understanding these four is the key to every "why does getComputedStyle return px not %" question.

InvalidationSet — 一次 DOM 改动怎么不触发全页重算

InvalidationSet — how one DOM change doesn't recalc the whole page

从 O(N · rules) 到 O(dirty)

from O(N · rules) to O(dirty)

假设你在一个有 10 000 个元素 + 1000 条规则的页面上,JS 给某个 div 加了 class "card"。朴素方案: 每个元素 × 每条规则跑一遍 selector match——10 000 000 次 SelectorChecker,显然不行。Blink 的解法叫 InvalidationSet: 在编译规则的时候就记下"如果这个 class / id / attribute 改了,会影响哪些祖先 / 兄弟 / 后代"。改 class 时,只查这张预算好的表,标真的需要重算的节点 dirty。

Imagine a page with 10 000 elements + 1000 rules. JS adds class "card" to one div. The naive approach: rerun selector match for every element × every rule — 10 million SelectorChecker calls. Obviously not viable. Blink's answer: InvalidationSet. At rule-compile time, precompute "if this class / id / attribute changes, which ancestors / siblings / descendants are affected". When a class flips, consult that precomputed table and mark only the truly-affected nodes dirty.

// core/css/invalidation/invalidation_set.h · simplified

class InvalidationSet {
  InvalidationType type_;       // Descendant | Sibling | Nth | SubtreeIfHover ...
  HashSet<AtomicString> classes_;     // class names whose descendant must recalc
  HashSet<AtomicString> ids_;
  HashSet<AtomicString> tag_names_;
  HashSet<AtomicString> attributes_;
  bool whole_subtree_invalid_;     // ← worst case: nuke subtree (e.g. with [attr~=*])
};

// RuleFeatureSet — built once when stylesheet enters CSSOM.
// Keys are "features" (class / id / attr / pseudo). Values are InvalidationSets.
class RuleFeatureSet {
  HashMap<AtomicString, Member<InvalidationSet>> class_invalidation_sets_;
  HashMap<AtomicString, Member<InvalidationSet>> id_invalidation_sets_;
  HashMap<AtomicString, Member<InvalidationSet>> attribute_invalidation_sets_;
  ...
};

一个例子 · ".card .btn" 的 InvalidationSet

Worked example · the InvalidationSet for ".card .btn"

/* Source rule: */
.card .btn { color: red; }

/* When this rule enters CSSOM, Blink builds two InvalidationSet entries: */

// "card" → InvalidationSet { type: Descendant, classes: ["btn"] }
// "btn"  → InvalidationSet { type: Descendant, classes: [] }     // empty — leaf already known

/* MEANING:                                                                   */
/*   - When element.classList toggles "card" → walk descendants, find .btn,   */
/*     mark them dirty.                                                       */
/*   - When element.classList toggles "btn" → mark only THIS element dirty,   */
/*     no descendant walk needed.                                             */
/*   - Siblings, ancestors, unrelated subtrees: untouched.                    */

StyleInvalidator.cc · 实际 walk 代码

StyleInvalidator.cc · the actual walk

// core/css/invalidation/style_invalidator.cc · ~simplified

void StyleInvalidator::InvalidateForClassChange(
    Element& element, const AtomicString& changed_class) {

  // ① Look up which InvalidationSet was precomputed for this class name
  const InvalidationSet* set =
      rule_feature_set_->class_invalidation_sets_.at(changed_class);
  if (!set) return;   // no rule uses ".foo" in any cascading way

  // ② Always dirty THIS element if class name matters at all
  element.SetNeedsStyleRecalc(kLocalStyleChange);

  // ③ Walk descendants if the invalidation set says "descendant"
  if (set->type() == InvalidationType::kInvalidateDescendants) {
    for (Element& descendant : ElementTraversal::DescendantsOf(element)) {
      if (set->InvalidatesElement(descendant)) {
        descendant.SetNeedsStyleRecalc(kLocalStyleChange);
      }
    }
  }

  // ④ Sibling invalidation — only walk the affected siblings
  if (set->type() == InvalidationType::kInvalidateSiblings) {
    Element* sibling = ElementTraversal::NextSibling(element);
    for (; sibling; sibling = ElementTraversal::NextSibling(*sibling)) {
      if (set->InvalidatesElement(*sibling)) {
        sibling->SetNeedsStyleRecalc(kLocalStyleChange);
      }
      if (!set->invalidates_subsequent_siblings()) break;   // "+" stops here
    }
  }

  // ⑤ :has() — backward walk, see Ch14
  if (const auto& has_set = set->SiblingInvalidationSet()) {
    InvalidateHasAncestor(element, has_set);
  }
}

sibling / descendant 边界 — combinator 怎么影响失效

Sibling / descendant boundaries — how combinators affect invalidation

空格 · > · + · ~ · :has()

whitespace · > · + · ~ · :has()

选择器里的组合器决定 InvalidationSet 的类型。这是为什么 .card + .btn 比 .card .btn 在 invalidation 上更贵——后者只往后代看,前者还要往兄弟看。

A selector's combinator determines the InvalidationSet's type. This is why .card + .btn is more expensive to invalidate than .card .btn — the latter only inspects descendants, the former also inspects siblings.

StyleRecalc 触发条件 — 真正会让样式重算的事件

StyleRecalc triggers — what really forces a recalc

DOM 改动 · 伪类切换 · viewport 变化

DOM mutations · pseudo-class flips · viewport changes

什么操作会让 Blink 重跑 cascade?这是页面性能优化里被最频繁问错的问题。看下面这张表:

What actions cause Blink to rerun cascade? This is the most-frequently-asked-wrong question in page perf optimisation. The table below:

transition / animation 数据模型

Transition / animation data model

KeyframeEffect · Animation · timeline

KeyframeEffect · Animation · timeline

CSS transition 和 animation 在 Blink 内部都被翻译成同一个数据模型: Web Animations API 的三件套——Animation(控制对象)、KeyframeEffect(关键帧序列)、AnimationTimeline(时间源)。transition 是 sugared form,animation 也是 sugared form——它们都被脱糖到 Web Animations 内核。

CSS transition and animation are both translated inside Blink into the same data model: the Web Animations API trio — Animation (controller), KeyframeEffect (frame sequence), and AnimationTimeline (time source). transition is sugar; animation is sugar; both desugar to the Web Animations kernel.

// core/animation/ · simplified

class Animation {
  Member<AnimationEffect> effect_;            // what to animate (one keyframe set)
  Member<AnimationTimeline> timeline_;         // time source (DocumentTimeline / ScrollTimeline)
  PlayState play_state_;                       // idle | running | paused | finished
  Optional<double> start_time_;                  // when did it start (in timeline)
  double playback_rate_;                          // 1.0 = normal · -1.0 = reverse
};

class KeyframeEffect : public AnimationEffect {
  Member<Element> target_;
  HeapVector<Keyframe> keyframes_;             // e.g. [{ background: red }, { background: blue }]
  EffectTiming timing_;                         // duration, easing, delay, iteration count
};

class DocumentTimeline : public AnimationTimeline {
  double CurrentTime() override { return doc_->RenderingTime(); }
};

CSS transition 怎么变 Animation

How CSS transition becomes an Animation

/* Source: */
.card       { background: red; transition: background 200ms; }
.card:hover { background: blue; }

/* When .card transitions from no-hover to hover, Blink synthesises: */

const animation = new Animation(
  new KeyframeEffect(
    card_element,
    [
      { background: 'red',  offset: 0 },
      { background: 'blue', offset: 1 }
    ],
    { duration: 200, easing: 'ease' }
  ),
  document.timeline
);
animation.play();   // auto-cleanup when finished, identical to JS-created animations

Compositor offload — 哪些属性能 GPU 跑

Compositor offload — which properties go GPU

transform · opacity · filter · ...

transform · opacity · filter · ...

Web 性能最常说的 "animate transform/opacity 而不是 left/top" 其实是 Compositor Offload 的简化版本。背后机制是: Blink 把 layer 树发给 Compositor 线程(不是 main thread),Compositor 在每帧自己跑 transform 和 opacity 插值,完全不用打扰 main thread。这就是为什么这两个属性能在 100% main-thread-busy 时仍能 60 fps 动画。

Web perf's classic advice "animate transform/opacity instead of left/top" is the dumbed-down version of Compositor Offload. The mechanism: Blink ships the layer tree to the Compositor thread (not main thread), and the Compositor interpolates transform and opacity each frame without ever bothering main. That's why these two properties can hit 60 fps even when main thread is at 100% busy.

/* ✗ TRIGGERS LAYOUT EVERY FRAME — main thread death spiral */
.bad { transition: left 300ms; }
.bad.open { left: 200px; }

/* ✓ COMPOSITOR-ONLY — 60 fps even under heavy main-thread load */
.good { transition: transform 300ms; }
.good.open { transform: translateX(200px); }

Compositor 怎么决定谁该 promote

How the compositor decides who gets promoted

// core/paint/paint_layer.cc · simplified Layerizer decision

CompositingReasons PaintLayer::DirectCompositingReasons() const {
  CompositingReasons reasons = CompositingReason::kNone;

  // ① TRANSFORM that animates or is 3D
  if (style_->HasTransform() &&
      (style_->Has3DTransform() || HasActiveTransformAnimation())) {
    reasons |= CompositingReason::k3DTransform;
  }

  // ② OPACITY that animates
  if (HasActiveOpacityAnimation()) {
    reasons |= CompositingReason::kActiveOpacityAnimation;
  }

  // ③ FILTER (any filter forces a layer for offload)
  if (style_->HasNonInitialBackdropFilter() ||
      HasActiveFilterAnimation()) {
    reasons |= CompositingReason::kBackdropFilter;
  }

  // ④ will-change hint — user said "this WILL animate"
  if (style_->HasWillChangeTransformHint() ||
      style_->HasWillChangeOpacityHint()) {
    reasons |= CompositingReason::kWillChangeTransform;
  }

  // ⑤ position: fixed if scrolling matters
  if (style_->GetPosition() == EPosition::kFixed &&
      DescendantsHaveScrollableAreas()) {
    reasons |= CompositingReason::kFixedPosition;
  }

  // ⑥ canvas / video / iframe / WebGL — always their own layer
  if (IsVideoElement() || IsCanvasElement() || IsIFrame()) {
    reasons |= CompositingReason::kVideo;
  }

  return reasons;
}

// "Layerizer" runs this for every PaintLayer and stitches together the layer tree.
// A page with 5000 elements and 0 transforms/opacity/will-change typically has
// JUST ONE compositor layer (the root). The Card adds ZERO additional layers
// because its transition is on background (non-offloadable).

animation-timeline / scroll-driven — 2024 起 CSS 接管滚动联动

animation-timeline / scroll-driven — CSS owns scroll-bound motion since 2024

ScrollTimeline · ViewTimeline · animation-range

ScrollTimeline · ViewTimeline · animation-range

2024 之前,"滚动联动动画" 必须靠 JS 监听 scroll 事件然后改 transform——主线程消耗大,容易掉帧。CSS 把这种常用模式抽出来变成原生概念: scroll-timeline 让动画的时间源不再是 wall-clock 而是 scroll position,直接跑在 compositor 线程上。

Before 2024, "scroll-bound animations" required JS scroll listeners updating transform — heavy on the main thread, easily jank. CSS lifted this common pattern into a native concept: scroll-timeline swaps the animation's time source from wall-clock to scroll position, running entirely on the compositor.

/* Old way — JS scroll listener (jank-prone): */
window.addEventListener('scroll', () => {
  el.style.transform = `translateY(${window.scrollY * 0.5}px)`;
});

/* New way — pure CSS, runs on compositor: */
.parallax {
  animation: parallax-move linear;
  animation-timeline: scroll(root block);
}

@keyframes parallax-move {
  from { transform: translateY(0); }
  to   { transform: translateY(-200px); }
}

/* Or scoped to an element entering the viewport: */
.fade-in {
  animation: appear linear;
  animation-timeline: view();
  animation-range: entry 0% cover 50%;   /* play as it scrolls in */
}

Container Queries — 让组件知道容器多大

Container Queries — letting a component see its container

2022 ship · containment + size query

2022 ship · containment + size query

CSS 30 年来,响应式只能问 "viewport 多大"——但 web 组件的真实需求是问 "我所在的父容器多大"(同一个 Card 在 sidebar 里窄,在主区宽,该用不同布局)。@container 在 2022 解决了这个问题——但不是免费: 每个 container 必须先声明 containment(container-type: inline-size),Blink 才能在 layout 完成后再跑一次依赖该 container 大小的 cascade。

For 30 years CSS could only ask "how big is the viewport" — but web components actually need to ask "how big is my parent container" (same Card narrow in a sidebar, wide in main area, different layout each). @container answered this in 2022 — but it's not free: each container must declare containment (container-type: inline-size) first, so Blink can rerun cascade after layout for rules depending on that container's size.

/* Setup */
.container {
  container-type: inline-size;       /* opt in · enables inline-size queries inside */
  container-name: card-host;          /* optional name · @container card-host (...) */
}

/* Query */
@container card-host (min-width: 400px) {
  .card { flex-direction: row; }
}
@container (max-width: 399px) {
  .card { flex-direction: column; }
}

为什么 container-type 是必要的

Why container-type is required

@container · Blink 实现细节

@container · Blink internals

// core/css/container_query.cc · simplified

class ContainerQuery {
  MediaQueryExpNode* expression_;     // "(min-width: 400px)"
  AtomicString container_name_;        // optional named container
};

bool ContainerQuery::Matches(const Element& element) const {
  // ① Walk UP the ancestor chain to find the nearest containing element
  const Element* container = element.parentElement();
  while (container) {
    const ComputedStyle* style = container->EnsureComputedStyle();

    if (style->ContainerType() == EContainerType::kNone) {
      container = container->parentElement();
      continue;
    }

    // ② Check container-name match (or unnamed)
    if (!container_name_.IsEmpty() &&
        !style->ContainerNames().Contains(container_name_)) {
      container = container->parentElement();
      continue;
    }

    // ③ Found! Now check if size is queryable yet (layout must have run)
    if (!container->HasFinishedLayout()) {
      // Pass 1 of two-pass — defer evaluation
      style_engine_->MarkContainerForPostLayoutQuery(container, query: this);
      return false;   // will re-evaluate in pass 2
    }

    // ④ Evaluate the size query against container's layout box
    LayoutSize size = container->GetLayoutBox()->ContentBoxSize();
    MediaQueryEvaluator eval(size, container->GetDocument());
    return eval.Eval(*expression_);
  }

  // No matching container found — query fails silently
  return false;
}

@scope / nesting — CSS 终于支持嵌套了

@scope / nesting — CSS finally has nesting

2023 ship · 终止 Sass 时代

2023 ship · ending the Sass era

2023 年 ship 的 CSS Nesting 解决了一个让 Sass / Less / Stylus 火了 15 年的痛点: 嵌套书写。@scope 进一步给了"限定作用域"的能力——一段样式只对某个子树生效,不溢出。这两个特性合起来让 Sass 类预处理器的必要性大幅下降。

CSS Nesting shipping in 2023 solved the pain that kept Sass / Less / Stylus alive for 15 years: nested syntax. @scope further added "scoped style block" — styles that apply only within a subtree, no leakage. Together these two cut the necessity of CSS preprocessors dramatically.

/* CSS Nesting · 2023 */
.card {
  padding: 1rem;

  & .title {                  /* & is the parent reference, like Sass */
    font-weight: bold;
  }

  &:hover {                   /* & required even for pseudo-classes */
    background: blue;
  }
}

/* @scope · 2023, scoped style block (avoids descendant leakage) */
@scope (.dialog) to (.dialog-footer) {
  .button { color: red; }    /* only applies to .button INSIDE .dialog but NOT past .dialog-footer */
}

anchor positioning · view-transitions · color-mix — 2024 阵容

anchor positioning · view-transitions · color-mix — the 2024 lineup

三个把大量 JS 用法装回 CSS 的特性

three features taking JS use cases back into CSS

2024 年 CSS 同时 ship 了三个能力,各自杀掉一个 JS 库生态:

2024 was CSS's "kill the JS library" year — three features shipped, each replacing an entire JS ecosystem:

/* ① anchor positioning */
.button { anchor-name: --my-anchor; }
.tooltip {
  position-anchor: --my-anchor;
  position-area: top;            /* place tooltip above the anchor */
  left: anchor(center);          /* x = anchor's horizontal center */
}

/* ② view-transitions · JS triggered, declarative styled */
::view-transition-old(thumb) { animation: 300ms fade-out; }
::view-transition-new(thumb) { animation: 300ms fade-in; }
/* JS side: document.startViewTransition(() => updateDom()) */

/* ③ color-mix · works for any blending */
.muted { color: color-mix(in oklch, var(--brand), white 40%); }
.darker { background: color-mix(in srgb-linear, var(--brand), black 20%); }

view-transitions · 浏览器自动 cross-fade 的真相

view-transitions · how the browser auto cross-fades

// JS triggers — browser captures BEFORE and AFTER frames
document.startViewTransition(() => {
  updateDom();             // any mutation: replace nodes, change class, route navigation
});

/* CSS controls the animation between BEFORE and AFTER */
::view-transition-old(root),
::view-transition-new(root) {
  animation-duration: 300ms;
  animation-timing-function: ease-in-out;
}

::view-transition-old(root) {
  animation-name: fade-out;
}
::view-transition-new(root) {
  animation-name: fade-in;
}

/* Per-element transitions — capture each named region separately */
.thumbnail {
  view-transition-name: thumb;     /* makes a "shared element" between old & new */
}
::view-transition-old(thumb),
::view-transition-new(thumb) {
  animation: 300ms ease morph;   /* will lerp position+size automatically */
}

性能模型 — 一次 style update 多少 ms

Performance model — how many ms per style update

9 个阶段的实测开销

measured cost per stage

读到这里你已经能看见 CSS 引擎的形状。最后这章把"一次 style update 多少 ms" 摊到 9 个阶段上,给你一张可用的性能心智图。所有数据来自典型企业级 SPA(5k DOM 节点 · 1k 规则 · M2 MacBook · Chrome 130 中位数)。

By here you can see the engine's shape. This final chapter breaks "how many ms per style update" across the 9 stages, giving you a usable perf mental model. Numbers from a typical enterprise SPA (5k DOM nodes · 1k rules · M2 MacBook · Chrome 130 median).

5 个最常见性能陷阱

5 most common perf traps

DevTools Performance 里的 trace event 名字

Trace event names you'll see in DevTools Performance

// How to capture a trace programmatically (for CI):
chrome --remote-debugging-port=9222 --headless --disable-gpu

// then via DevTools Protocol:
await page.tracing.start({ categories: ["blink.user_timing", "devtools.timeline"] });
await page.goto(url);
await page.tracing.stop();   // → JSON trace, load in DevTools or chrome://tracing

DevTools — 三个面板覆盖 80% 调试场景

DevTools — 3 panels cover 80% of debugging

Elements · Performance · Animations

Elements · Performance · Animations

References — 每个论断的出处

References — sources for every claim

W3C · Blink 源码 · 演讲 · 历史文档

W3C · Blink source · talks · historical docs

A · W3C / CSS WG specs · 核心

A · W3C / CSS WG specs · core

B · 2022-2026 新特性

B · 2022-2026 new features

C · Blink 源码 · 关键文件

C · Blink source · key files

D · 设计文档 / blog

D · design docs / blog posts

E · 历史 / 文化

E · history / culture

F · 跨文章互联

F · sibling articles in this series

本节共 ~50 条外部引用,覆盖每条非自明论断。如发现链接失效或事实漂移,issue 见 airingursb/airingursb.github.io。

This section carries ~50 external references, one for every non-self-evident claim. Broken link or factual drift → file an issue at airingursb/airingursb.github.io.

"读 CSS 引擎源码不是为了变成更好的CSS 用户——是为了变成"它的同事。" "Reading the CSS engine source isn't to become a better CSS user — it's to become its colleague." — Airing, 2026 (本文末)