WPT failures in css-masking/clip-path/clip-path-element-userSpaceOnUse-003.html and -004
Categories
(Core :: SVG, defect)
Tracking
()
People
(Reporter: dholbert, Unassigned)
References
Details
These two WPT tests fail in all browsers, with the same "bad" rendering:
https://wpt.fyi/results/css/css-masking/clip-path/clip-path-element-userSpaceOnUse-003.html
https://wpt.fyi/results/css/css-masking/clip-path/clip-path-element-userSpaceOnUse-004.html
The SVG element itself is 300x150, and all browsers fill the right half of that with green for the first test. (and fill the bottom half in the second test)
The test expects that the 50% values on the clipPath will be resolved with respect to the root viewport, instead, though. The spec text seems to support that:
https://drafts.fxtf.org/css-masking-1/#element-attrdef-clippath-clippathunits
("userSpaceOnUse" is the default behavior, which is supposed to make percentages resolve against "the user coordinate system for the element referencing the clipPath element via the clip-path property")
So it looks like the test agrees with the spec, but no browser implements this behavior yet (at least, not for clipPath-referenced-from-html).
Notably, if I add height:100%; width:100% to the <svg> element, then we seem to pass the test; but that's cheating. I think the idea here is that the size of the <svg> element isn't supposed to matter.
|
Reporter | |
Comment 1•1 year ago
|
||
FWIW, it looks like we've had these tests annotated as failing since 2017, based on the history for
https://searchfox.org/mozilla-central/rev/8e1b221afcdae76284b1439c547b032d1f84d236/testing/web-platform/meta/css/css-masking/clip-path/clip-path-element-userSpaceOnUse-003.html.ini
https://searchfox.org/mozilla-central/rev/8e1b221afcdae76284b1439c547b032d1f84d236/testing/web-platform/meta/css/css-masking/clip-path/clip-path-element-userSpaceOnUse-004.html.ini
So: there haven't been any recent behavioral changes here or anything.
|
||
Comment 2•1 year ago
|
||
Bug 866655 is the same thing for patterns I think. If so, the debate there is worth reading.
|
||
Comment 3•1 year ago
|
||
I was looking into this issue in Chromium. Because all engines are interoperable here, but none match the spec, should we file a spec issue for clarification and exclude these tests from interop 2023? Changing behavior here may have web compat risks.
|
|
||
Comment 4•1 year ago
|
||
Do we really want to admit defeat without trying? Opera 12 worked like this and Batik still does.
|
|
Reporter | |
Comment 5•1 year ago
|
||
We don't need to admit defeat or change the spec, necessarily, but at a minimum I think it makes sense to exclude the tests from interop-2023. (For the purposes of that effort, it's hard to make a case that engines must pass these particular tests to be interoperable, when in fact all major engines "interoperably fail" in the same way right now.)
(Maybe worth reconsidering them for interop-2024, particularly if some browser engine implements the spec/test-required behavior in the meantime and that brings confidence that this behavior is web-compatible and sensible.)
|
|
Reporter | |
Comment 6•10 months ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #5)
at a minimum I think it makes sense to exclude the tests from interop-2023.
Update: these tests were just removed from interop-2023 in https://github.com/web-platform-tests/interop/issues/608
And progers filed https://github.com/w3c/fxtf-drafts/issues/538 to consider what we should do about the spec here.
|
|
Reporter | |
Updated•10 months ago
|
|
|
||
Comment 7•2 months ago
|
||
https://www.w3.org/TR/SVG2/pservers.html#PatternElementPatternUnitsAttribute says patterns resolve against the viewport so clipPaths and filters should simply followed suit.
Description
•