freeCodeCamp Basic CSS 实战：让页面元素继承 body 元素的样式与测试验证机制

2026-09-06 17:54:54作者：霍妲思

本文围绕 freeCodeCamp 课程体系（Responsive Web Design 课程中的 basic-css 模块）中题为 "Inherit Styles from the Body Element" 的交互式挑战展开，讲解 CSS 继承机制的核心思想——通过 body 元素一次性为整页设置 color 与 font-family，并逐条拆解该挑战的官方测试断言、种子代码与参考解法，帮助你既掌握 CSS 继承的实战写法，又理解 freeCodeCamp 如何用自动化测试验证学习成果。

课程定位：这道挑战在 freeCodeCamp 课表中的位置

该挑战的源文件位于 bad87fee1348bd9aedf08746.md，其 front matter 声明了挑战元数据：

---
id: bad87fee1348bd9aedf08746
title: Inherit Styles from the Body Element
challengeType: 0
dashedName: inherit-styles-from-the-body-element
---

从 basic-css.json 的 challengeOrder 数组可以看出，basic-css 是 responsive-web-design 大课程下的第二个模块（第一个是 basic-html-and-html5）。"Inherit Styles from the Body Element" 排在第 26 位，紧接在 "Style the HTML Body Element"（bad87fee1348bd9aedf08736）之后、"Prioritize One Style Over Another"（bad87fee1348bd9aedf08756）之前。

这个排序本身就有教学逻辑：

前一步（Style the HTML Body Element）要求你给 body 写 background-color: black;，用黑底证明"每个 HTML 页面都有 body 元素"；
本步则在此基础上引入 CSS 继承（inheritance）的概念：既然 body 是页面内容的公共容器，那么写在 body 上的一些样式（如 color、font-family）会被页面上的其他元素自动继承；
后续步骤（Prioritize One Style Over Another、Override Styles in Subsequent CSS 等）则进入样式优先级（specificity / 覆盖）的专题。

因此，本文的挑战正是从"给 body 上色"迈向"用 body 统领全页文字样式"的关键一关。

核心概念：为什么样式可以写在 body 上

挑战的 description 部分给出了一段承上启下的讲解：

Now we've proven that every HTML page has a body element, and that its body element can also be styled with CSS. Remember, you can style your body element just like any other HTML element, and all your other elements will inherit your body element's styles.

（我们已经证明每个 HTML 页面都有一个 body 元素，且它可以像其他元素一样用 CSS 设置样式。请记住：你可以像样式化任何 HTML 元素一样样式化 body，而页面上的其他元素都会继承 body 的样式。）

这里涉及 CSS 继承机制的两个要点：

body 是页面内容的根容器。从 DOM 结构看，<head> 与 <body> 是 <html> 的两个子元素，所有可见内容都渲染在 body 内部，因此 body 天然适合承担"全站默认样式"的角色；
color 与 font-family 属于可继承属性。当你只声明 body { color: green; } 而没有为 h1 单独指定颜色时，h1 计算后的颜色就是 green；font-family 同理。这正是"一次声明、全页生效"的继承写法，比给每个元素逐个写 color / font-family 更符合 DRY 原则。

本挑战正是用两个可继承属性（color: green 和 font-family: monospace）让你亲身体验这一机制。

挑战任务与初始代码

挑战的 instructions 给出了三步任务：

创建一个文本为 Hello World 的 h1 元素；
向 body 元素的样式声明中加入 color: green;，让页面上所有元素都变成绿色；
向 body 元素的样式声明中加入 font-family: monospace;，让页面使用等宽字体。

你在编辑器里看到的初始（seed）代码如下：

<style>
  body {
    background-color: black;
  }

</style>

可以看到 seed 只保留了上一步设置的黑色背景，h1 尚未创建，color 与 font-family 也尚未声明。此时运行测试套件应当失败——这一点是 freeCodeCamp 课程测试框架的硬性约定，下文"测试框架"一节会展开。

参考解法：完整可运行的代码

挑战文件内 # --solutions-- 小节给出了官方参考解法：

<style>
  body {
    background-color: black;
    font-family: monospace;
    color: green;
  }

</style>
<h1>Hello World!</h1>

对照任务逐条核对：

body { background-color: black; } 从 seed 原样保留，黑色背景继续生效；
新增的 color: green 与 font-family: monospace 写在同一个 body 规则里，声明顺序不影响结果（这两条作用于不同属性）；
<h1>Hello World!</h1> 是唯一的页面内容，它不声明任何自身颜色或字体，因此两者都从 body 继承。

这里有一个值得注意的细节：monospace 是 CSS 的通用字体族关键字（generic family），浏览器会映射到系统内的等宽字体（如 Consolas、Menlo 或 Courier New 等），而不是特指某一款字体。这与前面 "Set the Font Family of an Element" 等挑战中使用的具体字体名（配合字体降级栈）形成对照，本关刻意使用关键字来聚焦"继承"本身而非"字体选型"。

官方测试断言逐条解析

# --hints-- 小节包含 7 条测试，它们既是学习检查点，也是理解"继承是否真实发生"的最好证据。按出现顺序解析：

1. 必须存在 h1 元素

assert.isNotEmpty(document.querySelectorAll('h1'));

用 document.querySelectorAll('h1') 查询页面中所有 h1，断言结果集合非空。querySelectorAll 与单数的 querySelector（只取第一个）不同，它返回全部匹配项，适合"至少存在一个"这类存在性检查。

2. h1 的文本必须是 "Hello World"

assert.match(
  document.querySelector('h1').textContent,
  /hello world/i
);

textContent 只取元素的文本内容（不含标签），配合 /i 忽略大小写的正则 /hello world/i。这意味着 Hello World、hello world 甚至 Hello World!（正则做的是"包含匹配"而非全等）都能通过——所以参考解法写作 Hello World! 也是合法的。

3. h1 必须成对出现开始与结束标签

const commentlessCode = __helpers.removeHtmlComments(code);
assert.match(commentlessCode, /<\/h1>/g);
assert.match(commentlessCode, /<h1/g);
assert.lengthOf(commentlessCode.match(/<\/h1>/g), commentlessCode.match(/<h1/g).length);

这条测试有意思：它不是在检查渲染结果，而是检查源码文本（code 变量即你在编辑器中写出的原始 HTML）。__helpers.removeHtmlComments(code) 先剔除 HTML 注释，防止学习者用注释"骗过"测试；然后分别用 /<\/h1>/g 与 /<h1/g 统计结束标签和开始标签的数量，并断言两者相等。这对应了 HTML 学习阶段反复强调的规范：元素必须闭合。

4. body 的 color 必须为 green

const bodyElement = document.querySelector('body');
const color = window.getComputedStyle(bodyElement)['color'];
assert.strictEqual(color, 'rgb(0, 128, 0)');

关键点在于 window.getComputedStyle()：它返回元素**计算后（computed）**的样式值，而非你写下的原始文本。CSS 关键字 green 会被浏览器解析为 rgb(0, 128, 0)——注意这不是 rgb(0, 255, 0)（那是亮绿 lime），CSS 标准色表里 green 对应的正是 0-128-0。断言用 strictEqual 做精确比较，验证的是"body 上的声明确实生效了"。

5. body 的 font-family 必须包含 monospace

const fontFamily = window.getComputedStyle(bodyElement)['font-family'];
assert.include(fontFamily.toLowerCase(), "monospace");

字体族是一个列表，浏览器可能按原样返回字符串（如 monospace），断言采用 assert.include 做"包含"检查并统一转小写，比全等比较更宽容，也覆盖了字体列表的常见形态。

6 与 7. h1 必须"继承"到 font 与 color

const h1Element = document.querySelector('h1');
const fontFamily = window.getComputedStyle(h1Element)['font-family'];
assert.include(fontFamily.toLowerCase(), "monospace");

const color = window.getComputedStyle(h1Element)['color'];
assert.strictEqual(color, 'rgb(0, 128, 0)');

这两条是本挑战的题眼。它们的写法与第 4、5 条几乎相同，差别只在查询对象从 body 换成了 h1。由于你在代码里从未给 h1 写过任何 color 或 font-family 声明，getComputedStyle(h1) 仍能取到 monospace 和 rgb(0, 128, 0)，唯一的可能来源就是 CSS 继承——测试框架用"检查后代而非祖先"的方式，把"继承发生了"这一抽象概念变成了可验证的事实。

从源码看：挑战文件是如何被编译与验证的

理解测试断言之后，再往仓库里看一层：这个 Markdown 挑战文件是如何变成"初始必挂、解法必过"的可执行测试的。

第一步：结构校验。 challenge-schema.js 用 Joi 定义了挑战数据模型。对本挑战相关的字段可以确认：challengeType: Joi.number().min(0).max(33).required()（本挑战的 challengeType: 0 合法）；tests 是必填数组，每项至少包含 text 与 testString（即上面 7 段断言对应的测试代码）；solutions 为"数组的数组"，表示一个挑战可以有多个等价解法。front matter 中的 id、dashedName 等字段也都在该 schema 中受到约束（例如 dashedName: Joi.string().regex(slugRE)，其中 slugRE = /^[a-z0-9-]+$/，与 inherit-styles-from-the-body-element 这种 kebab-case 命名对应）。

第二步：行为校验。 课程测试入口在 test-challenges.js，其中的核心约定与源码注释可以确认：

Test suite must fail on the initial contents：把挑战的 seed 代码放进测试运行器执行，断言测试套件必须失败（expect(fails).toBe(true)）——保证初始代码没有"送分"；
Solution N must pass the tests：把 --solutions-- 中的解法代码替换进 challengeFiles 后重跑，要求全部断言通过；
若无显式解法，框架会取"下一个挑战的 seed"作为解法（源码注释说明这主要出现在项目制课程中，本挑战有显式解法，不走此分支）。

第三步：在真实浏览器中执行。 从源码结构看，测试通过 Puppeteer 打开本地静态服务页面（http://127.0.0.1:8080/index.html），用 page.evaluate 在页面上下文调用 window.FCCTestRunner.getRunner(type).runAllTests(testStrings, timeout) 逐条执行断言。这正是为什么断言里能直接使用 document 和 window.getComputedStyle——它们运行在真实的 DOM 环境里，而非模拟环境。换句话说，你写下的 color: green 是否真的继承给了 h1，由浏览器引擎说了算，测试只是把它读出来比对。

延伸：本关之后学什么

沿着 basic-css.json 的 challengeOrder 继续，后续挑战自然延伸出三条支线：

样式优先级：紧接着的 "Prioritize One Style Over Another"、"Override Styles in Subsequent CSS"、"Override Class Declarations by Styling ID Attributes"、"Override All Other Styles by using Important" 等，探讨当 body 继承值、类选择器值与 !important 冲突时谁胜出——理解继承是理解 specificity 的前提；
颜色表示法：本关用关键字 green，而后面的 "Use Hex Code for Specific Colors"（#00FF00）、"Use RGB values to Color Elements"（rgb(...)）会教你同一颜色的多种写法。注意测试断言中出现的 rgb(0, 128, 0) 恰好是关键字 green 的 RGB 形式，三个关卡在颜色知识上首尾呼应；
CSS 变量：模块尾部的 "Use CSS Variables to change several elements at once" 等挑战，用 -- 自定义变量实现更灵活的"一处修改、全局生效"，可视为"body 继承"思想的进阶形态。

小结

本挑战体量虽小，却完整覆盖了 CSS 继承的关键链路：

写法：在 body { } 中同时声明 color: green 与 font-family: monospace，页面唯一的 h1 不写任何自身声明；
机制：color、font-family 作为可继承属性，由浏览器沿 DOM 树从 body 传递到 h1；
验证：官方 7 条断言既检查 body 上的声明（rgb(0, 128, 0)、monospace），也检查 h1 上"没写却算出来"的值，并用源码级断言确保 h1 标签规范闭合；
工程背景：挑战文件由 Joi schema 做结构校验（challenge-schema.js），再由测试框架保证"seed 必挂、解法必过"（test-challenges.js），在真实浏览器环境里执行断言。