Closed Bug 1160281 Opened 5 years ago Closed 5 years ago

Add support for emulating -webkit-transform-origin via CSS unprefixing service

Categories

(Core :: CSS Parsing and Computation, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla41
Tracking Status
p11 + ---
firefox41 --- fixed

People

(Reporter: miketaylr, Assigned: miketaylr)

References

Details

Attachments

(1 file, 1 obsolete file)

It seems fairly trivial to map -webkit-transform-origin to transform-origin via the CSS unprefixing service.

For non-svg content, we pass essentially the same tests at http://test.csswg.org/harness/results/css-transforms-1_dev/grouped/section/8/, which leads me to believe this would be pretty safe (that is, fix more than it would break).

https://github.com/webcompat/web-bugs/issues/1026 is one known site that will need this.
Daniel, if you think this seems OK I'd be happy to write a patch and some tests. WDYT?
Sounds good to me!
Flags: needinfo?(dholbert)
Cool, will start on this tomorrow.
Assignee: nobody → miket
(...For some value of "tomorrow")

I'm working on this now, but will wait until https://hg.mozilla.org/integration/mozilla-inbound/rev/3efe5f06818d lands on m-c before uploading a patch for review.
Thanks! (& sorry if that commit bitrotted your patch)
Nah, have been busy poking at other things until now. No harm done.
Simple mapping of -webkit-transform-origin to transform-origin. 

We could get pretty creative with the testing, but I just added the two actual instances used in one of the top Japan sites this fixes for us. It seems to be the most common usage on GitHub as well [1].

Once we get to r+, I'll push to Try.

[1] <https://github.com/search?p=99&q=-webkit-transform-origin&ref=simplesearch&type=Code&utf8=%E2%9C%93>
(just noticed I need a semicolon here):

>  width: 500px
Comment on attachment 8603434 [details] [diff] [review]
1160281-Add-support-for-webkit-transform-origin.patch

>+++ b/layout/style/test/unprefixing_service_iframe.html
>+  // -webkit-transform-origin: <value> maps directly to "transform-origin"
>+  { decl: "-webkit-transform-origin: 0 0",
>+   targetPropName: "transform-origin",
>+   expectedDOMStyleVal:  "0px 0px 0px",
>+   expectedCompStyleVal: "0px 0px" },

Nit: These 3 lines need 1 more space of indentation.

r=me with that
Attachment #8603434 - Flags: review?(dholbert) → review+
(Is there any known difference in syntax between the prefixed & unprefixed versions in webkit-derived browsers, or are they just aliases as far as we know?)
Thanks for the review!

As far as I know, there are no reported differences between prefixed and unprefixed syntax. I spent a while trying to track things down on blogs, mailing lists and the Chromium bug tracker but didn't come up with anything. Nothing of note in the resources tab of caniuse [1] or Blink's intent to unprefix [2].

[1]http://caniuse.com/#feat=transforms2d
[2]https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/vjyd8It--3Y
Addressed nits and carrying forward r+.

Let's see how Try feels about this: https://treeherder.mozilla.org/#/jobs?repo=try&revision=900f57e8072e
Attachment #8603434 - Attachment is obsolete: true
There's some timeouts and some e10s bc1 failure that seem entirely unrelated, so setting to checkin-needed.
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/39c35b0c2e04
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
You need to log in before you can comment on or make changes to this bug.