1566167 - transform: translate() function removes second parameter if it is 0px

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect)

Description

[emnudge]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36

Steps to reproduce:

I set an element's style property's transform to the string "translate(20px, 0px)"
($0.style.transform = "translate(20px, 0px)")
I requested the transform string back
(console.log($0.style.transform))

Actual results:

I got "translate(20px)" which removes the second parameter. Although both are equivalent, it is unexpected behavior and differs from Edge, IE, Chromium, and Safari. It breaks functions that rely on getting 2 parameters as an output when providing them as an inpu.

Expected results:

My second parameter should have been preserved in the return string. I should have gotten "translate(20px, 0px)"

Comment 1

[emnudge]

Attachment: bug shown using dev console

Comment 2

[Liviu Seplecan]

Hi @emnudge, Please provide a TC(testcase) in order to test the issue.
Thanks.

Comment 3

[emnudge]

@Livui(In reply to Liviu Seplecan from comment #2)

Hi @emnudge, Please provide a TC(testcase) in order to test the issue.
Thanks.

I thought the reproduce steps were clear enough, but it is also reproducible using this site made by Tom Hodgins:
https://tomhodgins.com/demo/cssom/
Typing CSS on the left will add that CSS, copy it, and then paste it back in the window to the right. It shows how a specific browser handles that property.
In every other browser, typing

div {
  transform: translate(20px, 0px);
}

on the left will output

div { transform: translate(20px, 0px); }

on the right. In firefox, however, it will output

div { transform: translate(20px); }

which matches up with the bug I've been seeing.

For a more practical example, I made a JS fiddle: https://jsfiddle.net/ay0jet8v/1/
Looking at the HTML, it will say what position the div is at. The y position will be undefined in firefox instead of 0px

Comment 4

[Liviu Seplecan]

Hi @emnudge, tks for the examples provided. Here are the results after testing the issue:
[Platform affected -tested]: Windows 10, Mac OS X, Ubuntu 18.04
[Environment]: Firefox nightly 70.0a1, beta 69.0b8, release 68.0.1
-> on all machines & FF versions the issue can be reproduced.
Additionally, something to mention is - on FF if the value is modified (other than "0") =>the value is parsed correctly. This can be seen in the screenshot attached.
Further, I will add a component, if isn't the right one please fell free to change it.
Thanks.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

This is invalid, as far as I can tell.

From https://drafts.csswg.org/cssom/#serializing-css-values:

If component values can be omitted or replaced with a shorter representation without changing the meaning of the value, omit/replace them.

As stated there, we may change this for compatibility with other engines, but I think lacking broken sites, the Gecko behavior is preferable / more consistent / more correct.

It is the same principle why when you write $0.style.margin = "0 0 0 0" you get back 0px not 0px 0px 0px 0px, in all engines when you do $0.style.margin.

Eric, would this be something Chromium would be interested in fixing / want a crbug for this?

Comment 6

[Liviu Seplecan]

Attachment: transform translate - property.png

Comment 7

[Eric Willigers]

I think Firefox was previously consistent with other browsers here.

My preference is not to remove consistency that previously existed, like in https://drafts.csswg.org/cssom/#serializing-css-values
"For legacy reasons, some properties serialize in a different manner, which is intentionally undefined here due to lack of resources. Please consult your local reverse-engineer for details."

My preference isn't an official Blink view.

This also affects percentages:
document.body.style.transform = "translate(10px, 0%)";
document.body.style.transform
-> "translate(10px)" in Firefox Nightly, "translate(10px, 0%)" elsewhere.

Like in https://www.w3.org/TR/css-values-4/#calc-serialize
"A value like calc(20px + 0%) would serialize as calc(0% + 20px), maintaining both terms in the serialized value. (It’s important to maintain zero-valued terms, so the calc() doesn’t suddenly "change shape" in the middle of a transition when one of the values happens to have a zero value temporarily. This also removes the need to "pick a unit" when all the terms are zero.)"
my preference is to not "change shape" when lengths are involved

Part of the reason I have been writing WPTs for serialization of each property is so we all have better understanding of what browsers currently do.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

I filed bug 1573830 for that.