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