To answer this question, we can obtain answers from these sources:
- W3C Specification
- WebKit Source Code
- Chromium Source Code
W3C Specification
To be precise, W3C doesn’t organize tests by itself; it directly utilizes the work from WPT (WebPlatformTests) organization, though from the code, this organization appears to have originated from the HTML Group.
WPT is an organization dedicated to providing cross-browser web technology stack test cases. Currently, this organization has accumulated numerous test cases, all stored in the github/wpt repository. Their tests come in various types, among which Rendering Test is most closely related to CSS. These tests are located in the css directory.
Additionally, W3C associates these test cases with corresponding chapters according to its own specification sections. These tests can be viewed in the CSS Test Harness.
WebKit’s Approach
CSS-related tests are concentrated in these directories:
Furthermore, WebKit also adopts some tests from WPT, with specific methods mentioned in WebKitW3CTesting. These files are stored in the LayoutTest/imported/w3c directory.
Chromium’s Approach
Chromium’s approach is to establish mechanisms that can utilize WPT’s work results. Maintainers can import tests from WPT, and after adding their own tests, they can create PRs in the upstream WPT repository. (See Import and Export).
The imported files are located here.
Deep Dive into Test Cases Under W3C Specification
Test cases are concentrated in the css directory, which contains all CSS-related test cases from CSSWG. Several folders in this directory need attention:
- support: Global support files, including images and stylesheets; other tests’ internal support files are stored in their own folders’ support directory
- vendor-imports: Some tests from old W3C standards, likely from the Mozilla era
- tools: Mainly for building CSS test cases and a Python HTTP library for test case construction, though not necessary for CSS; unclear why it’s placed here
Apart from these three folders, each other folder corresponds to a CSS-related draft from W3C, with specific correspondences viewable in the META.yml file within each folder.
So how is each test case composed internally?
First, we need to understand that a test case can generally be categorized into these types (divided based on how their correctness is determined):
- Rendering test
- Reftest: Provides another HTML file in the test file that doesn’t use the current technology, then determines if the rendering results of both files are identical
- Visual test: Determined through human visual inspection or comparison with previous screenshots; such tests usually have “-visual” added to the end of their filename (before the extension)
- JS test: Uses their own library called javascriptharness to determine result correctness
However, these two types of tests are fundamentally similar in form. According to Writing a refset, we can understand their structure. Let’s look at a typical test file:
<!DOCTYPE html>
<meta charset="utf-8">
<title>BDO element dir=rtl</title>
<link rel="help" href="<https://html.spec.whatwg.org/#the-bdo-element>">
<link rel="match" href="rtl-ref.html">
<meta name="assert" content="BDO element's DIR content attribute renders corrently given value of 'rtl'.">
<p>Test passes if WAS is displayed below.</p>
<bdo dir="rtl">SAW</bdo>
This file mainly consists of these parts:
- title: Self-explanatory
- link help: Indicates the corresponding test case
- link match: Another file for comparison
- meta assert: Shows the prompt when an error occurs
- Test content: Generally required to be self-explanatory
Explanation of Flags in Tests
Ahem
Ahem is a font specifically designed for browser testing, characterized by specific characters having specific shapes. Detailed explanations can be found in the README of GitHub - Kozea/Ahem: A dummy font often used in W3C tests.
Any test marked with Ahem requires the Ahem font for correct display. Therefore, before viewing the test execution process, you need to first download and install the font file from Github (on macOS, simply opening the ttf file is sufficient)