| commit | 9f736c52d047ed380482647728ed23e8f2db7179 | [log] [tgz] |
|---|---|---|
| author | Gordon P. Hemsley <me@gphemsley.org> | Tue Oct 11 00:39:35 2022 |
| committer | GitHub <noreply@github.com> | Tue Oct 11 00:39:35 2022 |
| tree | b720d2b23248db73668a96b50f172a42bb2f9e62 | |
| parent | e7800ec06e11e5f9089aca87a907f08a40e09b9c [diff] |
Reorganize css-color parsing tests (#36353)
There seems to be a prevailing convention in how parsing tests are named: <property>-{valid,invalid,computed}.html.
But css-color parsing tests have generally not been using this convention, in part because the css-color family of specs are in a seemingly rare position where the bulk of the standard revolves around a single CSS property (color) and the breadth of variability is in the definition of a single <color> grammar definition used to determine its value.
In the infrequent instances where parsing tests elsewhere have been subdivided, there have not been strong conventions as to how. After some analysis, I've concluded that <property>-{valid,invalid,computed}-<feature>.html is the most logical extension, given the corresponding undivided convention. (With features named according to terms of the spec, using at-<name> for at-rules and <name>-function for functions.)
Additionally, because css-color was one of the earlier efforts under the banner of "CSS 3", there exist a standard (level 3) and a set of tests that predate comprehensive behavior documentation, as well as implementations. This is being rectified in level 4, which goes into much more detail. But level 4 has also added new functionality which has not yet been fully implemented. These factors combined have meant that, over the years, developers have continued to add their complex, feature-specific tests for level 4 on top of the simple and basic tests for level 3, clouding the waters around who has implemented what, whether implementations are complete, and whether test coverage is comprehensive.
It has also meant, in some cases, that entire separate tests have been created for simple, singular parsing questions.
To rectify all that, I have gone through and restructured and reorganized the existing tests.
I have renamed a number of existing files to match the new convention for features, and split out the level 3 tests from the level 4 tests. I have also carried this through for upcoming level 5 and level 6 features.
The web-platform-tests Project is a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.
The most important sources of information and activity are:
wpt:matrix.org matrix channel; includes participants located around the world, but busiest during the European working day.If you'd like clarification about anything, don't hesitate to ask in the chat room or on the mailing list.
Clone or otherwise get https://github.com/web-platform-tests/wpt.
Note: because of the frequent creation and deletion of branches in this repo, it is recommended to “prune” stale branches when fetching updates, i.e. use git pull --prune (or git fetch -p && git merge).
See the documentation website and in particular the system setup for running tests locally.
The wpt command provides a frontend to a variety of tools for working with and running web-platform-tests. Some of the most useful commands are:
wpt serve - For starting the wpt http serverwpt run - For running tests in a browserwpt lint - For running the lint against all testswpt manifest - For updating or generating a MANIFEST.json test manifestwpt install - For installing the latest release of a browser or webdriver server on the local machine.wpt serve-wave - For starting the wpt http server and the WAVE test runner. For more details on how to use the WAVE test runner see the documentation.On Windows wpt commands must be prefixed with python or the path to the python binary (if python is not in your %PATH%).
python wpt [command]
Alternatively, you may also use Bash on Ubuntu on Windows in the Windows 10 Anniversary Update build, then access your windows partition from there to launch wpt commands.
Please make sure git and your text editor do not automatically convert line endings, as it will cause lint errors. For git, please set git config core.autocrlf false in your working tree.
The master branch is automatically synced to wpt.live and w3c-test.org.
Save the Web, Write Some Tests!
Absolutely everyone is welcome to contribute to test development. 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:
git checkout -b topic../wpt lint as described above.If you spot an issue with a test and are not comfortable providing a pull request per above to fix it, please file a new issue. Thank you!