Test Format

This page describes the test format. The requirements are explained below; to make things easier we've also provided a template that you can copy.

Additional guidelines on designing the content of the test can be found in the CSS2.1 Test Case Authoring Guidelines.

Template for New Tests

The submission format for CSS2.1 tests is XHTML in UTF-8. Images must be in PNG format. A set of scripts will generate the various formats from this source version. Tests must be valid XHTML, so please validate your tests before submission.

A template for new tests follows. Copy and paste the code below into a new file or save this template file and replace the capitalized parts as described below.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
 <head>
  <title>CSS Test: DESCRIPTION OF TEST</title>
  <link rel="author" title="NAME_OF_AUTHOR" href="mailto:EMAIL OR http://CONTACT_PAGE"/>
  <link rel="help" href="RELEVANT_SPEC_SECTION"/>
  <meta name="flags" content="TOKENS" />
  <meta name="assert" content="TEST ASSERTION"/>
  <style type="text/css"><![CDATA[
   CSS FOR TEST
  ]]></style>
 </head>
 <body>
  CONTENT OF TEST
 </body>
</html>

Template Details

Title element

<title>CSS Test: DESCRIPTION OF TEST</title>

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.

Bad example:

<title>CSS Test: Border Conflict Resolution</title>

We have 100+ tests on “Border Conflict Resolution”.

Good example:

<title>CSS Test: Border Conflict Resolution (width) - hidden/double</title>

Credits

<link rel="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.

Example 1:

<link rel="author" title="Boris Zbarsky" href="mailto:bzbarsky@mit.edu" />

Example 2:

<link rel="author" title="Bert Bos" href="http://www.w3.org/People/Bos/" />

Example 3:

<link rel="author" title="Microsoft" href="http://microsoft.com/" />

Reviewer

<link rel="reviewer" title="NAME_OF_REVIEWER" href="mailto:EMAIL OR http://CONTACT_PAGE" /> <!-- YYYY-MM-DD -->

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.

Example 1:

<link rel="reviewer" title="Boris Zbarsky" href="mailto:bzbarsky@mit.edu" /> <!-- 2008-02-19 -->

Example 2:

<link rel="reviewer" title="Bert Bos" href="http://www.w3.org/People/Bos/" /> <!-- 2005-05-03 -->

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.

Example of a fully-reviewed test:

<link rel="author" title="Bert Bos" href="http://www.w3.org/People/Bos/" />
<link rel="reviewer author" title="Boris Zbarsky" href="mailto:bzbarsky@mit.edu" /> <!-- 2008-02-19 -->
<link rel="reviewer" title="Bert Bos" href="http://www.w3.org/People/Bos/" /> <!-- 2008-04-22 -->

This test was written by Bert Bos, then reviewed by Boris Zbarsky, who made some corrections before deeming it acceptable. Those corrections were then reviewed and accepted by Bert Bos.

Specification Links

<link rel="help" href="RELEVANT_SPEC_SECTION" />

The specification link elements provide a way to align test with information in the CSS 2.1 specification.

  • Links should link to relevant sections within the CSS 2.1 Specification
  • Use the anchors from the CSS 2.1 Specification Table of Contents
  • A test can have multiple specification links
    • Always list the primary section that is being tested as the first item in the list of specification links
    • Order the list from the most used/specific to least used/specific
    • There is no need to list common incidental features like the color green if it is being used to validate the test unless the case is specifically testing the color green
  • If the test is part of multiple test suites, link to the relevant sections of each spec.
Example 1:

<link rel="help" href="http://www.w3.org/TR/CSS21/text.html#alignment-prop" />

Example 2:

<link rel="help" href="http://www.w3.org/TR/CSS21/text.html#alignment-prop" />
<link rel="help" href="http://www.w3.org/TR/CSS21/visudet.html#q7" />
<link rel="help" href="http://www.w3.org/TR/CSS21/visudet.html#line-height" />
<link rel="help" href="http://www.w3.org/TR/CSS21/colors.html#background-properties" />

Requirement Flags

<meta name="flags" content="TOKENS" />

Flags document the test’s prerequisites, for example, the Ahem font, or a paged presentation. Multiple tokens are space separated.

All flags documented elsewhere are deprecated except the following:

Token Description
ahem Requires the Ahem font
dom Requires support for JavaScript and the Document Object Model (DOM)
font Requires a specific font to be installed. (Details must be provided and/or the font linked to in the test description)
history User agent session history is required. Testing :visited is a good example where this may be used.
http Requires HTTP headers
HTMLonly Test case is only valid for HTML
image Requires support for bitmap graphics and the graphic to load
interact Requires human interaction (such as for testing scrolling behavior)
invalid Tests handling of invalid CSS. Note: This case contains CSS properties and syntax that may not validate.
namespace Requires support for XML Namespaces
nonHTML Test case is only valid for formats besides HTML (e.g. XHTML or arbitrary XML)
may Behavior tested is preferred but OPTIONAL. [RFC2119] (These tests must be reviewed by a test suite owner or peer.)
paged Only valid for paged media
should Behavior tested is RECOMMENDED, but not REQUIRED. [RFC2119]
scroll Only valid for continuous (scrolling) media
svg Requires support for vector graphics (SVG)
96dpi Assumes 96dpi display
Example 1 (one token applies):

<meta name="flags" content="invalid" />

Example 2 (multiple tokens apply):

<meta name="flags" content="ahem scroll image" />

Example 3 (no tokens apply):

<meta name="flags" content="" />

Test Assertions

<meta name="assert" content="TEST ASSERTION" />

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).

Style Element (embedded styles)

<style type="text/css"><![CDATA[
   CSS FOR TEST
  ]]></style>

When creating styles primarily use ID or Class selectors. Inline styles should not be used unless the case is specifically testing this scenario.

Script type (embedded script)

<script type="text/javascript"><![CDATA[
   ... Javascript code here ...
  ]]></script>

Some testcases require support for javascript and the Document Object Model (DOM).

Although type=“application/javascript” and type=“application/ecmascript” are recommended by [RFC4329], the CSS 2.1 test suite only accepts type=“text/javascript”.

''body'' Content

<body>
 CONTENT OF TEST
</body>
  • When creating content use : <div>, <span>, <p>, <img>
    • Beware! <p> has margins by default!
  • Use other elements only to test the interaction with those elements' features (or other namespaces' features)
  • Test table features with both HTML table elements and <div> + display: table-*
  • Do not use the style attribute (inline styles) unless specifically testing that attribute
  • Avoid making assumptions that are not in the "most of the test suite makes the following assumptions" list and document any that you do.
  • It's helpful to people trying to understand the test if you use meaningful class and ID names and escape invisible characters like no-break-spaces.
  • Indent nicely!

Filename format

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

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

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

Examples:
margin-collapsing-###.ext
border-solid-###.ext
float-clear-###.ext

###
This is a zero-filled number used to keep the filenames unique when files have the same 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. There may also be a letter affixed after the number, which can be used to indicate variants of a test.

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.

ext
The file extension or format of the file.

Support files

A number of standard images are provided in the support directory. These include

  • 1×1 color swatches
  • 15×15 color swatches
  • 15×15 bordered color swatches
  • assorted rulers and red/green grids
  • a cat
  • a 4-part picture

Additional generic files can be added as necessary, and should have a descriptive filename. 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.

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.

<Files ~ "^lang-selector-005\.(xht|xhtml|xml|html|htm)$">
AddLanguage fr .xht .xhtml .xml .html .htm
</Files>

Please flag tests that require HTTP interaction with the http flag so people running the tests locally know their results will not be valid.

 
test/css2.1/format.txt · Last modified: 2010/07/06 14:09 by fantasai
Recent changes RSS feed Valid XHTML 1.0 Valid CSS Driven by DokuWiki