Csswg-drafts: [css-transforms] Spec and blink implementation of transform-box for SVG elements differ

[birtles]

The spec says,

"For SVG elements without an associated CSS layout box, the used value for border-box is view-box."[1]

Erik points out that,

"It seems to me that a used value of 'fill-box' in this case would lead to more easily understood behavior than 'view-box'."

I believe Chrome ships with a used value of fill-box. Firefox is not shipping transform-box (see Mozilla bug 1208550 and bug 1209061) because we are waiting to see if the spec changes or Chrome changes. I have been unable to get any answer from blink folk about whether or not they are going to change this (see twitter thread).

[AmeliaBR]

If the decision is to "make Chrome's behavior the default" because of web-compat, the spec will need a new value. Chrome's behavior is equivalent to fill-box for percentages (lengths in transform and position in transform-origin), but is equivalent to view-box for absolute measurements in transform-origin. Which means it is possible for transform to use fill-box percentages for translation distances even while transform-origin uses the view-box origin. It also means that transform-origin: 0 0 (the default, backwards compatible with SVG 1) is very different from transform-origin: 0% 0% (which switches to fill-box behavior).

I've said in many places that I find this behavior to be a horrible mess of logical inconsistency, but if the only way to get the logical behavior as an _option_ is to spec the illogical behavior as the default, I may have to grudgingly accept that.

[fsoder]

We added a use counter to Blink to attempt to gauge the amount of breakage this might cause:

https://www.chromestatus.com/metrics/feature/timeline/popularity/1842

At the time of writing it's at 0.007% (after reaching the Beta channel.) This is supposed to be an upper bound.
I'd also like to note, that because of the duality @AmeliaBR describes, it won't necessarily be possible to "save" all current uses. (I'm contemplating adding a counter for that.)

[AmeliaBR]

Thanks for those numbers Frederick.

I assume the jump in the stats from the middle last week is related to the usage counter expanding from Chrome Canary users to Chrome Beta users? (And so the later numbers are probably more representative of the wider web...)

Do you have a separate tracker for transform-box itself? With Firefox's transform-box support ready to roll out in v55, I suspect we'll see an increase in usage of transform-box: fill-box over the coming months, as devs fix transforms that were designed for Chrome but look broken in Firefox.

Given approximately 0.01% usage, would it be worth having some sort of organized education & transition plan, such as console warnings on sites that trigger that measurement? In addition to warning that the transformation of some elements might change in a future version, it could provide a link to information about the transform-box property (to MDN or the spec).

Of course, once we get a clear commitment that Blink is going to implement transform-box, I know many "thought leaders" in the SVG web animation community who would happily help get the word out. But they need a clear, consistent implementation plan from browsers so that they can provide useful advice.

[fsoder]

The jump would be for the Dev -> Beta transition, yes (and, yes, more representative.)
There's no counting for the transform-box property, because it isn't yet implemented. I will get an "Intent to Implement" out and land the implementation behind the experimental flag. That ought to give additional early warning and some indication (and hopefully experimentation.) We'll need to get this issue resolved before we can consider shipping though I think. (0.01% is a pretty sizable number using the measuring sticks of today.) I'm not sure about a "console" (deprecation?) warning, but I'd be willing to consider it (and ventilate it to hear other peoples opinion.)

[smfr]

Related to issue #928

[smfr]

Should we move transform-box to level 2 given that only Gecko implements it?

[AmeliaBR]

Not unless you're willing to accept non-interoperable implementations of transform and transform-origin applied to SVG elements. That's the main issue. transform-box is the proposed solution.

[fsoder]

Blink has implemented transform-box, but shipping is hinged on what happens here. And, as @AmeliaBR says, even if the property is moved to L2 the reference-box term needs to be defined for L1.

[css-meeting-bot]

The CSS Working Group just discussed border-box vs view-box in transform-box, and agreed to the following resolutions:

RESOLVED: Add "auto" as initial value for transform-box, give it the current border-box/view-box dual behavior

RESOLVED: Add stroke/padding/content-box, and set up the proper mappings between them for transform-box.

The full IRC log of that discussion

<TabAtkins> Topic: border-box vs view-box in transform-box
<TabAtkins> GitHub Topic: https://github.com/w3c/csswg-drafts/issues/857
<TabAtkins> TabAtkins: I have an action to review the CSS <=> SVG box keyword mappings and find a consistent mapping between them.
<TabAtkins> TabAtkins: This one (border-box = view-box) is particularly bad; border-box normally equals stroke-box.
<TabAtkins> TabAtkins: I suspect it was done solely to give us an initial value that captured the diff between CSS and SVG.
<TabAtkins> Rossen: So is that a spec bug?
<TabAtkins> TabAtkins: Yeah. We should make border-box work properly. Then add a new initial value (auto?) that still captures the dual-behavior we want.
<TabAtkins> Rossen: Objections?
<TabAtkins> smfr: Ah yeah, they're bending what border-box means right now.
<TabAtkins> RESOLVED: Add "auto" as initial value for transform-box, give it the current border-box/view-box dual behavior
<TabAtkins> TabAtkins: Further issue here - spec maps fill-box to border-box. That violates the mapping used elsewhere in CSS, where border=stroke and padding/content=fill.
<TabAtkins> TabAtkins: Suspect it was just because there's only use-cases for those two, and they're close enough that they wer ejust mapped for convenience. But that's inconsistent and bad for the platform.
<TabAtkins> TabAtkins: Should we add the additional box keywords and set up a proper mapping?
<TabAtkins> RESOLVED: Add stroke/padding/content-box, and set up the proper mappings between them for transform-box.

[AmeliaBR]

To clarify: "the current border-box/view-box dual behavior" means that SVG and CSS layout elements have different default boxes? I see on #895 there is a resolution (thank you) against entrenching the Blink/WebKit "dual behavior" of a different sort, where % values use a different reference box than length values.

For SVG versus CSS, I don't see a reason for auto. The better way to address the issue is via user-agent styles, as discussed in #928. I can't imagine an author intentionally setting the same transformation on both SVG and CSS layout elements, and yet want different reference boxes for each. And there's no backwards-compatibility issue with the transform-box property itself, so long as the defaults are correct when it isn't used.

---

As for generally creating a mapping for CSS layout boxes to fallback to SVG layout boxes, and vice versa, I'm fine with that so long as it is consistent across all properties. To make that work for many properties either means expanding the number of allowed values so that the reference box equivalents exist, or defining a separate set of property-specific fallbacks.

My preferred equivalents are as follows:

• view-box : positioning containment box (whatever would be used for % in width & height)
• decorated-box : margin-box
• stroke-box : border-box
• fill-box : content-box

That leaves padding-box without a match. I'd say it should also fallback to fill-box (but fill-box would fall back to content-box).

For reference: Definitions of the SVG boxes are here.

PS, This discussion should probably be in a separate issue. Not sure if one already exists, or if it needs to be created.

PPS, Comment edited for grammatical disconnectedness. Apologies to anyone who tried to read the email notification.

[css-meeting-bot]

The CSS Working Group just discussed CSS-SVG Box Correspondences, and agreed to the following resolutions:

• RESOLVED Initial value of transform is view-box
• RESOLVED: Initial value of transform is view-box
• RESOLVED: view-box and stroke-bo resolve to the same as boxes defined in fill-stroke module

The full IRC log of that discussion

<fantasai> Topic: CSS-SVG Box Correspondences
<Rossen> ScribeNick: flackr
<tantek> present+
<flackr> fantasai: issue is to have a standardized mapping between dash box keywords, bunch of properties take these kinds of keywords
<skk> present+
<dbaron> s/dash box/*-box/
<flackr> Rossen: yesterday we partially covered issue, and agreed on mapping. content-box and padding-box map to fill-box. border-box maps to stroke-box
<flackr> fantasai: we need something to go back in other direction
<flackr> Rossen: for view-box?
<flackr> TabAtkins: it's a box, but we don't have anything that let's you refer to it
<dbaron> It seems we have three github issues on this: https://github.com/w3c/fxtf-drafts/issues/66 https://github.com/w3c/csswg-drafts/issues/999 https://github.com/w3c/csswg-drafts/issues/857
<flackr> TabAtkins: we can map view-box to one of the element based boxes
<dbaron> Github issue: https://github.com/w3c/csswg-drafts/issues/857
<flackr> fantasai: in fill and stroke module css ends up having all of these boxes, <points to content, padding, border, stroke>
<flackr> fantasai: are there places in other specs where we take these boxes?
<flackr> TabAtkins: no, we only have these in fill and stroke because they talk about text, with geometry different than normal boxes
<flackr> fantasai: fill-origin property, which takes these keywords can be set on any element. it's not applied to text, applied to an element and takes that object's geometry for settting the fill origin for images
<flackr> fantasai: if we don't have transform-box or other box properties use that same definition, then if you set coordinates in transforms and set the same in fill or stroke, you would get different results
<flackr> fantasai: we didn't run into a use case while working on transforms that we needed these text based bounding box concepts, but we should use this same concept in all of our boxes whereever fill or stroke appears
<flackr> fantasai: for example for setting a mask image with the same origin when set to fill-box as a fill with origin set to fill-box
<flackr> TabAtkins: possible
<flackr> TabAtkins: problem is that mask, transform, and shapes
<flackr> fantasai: shape doesn't have fill and stroke
<dbaron> reading https://github.com/w3c/csswg-drafts/issues/999#issuecomment-277024658
<flackr> dbaron: the notion that some of the properties are doign different things does make some sense because they can't reasonably map into the same property
<flackr> fantasai: didn't discover we needed fill and stroke box until we did this module
<fantasai> s/this/fill-stroke/
<dbaron> https://drafts.fxtf.org/fill-stroke/
<fantasai> s/until/in CSS until/
<flackr> fantasai: view-box is on transform-box property?
<flackr> TabAtkins: just on transform-box
<flackr> ChrisL: the view-box declared on the closest svg element
<flackr> Rossen: kind of like initial box of the svg
<flackr> TabAtkins: I don't agree in general we should match fill-box and stroke-box to same meaning
<flackr> TabAtkins: because these properties are dealing with text and these properties are talking about properly filling and stroking that text
<flackr> TabAtkins: whereas for svg they are in a different context, it depends on the property you are interpreting for
<flackr> fantasai: if you have element with some text, and the fill box is bigger, then when you draw an image and add a mask, these need to use the same coordinate system
<flackr> fantasai: but if you're saying fill-box is not available for mask origin can't make these line up
<flackr> TabAtkins: it's still a matter of which concept you're talking about, the box's geometry or the geometry of the text
<flackr> fantasai: it should create the same coordinate system that it does if you set fill-origin on that element
<flackr> Rossen: in css boxes internally, this is going to be an overflow box
<flackr> fantasai: it's text only
<flackr> fantasai: it's the outline of the glyphs, so not quite the inline text box
<flackr> fantasai: i think we need consistent coordinate systems, fill-origin and mask-origin should have the same behavior for the same keywords
<flackr> fantasai: if those have same behavior for same keywords, transform-box should too
<flackr> TabAtkins: yeah, but other properties such as mask-origin, when using svg keyword on css stuff will have a changed meaning
<flackr> fantasai: hopefully people aren't doing that
<flackr> ChrisL: how much of a breaking change is this?
<flackr> TabAtkins: might be minor, might be major, depends on content
<flackr> fantasai: initial value might need to be some kind of auto keyword that depends on whether it's svg or css
<flackr> ChrisL: i'd rather avoid making breaking changes unless we have to
<fantasai> fantasai: or a UA stylesheet thing
<flackr> TabAtkins: initial value of border-box for svg is view-box
<flackr> TabAtkins: transforms and svgs default to the top-left corner
<flackr> TabAtkins: i guess i'm okay with this
<flackr> TabAtkins: with fill-box used in css meaning what's defined in fill and stroke
<flackr> Rossen: we don't care about view-box?
<flackr> fantasai: this is another issue i think
<flackr> TabAtkins: think we added auto keyword
<fantasai> [confusion about what the resolutions actually were]
<flackr> fantasai: if I specify transform-box: border-box on svg element what do i get?
<flackr> fantasai: If i specify transform-box: view-box on a CSS box what do i get?
<flackr> TabAtkins: maps down to border-box, it's the closest you can get
<flackr> fantasai: what's the initial value?
<flackr> TabAtkins: something different, forget what specifically
<dbaron> (answer to the previous question was border-box -> stroke-box on SVG)
<flackr> fantasai: make initial value view-box to get behavior we want it to have
<flackr> ChrisL: that seems fine
<fantasai> Resolutions from yesterday, presumably were
<fantasai> * border-box in SVG is treated as stroke-box
<fantasai> * view-box is in CSS is treated as border-box
<fantasai> * initial value is view-box
<fantasai> From today: fill-box and stroke-box for CSS are as defined in fill-stroke
<fantasai> for completeness, content-box and padding-box in SVG are treated as fill-box
<flackr> Rossen: view-box and stroke-box resolve to the same as boxes defined in svg fill-stroke
<flackr> RESOLVED Initial value of transform is view-box
<flackr> RESOLVED: Initial value of transform is view-box
<fantasai> RESOLVED: view-box and stroke-bo resolve to the same as boxes defined in fill-stroke module
<fantasai> s/stroke-bo/stroke-box/

[AmeliaBR]

So the net result of that discussion as it applies to the original topic of this issue:

• Blink & WebKit are still wrong.
• Default behavior on SVG elements should be to use the view-box as the reference for both percentages and transform-origin.

Which results in these required actions from implementers:

• The default behavior in Firefox is correct, but the newly-shipped transform-box implementation will need to be updated with the new initial value and the new {specified value ⇒​ used value} mappings.
• The pending transform-box implementation (with change in default behavior) for Blink will need to be updated before shipping.
• A transform-box implementation for WebKit will hopefully follow along soon (with change in default behavior).
• CSS transform support on SVG elements in Edge, including transform-box, will hopefully follow along soon.

Did you get clear commitments & action plans from the implementation teams to make that happen? This is still a breaking change for WebKit & Blink. Anything that breaks wasn't web-compatible to start out with, but there is a lot of CSS code out there that is being written specifically for WebKit & Blink without worrying about web compat.

[smfr]

I would like to implement transform-box in WebKit according to Amelia's latest summary. This will happen via webkit.org/b/145783.

[AmeliaBR]

Has anyone taken an action to update the spec to match the resolutions above? The Editor's Draft still has the old text. I was trying to file a bug on Firefox to update their implementation, but I don't have a final spec text to point them to.

Update: Filed the Firefox bug anyway

[dirkschulze]

@AmeliaBR If @smfr doesn't get to it I can take a look later next week.

[smfr]

Be my guest. Haven't had time for spec editing recently.

[smfr]

I'll change the initial value for transform-box to view-box per the resolution. I don't know if css-transforms-1 should mention the stroke box. There doesn't seem to be a canonical reference to the various box types (https://drafts.fxtf.org/fill-stroke/#fill-origin has them under fill-origin).

[smfr]

Let's use the better-titled issue #999 to cover the rest of the changes.