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
The spec for UserSpaceOnUse (link) states that clip-path contents use a coordinate system based on the referencing element, not the referenced clip-path:
userSpaceOnUse: The contents of the clipPath represent values in the current user coordinate system in place at the time when the clipPath element is referenced (i.e., the user coordinate system for the element referencing the clipPath element via the clip-path property).
Batik follows the spec and the clip is sized to 250x250 (50% of the viewport)
Chromium, Webkit, Gecko, and Inkscape disagree with the spec and the clip is sized to 100x100 (50% of #inner).
One path forward is to measure if the current spec is web-compatible. This could be done by looking at httparchive data for relative units in clipPath, or by collecting metrics from a browser for how often this occurs in the wild.
The spec for UserSpaceOnUse (link) states that clip-path contents use a coordinate system based on the referencing element, not the referenced clip-path:
A simple example is the following testcase:
Batik follows the spec and the clip is sized to 250x250 (50% of the viewport)
Chromium, Webkit, Gecko, and Inkscape disagree with the spec and the clip is sized to 100x100 (50% of #inner).
One path forward is to measure if the current spec is web-compatible. This could be done by looking at httparchive data for relative units in clipPath, or by collecting metrics from a browser for how often this occurs in the wild.
Additional links: chromium's tracking bug, gecko's tracking bug (see also this discussion). Aspects of this issue were raised in #249. This recently came up in interop-2023 and we excluded the two tests of this behavior (web-platform-tests/interop#608).
The text was updated successfully, but these errors were encountered: