You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-values-3][spec-rec] Publish CSS Values & Units 3 as a REC #4846
Now 57 of 70 required tests meet CR exit criteria Problems are ch unit, especially in vertical writing; calc in transform; calc in offset-position, and calc in text-combine-upright: digits .
I suspect carefully checking the correctness of those tests, then filing individual bugs on browser engines, would help drive those fails towards zero.
And yes, a human-written addendum that the fails are more to do with the other specs being tested (this is particularly true with a spec like V&U) will be needed.
It can be fixed manually (using link-defaults), but the reason it's happening is that I currently only distinguish between "ED" and "TR" statuses for definitions; I don't go into more fine-grained divisions within TR. As such, Values 4 is considered a perfectly suitable definition source.
Assessing the level of implementation support is tricky because the values and units can't be implemented by themselves; the actual WPT are examples where other specifications are using them. There is a manually generated implementation report but that was last updated April 2021.
@tabatkins@fantasai how close do you think this is to getting to REC? It would need another CR Snapshot first, of course.
ACR draft was published in 2024 so @fantasai@tabatkins how much plea-bargaining would an implementation report have to do to be able to exit CR? It seems tht Firefox is still in the lead, so we need one other implementation to improve.
It would be both easier to understand where things stand if there were subdirectories corresponding to the different sections of the spec, rather than having 285 files in a single directory, and easier to exclude additions from Level 4 and Level 5.
And skimming through those tests, the results basically seem ok - Blink and WebKit either try to be smart about the computed value or just return the authored value - though those sometimes differ from the expected value, which often uses (unnecessary) calc() expressions.
Activity
svgeesus commentedon Mar 9, 2020
The report is automatically generated. Here is the current one (39 of 70 required tests meet CR exit criteria).
The main things missing are passes on
chunits in both horizontal and vertical writing.There are also missing test results for Blink, Webkit (and also Edge, if anyone has a pre-Blink Edge around for testing)
svgeesus commentedon Mar 9, 2020
Currently 6 open, 41 closed issues (one of them being this meta-issue).
gsnedders commentedon Mar 9, 2020
Well, yes, but I've almost never seen an implementation report accepted without any sort of human-written element explaining failures. :)
FWIW, it wasn't clear how many of those are things that actually block Level 3?
gsnedders commentedon Mar 9, 2020
https://wpt.fyi/results/css/css-values?label=master&product=edge-44.17763.1.0&product=chrome%5Bstable%5D&product=firefox%5Bstable%5D&product=safari%5Bstable%5D&aligned has results for 4b7986331d2e2ee1e63ed42e392d36946904327c, which is admittedly now a while ago.
svgeesus commentedon Mar 10, 2020
Now 57 of 70 required tests meet CR exit criteria Problems are
chunit, especially in vertical writing;calcintransform;calcinoffset-position, and calc intext-combine-upright: digits.I suspect carefully checking the correctness of those tests, then filing individual bugs on browser engines, would help drive those fails towards zero.
And yes, a human-written addendum that the fails are more to do with the other specs being tested (this is particularly true with a spec like V&U) will be needed.
svgeesus commentedon Mar 10, 2020
I removed the
css-values-3tag on #4329 and the rest look like low-hanging fruit that could be closed off speedily.svgeesus commentedon Mar 10, 2020
Okay that is a bit whacked.
I'm guessing that is incorrect bikeshed syntax, and should be fixed.
tabatkins commentedon Mar 10, 2020
It can be fixed manually (using link-defaults), but the reason it's happening is that I currently only distinguish between "ED" and "TR" statuses for definitions; I don't go into more fine-grained divisions within TR. As such, Values 4 is considered a perfectly suitable definition source.
svgeesus commentedon Jul 31, 2024
So (four years later):
Assessing the level of implementation support is tricky because the values and units can't be implemented by themselves; the actual WPT are examples where other specifications are using them. There is a manually generated implementation report but that was last updated April 2021.
@tabatkins @fantasai how close do you think this is to getting to REC? It would need another CR Snapshot first, of course.
svgeesus commentedon Oct 17, 2025
Seems pretty static, now 3302 tests.
and changes not updated but almost no changes since last CRS
ACR draft was published in 2024 so @fantasai @tabatkins how much plea-bargaining would an implementation report have to do to be able to exit CR? It seems tht Firefox is still in the lead, so we need one other implementation to improve.
And should we publish a CR Snapshot to incorporate the one tiny but non-editorial change?
gsnedders commentedon Oct 17, 2025
A quick glance at tests with less than two passes suggests that it's mostly things in later levels which don't pass.
It would be both easier to understand where things stand if there were subdirectories corresponding to the different sections of the spec, rather than having 285 files in a single directory, and easier to exclude additions from Level 4 and Level 5.
SebastianZ commentedon Oct 18, 2025
Looking at the main portion of failing tests in the spec, they refer to values in CSS Shapes like https://wpt.fyi/results/css/css-shapes/shape-outside/values/shape-outside-circle-004.html?label=master&label=experimental&aligned.
And skimming through those tests, the results basically seem ok - Blink and WebKit either try to be smart about the computed value or just return the authored value - though those sometimes differ from the expected value, which often uses (unnecessary)
calc()expressions.For what it's worth, there's also a Chromium bug related to those tests.
Sebastian