[css-transforms-1] Define basis for percentage transform on patterns, gradients, clipPath

[smfr]

http://www.w3.org/mid/9B0DDCB4-B480-471F-943A-C5ED00598DFA@adobe.com

During the FX meeting in Hamburg we resolved that percentage values for the 'transform' property should not be ignored. IIRC we did not resolve if percentage values are relative to:

• the user space of the referencing object
• the bounding box of the referencing object
• the size of the resource (pattern/gradient/clipPath size).

I would like to avoid to use the last item since we do not have a definition for the size of clipPath.

Relative to the bounding box seems more natural to me and would be consistent with percentage values for 'transform' on the object itself.

Here is an example:

<svg width="500" height="500">
<defs>
    <clipPath transform="translate(20%, 20%)" id="clipping">
        <rect width="20" height="20"/>
    </clipPath>
</defs>

<rect width="200" height="200" fill="green" clip-path="url(#clipping)">
</svg>

Going with the first two items of the list, should the clipPath be translated by

• (100px, 100px) or
• (40px, 40px)

[css-meeting-bot]

The CSS Working Group just discussed More %s, and agreed to the following resolutions:

RESOLVED:  no change

The full IRC log of that discussion

<TabAtkins> Topic: More %s
<TabAtkins> GitHub Topic:
<TabAtkins> GitHub Topic: https://github.com/w3c/csswg-drafts/issues/892
<TabAtkins> smfr: Does transform-box resolve this one as well?
<TabAtkins> TabAtkins: Yeah, should be.
<TabAtkins> smfr: transform-box doesn't have a definitio nfo the gradient "size" tho. Perhaps it's not something you should be able to do.
<TabAtkins> ChrisL: There's a default clip-path on the SVG root that's set to its bounding box.
<TabAtkins> Rossen: Would the bounding box change if the clip-path was shrunk?
<TabAtkins> ChrisL: No.
<TabAtkins> Rossen: So no, there's no way to target the clip-path box.
<TabAtkins> smfr: So a no-change?
<TabAtkins> TabAtkins: Seems like it yes. Everything is either handled by transform-box already, or doesn't have a use-case.
<TabAtkins> RESOLVED:  no change

[AmeliaBR]

I'm not sure what "no change" is supposed to mean. There is no guidance on this question in either the transform spec or the SVG spec.

SVG 1.1 didn't have transformations on clipPath or mask, but it did have patternTransform and gradientTransform. I would expect a transformation on a clip-path or mask to work the same way: as a transformation of the infinite canvas on which the effect is defined, after scaling it according to the size of the shape's bounding box or userSpace, but prior to compositing it with the shape.

However, that doesn't answer the question about percentages. The SVG 1.1 syntax did not have percentages in transforms, and therefore they didn't need a reference box. However, they did need a reference origin.

All the graphical effects do have a reference box (the box used for defining the scale of the effect, whether that was objectBoundingBox or userSpaceOnUse), albeit one that doesn't fit with transform-box.

For gradients, we even have consistent implementations that use that reference box to define the transform origin for scales and rotations. So if it's a userSpace gradient, the rotation is around the user-space origin. If it's a bounding-box gradient, the rotation is around the top-left corner of the bounding box (after adjusting for any non-uniform scale transformation created by scaling the effect coordinate space to the bounding box).

For patterns, implementations aren't currently consistent with each other or the spec. SVG spec bug discussion is here: w3c/svgwg#293
I have a demo/test case here: https://codepen.io/AmeliaBR/details/woKBYp/

---

All of this is in addition to the long-standing issue that we still do not have clear definitions of what objectBoundingBox and userSpaceOnUse mean when applied to a non-SVG element, or how they interact with reference boxes defined in the mask/clip/fill/stroke properties on the target elements.

[smfr]

https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Bounding_boxes

[smfr]

Still needs some thought and spec wording.

[dirkschulze]

Ok, looked at this again. Lets limit the issue in question to the <pattern> element.

The <pattern> element has the attributes patternUnits, patternContentUnits and patternTransform. All 3 attributes influence the coordinate system for drawings.

• patternContentUnits modifies the coordinate space for the content of <pattern> (content of the tile)
• patternUnits specifies a coordinate space for the pattern tile itself. Namely the width and height attributes.
• patternTransform specifies the coordinate space for the pattern itself. Percentage values get resolved according to the reference box of the referencing element in the local coordinate space of the referencing element (a <rect> element for instance).

As a result, according to the current specification text, patternUnits do not contribute to the transformation of the patternTransform.

@AmeliaBR Do you think this is a breaking change? Do you have an example?

[dirkschulze]

It kind of seems that we mix this issue with #893.

Lets keep this issue to the reference box for percentage values. Will repost the above in the other issue.

Edit: Maybe it was just me who mixed up the issues.

[css-meeting-bot]

The Working Group just discussed Define basis for percentage transform on patterns, gradients, clipPath.

The full IRC log of that discussion

<krit> topic: Define basis for percentage transform on patterns, gradients, clipPath
<BogdanBrinza> GitHub: https://github.com//issues/892
<krit> krit: pattern has patternTransform attribute
<krit> krit: this is mapped to transform property
<krit> krit: which supports percentage
<krit> krit: what do those percentages map too
<krit> krit: currently the spec says they map to the reference box from the transform-box
<krit> AmeliaBR: there are incompatibilities even today
<krit> AmeliaBR: we have different implementations doing different transforms... was never really well defined.
<krit> AmeliaBR: one coordinate. system for tile size, tile content and so on... all use objectBoundingBox or userSpaceOnUse
<krit> krit: even worst, the reference box is different depending if it is content or pattern size
<krit> krit: we also need to decide if the coordinate spaces should be consistent across pattern and mask... extended to work with percentages ... extended to work on clip-path as well.
<krit> krit: AmeliaBR Worte a detailed proposal: https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Bounding_boxes
<krit> AmeliaBR: is it possible to summarise>?
<krit> AmeliaBR: don't think it is a proposal but rather a summary what is brokeb
<krit> AmeliaBR: for patterns you also want to transform the tiling pattern
<krit> AmeliaBR: like when you transform the root element in a canvas window... like a repeating background image on a root element... when you rotate and scale it the entire canvas rotates and scales... you'd expect something like this for pattenr
<krit> krit: for me that sounds like patternTransform comes before the tile size coordinate system and contnet
<krit> AmeliaBR: it is like grouping, right
<krit> AmeliaBR: but then you need to define the reference size and origin
<krit> AmeliaBR: currently it is not defined in a rich way and browsers are inconsistent
<krit> krit: inconsistent across all browsers or just certain browsers
<krit> AmeliaBR: last time there were at least3 different versions that cmae
<krit> AmeliaBR: came out
<AmeliaBR> Incompat for SVG patternTransform: https://github.com/w3c/svgwg/issues/293
<krit> krit: is there something we can work on step by step?
<krit> krit: like agree on the transform order?
<krit> krit: for pattern: as if the entire pattern would be grouped and then transformed...
<krit> AmeliaBR: that seems constantly across browsers already
<krit> AmeliaBR: it gets inconsistent when you rotate... what is the origin to rotate around.
<krit> krit: then agree on the order first
<krit> krit: go with "grouping" the entire pattern/mask/clipPath independent of the additional attributes they have...
<krit> BogdanBrinza: not objecting... seems to make sense
<ChrisL> same here, irc and web works but no audio
<BogdanBrinza> let
<BogdanBrinza> let's call in again
<BogdanBrinza> I redialed and doesn't seem that anybody can hear me, right?
<BogdanBrinza> let's quickly capture the last statement to continue smoothly next week
<ChrisL> good idea
<BogdanBrinza> Dirk, was there anything not minuted already?
<BogdanBrinza> believe the question was on the "grouping" of the patterns/masks/etc and Amelia's opinion on that right?
<krit> correct
<krit> krit: believe the question was on the "grouping" of the patterns/masks/etc and Amelia's opinion on that right?
<AmeliaBR> Last thing I was saying (not sure if any of you heard it): this is another case where we need to write out all the different options (spec-wise), and work through the consequences, to see if they make sense and/or have any compat issues.
<BogdanBrinza> thank you Amelia
<ChrisL> I didn't hear that and yes, I agree
<krit> any action until next weeks call?
<BogdanBrinza> I read Amelia's reply as the action plan
<BogdanBrinza> write down the specific options (ideally with samples) and work through the compatibility impact of each (if any impact at all)
<AmeliaBR> Yep. If anyone can come up with more demos/scenarios (including theoretical examples of features that aren't implemented yet), that would be very helpful.
<AmeliaBR> I'll also call out on Twitter, see if we can get some other opinions from SVG/CSS authors.

[dirkschulze]

Created another example here: https://codepen.io/krit/pen/LmGyJy

The example has 8 rectangle stripes.

• The first 4 are as width as the viewport.
• The last 4 half the size of the viewport.

Furthermore:

• For the first 2 of each a transform property gets applied with percentage values.
• For the last two, gradientTransform.

objectBoundingBox and userSpaceOnUse are used between the 8 rects.

The transform property only gets implemented in Blink. The results are not fully conclusive (Blink has an issue with one of the gradientTransforms). However, it is save to say that Blink does not use the reference box of the referencing element.

[dirkschulze]

We clarified that gradientTransform and patternTransform apply in the gradient coordinate space or pattern coordinate space respectively. The same space, percentage values of the x, x1, x2, y, y1, y2, width and height attributes need to get resolved to too.

I'd propose that we ignore the "reference box" specified by transform-box not the pattern, linearGradient, radialGradient and clipPath elements and reuse the reference box that the above named attributes use. @AmeliaBR any objections to this sentiment? Though, as @AmeliaBR mentioned, this reference box is not entirely interoperable. However, that is an issue of the SVG spec IMO.

[AmeliaBR]

I'd propose that we ignore the "reference box" specified by transform-box not [edit: I assume you mean "on"] the pattern, linearGradient, radialGradient and clipPath elements and reuse the reference box that the above named attributes use. @AmeliaBR any objections to this sentiment?

That much I support.

And to clarify, for pattern and for mask, you're suggesting to use the "outer" reference box (patternUnits/maskUnits), not the *ContentUnits ? I think that's the only approach that can logically be applied, since the transformation needs to apply to the full canvas (e.g., after pattern tiling).

[css-meeting-bot]

The Working Group just discussed Define basis for percentage transform on patterns, gradients, clipPath.

The full IRC log of that discussion

<BogdanBrinza> topic: Define basis for percentage transform on patterns, gradients, clipPath
<BogdanBrinza> GitHub: https://github.com//issues/892
<chris> dirk: introduced transform box, as it is different in html and svg. Problem with resource elements
<chris> ... not clear what the reference box should be
<chris> ... already have this in SVG 1.1, patternUnits, clipPathUnits
<chris> ... indirect referene box, x y etc resolve relative to that
<chris> ... suggest using same reference box for the transforms esp percentage values
<chris> ... easiest and most straightforward way
<chris> AmeliaBR: reviewed before call, most sensible approach. No easy way to do transform box.
<chris> ... what Dirk prooposes is consistent with how gradient transform is implemented everywhere. pattern transform needs better interop, so good guidance. And also for clipPath and mask
<chris> ... consistent where we have web compat
<chris> dirk: not clearly defined that it also defines the reference box, spec needs to be clearer
<chris> AmeliaBR: yes we need spec text
<chris> ... in clipping and masking and svg2
<chris> tav: and test cases
<chris> (general agreement)
<chris> resolved: use indirectly defined reference boxes for transforms on resource elements. transform box does not apply to graphics elements.
<chris> dirk: I will do the spec work
<chris> AmeliaBR: we need tests, they will need to be manual tests as affect rendering
<chris> dirk: we have some tests for clippath but not with transforms or percentage units
<chris> dirk: 3 more issues on tranform spec, need to be discussed by css wg. then will republish
<chris> ... want wider review
<chris> s/tranf/transf/