Closed birtles closed 6 years ago
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.
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.)
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.
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.)
Related to issue #928
Should we move transform-box to level 2 given that only Gecko implements it?
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.
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.
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.
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:
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.
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
So the net result of that discussion as it applies to the original topic of this issue:
Which results in these required actions from implementers:
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.
I would like to implement transform-box in WebKit according to Amelia's latest summary. This will happen via webkit.org/b/145783.
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
@AmeliaBR If @smfr doesn't get to it I can take a look later next week.
Be my guest. Haven't had time for spec editing recently.
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).
Let's use the better-titled issue #999 to cover the rest of the changes.
The spec says,
Erik points out that,
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).