search

w3c / fxtf-drafts

Mirror of https://hg.fxtf.org/drafts
https://drafts.fxtf.org/
Other
68 stars 49 forks source link

Resolve whether to change UserSpaceOnUse spec #538

Open progers opened 7 months ago

progers commented 7 months ago

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).

A simple example is the following testcase:

<svg xmlns="http://www.w3.org/2000/svg" width="500" height="500">
  <svg id="inner" x="0" y="0" width="200" height="200">
    <clipPath id="myclip" clipPathUnits="userSpaceOnUse">
      <rect x="0" y="0" width="50%" height="50%" />
    </clipPath>
  </svg>
  <rect width="500" height="500" fill="green" clip-path="url(#myclip)" />
</svg>

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 https://github.com/w3c/fxtf-drafts/issues/249. This recently came up in interop-2023 and we excluded the two tests of this behavior (https://github.com/web-platform-tests/interop/issues/608).

thantintsan commented 6 months ago

Please Give MaxWin

yisibl commented 6 months ago

I believe the resvg-js rendering is correct.

image