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!

Cool, will start on this tomorrow.

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

(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

Great, thanks!

Addressed nits and carrying forward r+. Let's see how Try feels about this: https://treeherder.mozilla.org/#/jobs?repo=try&revision=900f57e8072e

There's some timeouts and some e10s bc1 failure that seem entirely unrelated, so setting to checkin-needed.