Test Format

This page describes the standard test format for CSSWG self-describing tests, reftests and script tests. The requirements are explained below; to make things easier we've also provided a template that you can copy.

The recommended structure for CSS tests is a self-describingreftest. If it's possible for a test to be a reftest, it must be a reftest. (We prefer reftests to also be self-describing or otherwise easy for humans to interpret, but this is not a requirement). script tests should be used for scenarios such as testing a JS API or adding automation to a reftest.

Design Requirements

Tests should be very short and certainly not require scrolling on even the most modest of screens, unless the test is specifically for scrolling or paginating behaviour. This enables them to be run more easily on various testing platforms.

Tests should be as cross-platform as reasonably possible, working across different devices, screen resolutions, paper sizes, etc. Exceptions should document their assumptions.

Red Means Failure

Don't use the color red other than to indicate a failure. (Exception: testing for support of red) Since green-with-no-red is often used to indicate success, it's best to also avoid green unless using the presence of red to indicate failures.

Acceptable Test Formats

The preferred submission format for CSSWG tests is either XHTML or HTML5, in UTF-8. HTML < 5 is also acceptable, but it will be processed by an HTML5 compatible parser. SVG is also acceptable where necessary.

Note that in general, the test source will be parsed and re-serialized, even in its source format. The re-serialization will cause minor changes to the test file, notably: attribute values will always be quoted, whitespace between attributes will be collapsed to a single space, duplicate attributes will be removed, optional closing tags will be inserted, and invalid markup will be normalized. If these changes should make the test inoperable, for example if the test is testing markup error recovery, add the flag 'asis' to prevent re-serialization. This flag will also prevent format conversions so it may be necessary to provide alternate versions of the test in other formats (XHTML, HTML, etc.)

Images must be in either PNG or SVG format. (PNG is preferred where raster images can be used.)

A set of scripts will generate the various formats (XHTML, HTML, XHTML for Printers) from this source version.

Tests must be valid, so please validate your tests before submission. For tests that use the HTML style header, the validator may report errors on the flags and assert metadata. These specific errors can be ignored - this is a known issue and work is in progress to correct the problem.

When using any characters beyond the ASCII set, in any encoding, the character encoding must be specified properly per the specification of the source format.

If the test uses the Ahem font, make sure its computed font-size is a multiple of 5px, otherwise baseline alignment may be rendered inconsistently (due to rounding errors introduced by certain platforms' font APIs). We suggest to use a minimum computed font-size of 20px.

If the test uses the Ahem font, make sure the line-height on block elements is specified; avoid 'line-height: normal'. Also, for absolute reliability, the difference between computed line-height and computed font-size should be dividable by 2.

Template Details

Title element

The title appears in the generated index, so make sure it is concise, unique and descriptive. The role of the title is to identify what specific detail of a feature or combination of features is being tested, so that someone looking through an index can see quickly what's tested in which file. In most cases, this description should not require more than 5 or 6 words. There is no need to provide the chapter or section in the title.

For specifications other than CSS 2.1, you can include the module name somewhere before the colon, like “CSS Selectors Test:” or “CSS Test (Selectors):”. Do not include the module version number, since the test might get reused for the next version.

Credits

<linkrel="author"title="NAME_OF_AUTHOR"href="mailto:EMAIL OR http://CONTACT_PAGE"/>

Credits provide a way to identify the person or organization that created the test and/or holds copyright in the test. This is useful for reviewing purposes and for asking questions about the individual test. A test can have multiple author credits if necessary.

Reviewer

If a test has passed review, then the reviewer should note this by adding his or her name as a reviewer, along with the date of the review. A test can have multiple reviewers if necessary. A reviewer must be a person, not an organization.

If a test would pass review with some (non-metadata) changes and the reviewer chooses to make these changes, then the reviewer should add his or her name as a reviewer-author, along with the date of the review, when checking in those changes. This indicates that the reviewer-author approves of the original author's test when taken with these proposed changes, and that someone else (possibly the original author) must review the changes. The test is fully reviewed only when the latest reviewer did not also contribute changes to the test at the time of the review.

Reference Links

The reference link elements are used in reftests and provide the list of reference file(s) that the test should be compared to.

match references must be files that render identically to the test, but use an alternate means to do so

Multiple match references are used when the test can match any of the reference files

If a test requires multiple match references that all need to match (for example, to catch when a reference fails in the same way the test does), then chain the references together, i.e.: place reference links to the additional match references in the reference files. It is recommended that the chained reference files form a loop (e.g.: a → b → c → a) so that a test linking to any reference in the chain will find all the references.

mismatch references are files that render differently than the test file. A test may have any number of mismatch references. The test is considered to fail if it renders the same as any of the mismatch references.

Note that reference files may themselves have mismatch references. In that case the reference file must not render the same as any of its mismatch references in order to be considered valid. If a reference is considered invalid (by the fact of not matching any of its match references, or matching any of its mismatch references), then a test that refers to the reference will be considered to have failed.

Reference files may be dedicated reference files, images, or other tests

Test Assertions

This element should contain a complete detailed statement expressing what specifically the test is attempting to prove. If the assertion is only valid in certain cases, those conditions should be described in the statement.

The assertion should not be:

A copy of the title text

A copy of the test verification instructions

A duplicate of another assertion in the test suite

A line or reference from the CSS specification unless that line is a complete assertion when taken out of context.

The test assertion is optional. It helps the reviewer understand the goal of the test so that he or she can make sure it is being tested correctly. Also, in case a problem is found with the test later, the testing method (e.g. using 'color' to determine pass/fail) can be changed (e.g. to using 'background-color') while preserving the intent of the test (e.g. testing support for ID selectors).

Examples of good test assertions:

“This test checks that a background image with no intrinsic size covers the entire padding box.”

Style Element (embedded styles)

When creating styles primarily use type, ID or Class selectors. Inline styles should not be used unless the case is specifically testing this scenario. Other selector types should also be avoided unless specifically testing those scenarios.

File name format

The new file name format is test-topic-###.ext where test-topic somewhat describes the test and
### is a zero-filled number used to keep the file names unique.

The file name is no longer restricted to 31 characters, but please try to keep them short.

The file name should not use the underscore (“_”) character; please use the hyphen (“-”) character instead.

test-topic
A short identifier that describes the test. The test-topic should avoid
conjunctions, articles, and prepositions. It is a file name, not an English phrase: it should be as
concise as possible.

###
This is a zero-filled number used to keep the file names unique when files have the same test-topic name.

Note: The number format is limited to 999 cases. If you go over this number it is recommended that you reevaluate your test-topic name.

For example, in the case of margin-collapsing there are multiple cases so each case could have the same test-topic but different numbers.margin-collapsing-001.xht
margin-collapsing-002.xht
margin-collapsing-003.xht

There may also be a letter affixed after the number, which can be used to indicate variants of a test.

For example, float-wrap-001l.xht and float-wrap-001r.xht might be left and right variants of a float test.

If tests using both the unsuffixed number and the suffixed number exist, the suffixed tests must be subsets of the unsuffixed test.

For example, if bidi-004 and bidi-004a both exist, bidi-004a must be a subset of bidi-004.

If the unsuffixed test is strictly the union of the suffixed tests, i.e. covers all aspects of the suffixed tests (such that a user agent passing the unsuffixed test will, by design, pass all the suffixed tests), then the unsuffixed test should be marked with the combo flag.

If bidi-004a and bidi-004b cover all aspects of bidi-004 (except their interaction), then bidi-004 should be given the combo flag.

ext
The file extension or format of the file, usually .xht for test files.

Additional generic files can be added as necessary, and should have a descriptive file name. Just like other file name, support files' file name should not use the underscore (“_”) character; use the hyphen (“-”) character instead. Test-specific files should be named after the test (or test-topic if they are shared across several tests within a series). If possible tests should not rely on transparency in images, as they are converted to JPEG (which does not support transparency) for the xhtml1print version.

User style sheets

Some test may require special user style sheets to be applied in order for the case to be verified.

In order for proper indications and prerequisite to be displayed every user style sheet should contain the following rules.

#user-stylesheet-indication{/* Used by the harness to display and indication there is a user style sheet applied */display:block!important;}

The rule #user-stylesheet-indication is to be used by any harness running the test suite.

A harness should identify test that need a user style sheet by looking at their flags meta tag. It then should display appropriate messages indicating if a style sheet is applied or if a style sheet should not be applied.

Within the test case it is recommended that the case itself indicate the necessary user style sheet that is required.

Examples: (code for the cascade.css file)

#cascade/* ID name should match user style sheet file name */{/* Used by the test to hide the prerequisite */display:none;}

The rule #cascade in the example above is used by the test page to hid the prerequisite text. The rule name should match the user style sheet CSS file name in order to keep this orderly.

Examples: (code for the cascade-### XHTML files)

<pid="cascade">PREREQUISITE: The <ahref="support/cascade.css">"cascade.css"</a> file is enabled as the user agent's user style sheet.</p>

The id value should match the user style sheet CSS file name and the user style sheet rule that is used to hide this text when the style sheet is properly applied.

Please flag test that require user style sheets with the userstyle flag so people running the tests know that a user style sheet is required.

HTTP headers

Some tests may require special HTTP headers. These should be configured in a .htaccess file located in the same directory as the relevant file. An example configuration is shown below. Note that multiple file extensions are supported in the configuration so that exported formats are all handled correctly. The build scripts will concatenate all .htaccess files in the test sources' parent directories and support directories.