search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.48k stars 662 forks source link

[css-transforms] Spec and blink implementation of transform-box for SVG elements differ #857

Closed birtles closed 6 years ago

birtles commented 7 years ago

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

fsoder commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Related to issue #928

smfr commented 7 years ago

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

AmeliaBR commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 ``` Topic: border-box vs view-box in transform-box GitHub Topic: https://github.com/w3c/csswg-drafts/issues/857 TabAtkins: I have an action to review the CSS <=> SVG box keyword mappings and find a consistent mapping between them. TabAtkins: This one (border-box = view-box) is particularly bad; border-box normally equals stroke-box. TabAtkins: I suspect it was done solely to give us an initial value that captured the diff between CSS and SVG. Rossen: So is that a spec bug? TabAtkins: Yeah. We should make border-box work properly. Then add a new initial value (auto?) that still captures the dual-behavior we want. Rossen: Objections? smfr: Ah yeah, they're bending what border-box means right now. RESOLVED: Add "auto" as initial value for transform-box, give it the current border-box/view-box dual behavior 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: 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: Should we add the additional box keywords and set up a proper mapping? RESOLVED: Add stroke/padding/content-box, and set up the proper mappings between them for transform-box. ```
AmeliaBR commented 7 years ago

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.

css-meeting-bot commented 7 years ago

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

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

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.

smfr commented 7 years ago

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

AmeliaBR commented 7 years ago

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 commented 7 years ago

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

smfr commented 7 years ago

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

smfr commented 6 years ago

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 commented 6 years ago

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