no way to compare when less than two revisions

Differences

This shows you the differences between two versions of the page.

@@ Line 1: / Line 1: @@
+====== Test Format ======
+This page describes the standard test format for CSSWG [[test:selftest|self-describing tests]] and [[test:reftest|reftests]]. 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 [[selftest|self-describing]] [[reftest|reftest]]. If it's possible for a test to be a [[reftest|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.)
+===== Design Requirements =====
+The following are requested of all tests submitted to the CSSWG, both for [[test:reftest|reftests]] and [[test:selftest|self-describing tests]]:
+  ; Short
+  : 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.
+  ; Valid
+  : Unless specifically testing error-recovery features, the tests should all be valid. Inconsistencies in e.g. HTML parsing shouldn't be affecting CSS test suite pass rates.
+  ; Cross-platform
+  : 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 XHTML in UTF-8. HTML is also acceptable; however note that the test source will be parsed and reserialized.
+Images must be in PNG format.
+A set of scripts will generate the various formats (XHTML, HTML, XHTML for Printers) from this source version.
+Tests must be //valid// XHTML, so please [[http://validator.w3.org/|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.
+===== Template for New Tests =====
+A template for new tests follows. Copy and paste the code below into a new file or save {{test:css2.1:test-topic-000.xht|this template file}} and replace the capitalized parts as described below.
+<code html>
+<!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>
+</code>
+===== Template Details =====
+==== Title element ====
+<code html>
+<title>CSS Test: DESCRIPTION OF TEST</title>
+</code>
+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.
+<note example>
+Bad example:
+<code html>
+<title>CSS Test: Border Conflict Resolution</title>
+</code>
+We have 100+ tests on "Border Conflict Resolution".
+Good example:
+<code html>
+<title>CSS Test: Border Conflict Resolution (width) - hidden/double</title>
+</code>
+</note>
+==== Credits ====
+<code html>
+<link rel="author" title="NAME_OF_AUTHOR" href="mailto:EMAIL OR http://CONTACT_PAGE" />
+</code>
+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.
+<note example>
+Example 1:
+<code html>
+<link rel="author" title="Boris Zbarsky" href="mailto:bzbarsky@mit.edu" />
+</code>
+Example 2:
+<code html>
+<link rel="author" title="Bert Bos" href="http://www.w3.org/People/Bos/" />
+</code>
+Example 3:
+<code html>
+<link rel="author" title="Microsoft" href="http://microsoft.com/" />
+</code>
+</note>
+==== Reviewer ====
+<code html>
+<link rel="reviewer" title="NAME_OF_REVIEWER" href="mailto:EMAIL OR http://CONTACT_PAGE" /> <!-- YYYY-MM-DD -->
+</code>
+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.
+<note example>
+Example 1:
+<code html>
+<link rel="reviewer" title="Boris Zbarsky" href="mailto:bzbarsky@mit.edu" /> <!-- 2008-02-19 -->
+</code>
+Example 2:
+<code html>
+<link rel="reviewer" title="Bert Bos" href="http://www.w3.org/People/Bos/" /> <!-- 2005-05-03 -->
+</code>
+</note>
+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.
+<note example>
+Example of a fully-reviewed test:
+<code html>
+<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 -->
+</code>
+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.
+</note>
+==== Specification Links ====
+<code html>
+<link rel="help" href="RELEVANT_SPEC_SECTION" />
+</code>
+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 [[http://www.w3.org/TR/CSS21/#toc|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.
+<note example>
+Example 1:
+<code html>
+<link rel="help" href="http://www.w3.org/TR/CSS21/text.html#alignment-prop" />
+</code>
+Example 2:
+<code html>
+<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" />
+</code>
+</note>
+==== Reference Links ====
+<code html>
+<link rel="match" href="RELATIVE_PATH_TO_REFERENCE_FILE" />
+<link rel="mismatch" href="RELATIVE_PATH_TO_REFERENCE_FILE" />
+</code>
+The reference link elements are used in [[.:css2.1:test:reftest|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.
+  * Reference files may be dedicated reference files, images, or other tests
+<note example>
+Example 1:
+<code html>
+<link rel="match" href="green-box-ref.xht" />
+</code>
+Example 2:
+<code html>
+<link rel="match" href="green-box-ref.xht" />
+<link rel="match" href="blue-box-ref.xht" />
+<link rel="mismatch" href="red-box-notref.xht" />
+<link rel="mismatch" href="red-box-notref.xht" />
+</code>
+</note>
+==== Requirement Flags ====
+<code html>
+<meta name="flags" content="TOKENS" />
+</code>
+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 [[http://www.w3.org/Style/CSS/Test/Ahem/|Ahem font]] |
+|  animated  | Test is animated in final state. (Cannot be verified using reftests/screenshots.) |
+|  combo  | Test, which must have an unsuffixed filename number, is strictly the union of all the suffixed tests with the same name and number. (See File name format, below.) |
+|  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. %%[%%[[http://www.ietf.org/rfc/rfc2119.txt|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. %%[%%[[http://www.ietf.org/rfc/rfc2119.txt|RFC2119]]] |
+|  scroll  | Only valid for continuous (scrolling) media |
+|  svg  | Requires support for vector graphics (SVG) |
+|  userstyle  | Requires a user style sheet to be set |
+|  32bit  | Assumes a 32-bit integer as the minimum (-2147483648) or maximum (2147483647) value |
+|  96dpi  | Assumes 96dpi display |
+<note example>
+Example 1 (one token applies):
+<code html>
+<meta name="flags" content="invalid" />
+</code>
+Example 2 (multiple tokens apply):
+<code html>
+<meta name="flags" content="ahem scroll image" />
+</code>
+Example 3 (no tokens apply):
+<code html>
+<meta name="flags" content="" />
+</code>
+</note>
+==== Test Assertions ====
+<code html>
+<meta name="assert" content="TEST ASSERTION" />
+</code>
+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).
+<note>
+Examples of good test assertions:
+  * "A background image with no intrinsic size covers the entire padding box."
+  * "Word-spacing affects each space (U+0020) and non-breaking space (U+00A0)."
+  * "If 'top' and 'bottom' are specified on an absolutely-positioned replaced element, then any remaining space is split amongst the 'auto' vertical margins."
+  * "text-indent affects only the first line of a block container if that line is also the first formatted line of an element
+</note>
+==== Style Element (embedded styles) ====
+<code html>
+<style type="text/css"><![CDATA[
+   CSS FOR TEST
+  ]]></style>
+</code>
+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) ====
+<code html>
+<script type="text/javascript"><![CDATA[
+   ... Javascript code here ...
+  ]]></script>
+</code>
+Some testcases require support for javascript and the Document Object Model (DOM).
+Although type="application/javascript" and type="application/ecmascript" are recommended by %%[%%[[http://www.ietf.org/rfc/rfc4329.txt|RFC4329]]], the CSS 2.1 test suite only accepts type="text/javascript".
+==== ''body'' Content ====
+<code html>
+<body>
+ CONTENT OF TEST
+</body>
+</code>
+  * 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 [[http://www.w3.org/Style/CSS/Test/CSS2.1/current/|"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!
+Guidelines on designing the content of the test can be found in the [[http://www.w3.org/Style/CSS/Test/guidelines.html|CSS2.1 Test Case Authoring Guidelines]].
+===== 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.
+**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.
+<note example>
+Examples:\\
+''margin-collapsing-###.ext\\
+border-solid-###.ext\\
+float-clear-###.ext''
+</note>
+**###**\\
+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.
+<note example>
+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''
+</note>
+There may also be a letter affixed after the number, which can be used to indicate variants of a test.
+<note example>
+For example, ''float-wrap-001l.xht'' and ''float-wrap-001r.xht'' might be left and right variants of a float test.
+</note>
+If tests using both the unsuffixed number and the suffixed number exist, the suffixed tests must be subsets of the unsuffixed test.
+<note example>
+For example, if ''bidi-004'' and ''bidi-004a'' both exist, ''bidi-004a'' must be a subset of ''bidi-004''.
+</note>
+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.
+<note example>
+ If ''bidi-004a'' and ''bidi-004b'' cover all aspects of ''bidi-004'' (except their interaction), then ''bidi-004'' should be given the ''combo'' flag.
+</note>
+**ext**\\
+The file extension or format of the file, usually ''.xht'' for test files.
+===== Support files =====
+A number of standard images are provided in the [[http://www.w3.org/Style/CSS/Test/CSS2.1/current/xhtml1/support/|support directory]]. These include
+  * 1x1 color swatches
+  * 15x15 color swatches
+  * 15x15 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 file name. 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.
+<code css>
+#user-stylesheet-indication
+{
+    /* Used by the harness to display and indication there is a user style sheet applied */
+    display: block!important;
+}
+</code>
+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.
+<note example>
+Harness style sheet rules:
+<code css>
+#userstyle
+{
+    color: green;
+    display: none;
+}
+#nouserstyle
+{
+    color: red;
+    display: none;
+}
+</code>
+Harness ''userstyle'' flag found:
+<code html>
+<p id="user-stylesheet-indication" class="userstyle">A user style sheet is applied.</p>
+</code>
+Harness ''userstyle'' flag NOT found:
+<code html>
+<p id="user-stylesheet-indication" class="nouserstyle">A user style sheet is applied.</p>
+</code>
+</note>
+Within the test case it is recommended that the case itself indicate the necessary user style sheet that is required.
+<note example>
+Examples:  (code for the cascade.css file)
+<code css>
+#cascade /* ID name should match user style sheet file name */
+{
+    /* Used by the test to hide the prerequisite */
+    display: none;
+}
+</code>
+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)
+<code html>
+<p id="cascade">PREREQUISITE: The <a href="support/cascade.css">"cascade.css"</a> file is enabled as the user agent's user style sheet.</p>
+</code>
+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.
+</note>
+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.
+  <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.