commit b779654ad9a87ce20450367a23ac2b8ec9103927
parent f3a022de2244eccfe9b719d89d7ef919892b69eb
Author: Jean-Philippe Gravel <jpgravel@chromium.org>
Date: Mon, 1 Dec 2025 07:22:47 +0000
Bug 2003098 [wpt PR 56344] - Fix math markup in WPT's canvas test generator readme, a=testonly
Automatic update from web-platform-tests
Fix math markup in WPT's canvas test generator readme
It appears that not all Markdown renderers like equations delimited with
simple dollar signs (see [1] and [2]). Maybe it's because the equations
contained `*`, which overlaps with the Markdown syntax. It seems that
Github works correctly when doing $`...`$.
[1]: https://github.com/web-platform-tests/wpt/blob/71154f49e6cdda82c43e11bb74cfe3ad7b3f9368/html/canvas/tools/README.md
[2]: https://chromium.googlesource.com/chromium/src.git/+/4a3174e778f45e7648ce37ada093017163a4254f/third_party/blink/web_tests/external/wpt/html/canvas/tools/README.md
Change-Id: Ibc874a29b4f283de0f2b2bae9485743618e215f8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7210931
Auto-Submit: Jean-Philippe Gravel <jpgravel@chromium.org>
Commit-Queue: Andres Ricardo Perez <andresrperez@chromium.org>
Reviewed-by: Andres Ricardo Perez <andresrperez@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1551663}
--
wpt-commits: 3a2402822007826e89a1dc4fd5534977cccd1753
wpt-pr: 56344
Diffstat:
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/testing/web-platform/tests/html/canvas/tools/README.md b/testing/web-platform/tests/html/canvas/tools/README.md
@@ -611,10 +611,10 @@ In practice, we have found bugs in the canvas what only happen for very specific
combinations of states, like, using a specific `globalCompositeOperation`, with
transforms and shadows enabled, but only when `drawImage` is used. We might want
be thorough and test as many combinations of these states as we can, but testing
-all permutations would require $3*2*26*2*2*2*2*3 = 7488$ tests. Putting all of
+all permutations would require $`3*2*26*2*2*2*2*3 = 7488`$ tests. Putting all of
these in different files would be unmanageable. Comes variant grids to the
rescue! If we generated test files each testing all composite operations in a
-grid, we'd only need a much more reasonable $3*2*2*2*2*2*3 = 288$ files.
+grid, we'd only need a much more reasonable $`3*2*2*2*2*2*3 = 288`$ files.
To generate a variant grid, use the `variants_layout:` config. This has to be a
list of the same lengths as the `variants:` list (as long as there are variant
@@ -649,8 +649,8 @@ would be generated:
- grid-example.B2.D1
- grid-example.B2.D2
-Then, the 3 `single_file` dimensions would produce $2*2*2 = 8$ tests in each of
-these files. For JavaScript tests, each of these test would be generated in
+Then, the 3 `single_file` dimensions would produce $`2*2*2 = 8`$ tests in each
+of these files. For JavaScript tests, each of these test would be generated in
sequence, each with their own `test()`, `async_test()` or `promise_test()`
fixture. Reftest on the other hand would produce a 2x2x2 grid, as follows:
```
