W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > January 2018

[fxtf-drafts] [filter-effects][css-masking][fill-stroke] clarify userSpaceOnUse / objectBoundingBox applied to non-SVG elements

From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
Date: Wed, 24 Jan 2018 19:27:13 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issues.opened-291330305-1516822031-sysbot+gh@w3.org>
AmeliaBR has just created a new issue for https://github.com/w3c/fxtf-drafts:

== [filter-effects][css-masking][fill-stroke] clarify userSpaceOnUse / objectBoundingBox applied to non-SVG elements ==
`filter`, `mask`, `clip-path`, and the proposed extension of `fill` and `stroke` all support SVG graphical effects applied to CSS layout boxes.

The problem: none of these specs clearly define how the SVG effect-scaling attributes ( `objectBoundingBox` versus `userSpaceOnUse` for `filterUnits`, `primitiveUnits`, `maskUnits`, `maskContentUnits`, `clipPathUnits`, `gradientUnits`, `patternUnits`, and `patternContentUnits`) map to the CSS box model.

I *think* we've got fairly consistent implementations when it comes to `objectBoundingBox` effects (but I haven't tested carefully), by mapping it to border-box. This is despite the fact that definitions in masking and filters just link to the SVG spec's definition of bounding box units. And fill & stroke has text trying to get border-box to match stroke-box.

I *know* we don't have consistency for `userSpaceOnUse` effects. Definitions in the spec link to CSS Transforms' [definition of the user coordinate system](https://drafts.csswg.org/css-transforms-1/#user-coordinate-system), which has now been updated to be defined as the `transform-box` width and height and position, with 1 unit = 1 CSS px.  (I haven't tested whether any browsers that implement `transform-box` for SVG elements also change how `userSpaceOnUse` effects work in SVG. But my guess is no.)

Of course, to make it even more confusing, only Firefox matches the spec definition of `userSpaceOnUse` for SVG elements. Everyone is else is broken in a very unhelpful way.

(PS, Sorry for not bringing this up before. It's only as we've been working through FXTF issues that I realized there wasn't already an open issue for something I knew as one of the biggest issues with these specs!)

Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/249 using your GitHub account
Received on Wednesday, 24 January 2018 19:27:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:21 UTC