This is the HTML Working Group's test suite for HTML, Canvas, and Microdata (any version — 5.0, 5.1, LS, etc.). It is maintained by the HTML Test Suite Task Force, which for all that it has "Task Force" in its name is really a bunch of cool froods.
Tests are under
html (for the HTML specification),
canvas (for the
Canvas specification), and
microdata (Surprise test! Which specification
are these tests for?).
Inside the specification directories, the tree represents the sections of the
respective documents, using the section IDs for directory names, with a maximum
of three levels deep. So if you're looking for tests for "The History interface",
they will be under
Various resources that tests depend on are in
In order to function properly, tests need to be run from a web server that has
If you're looking at a section of the specification and can't figure out where the directory is for it in the tree, just run:
node tools/scripts/id2path.js your-id
In the vast majority of cases the only branch that you should need to care
There is another branch called
CR. This is a strict subset of
is limited to features that are found in the Candidate Recommendation version
of the relevant specifications.
If you see other branches in the repository, you can generally safely ignore
them. Please note that branches prefixed with
temp/ are temporary branches
and can get deleted at some point. So don't base any work off them unless
you want to see your work destroyed.
Save the Web, Write Some Tests!
Let's get the legalese out of the way:
All contributors must agree to the following W3C test licences:
We can accept tests contributed under compatible conditions, just contact us to ask about it.
Absolutely everyone is welcome (and even encouraged) to contribute to test development, so long as you fulfil the contribution requirements detailed above. No test is too small or too simple, especially if it corresponds to something for which you've noted an interoperability bug in a browser.
The way to contribute is just as usual:
- fork this repository (and make sure you're still relatively in sync with it if you forked a while ago);
- create a branch for your changes,
git checkout -b submission/your-name;
- make your changes;
- push that to your repo;
- and send in a pull request based on the above.
Please make your pull requests either to
master or to a feature branch
(but not to
We can sometimes take a little while to go through pull requests because we have to go through all the tests and ensure that they match the specification correctly. But we look at all of them, and take everything that we can.