Test case: data:text/html,<!doctype html> <body style=-moz-transform:scale(1)> <script> document.body.textContent = getComputedStyle(document.body).MozTransform </script> Firefox 12.0a1 (2012-01-17) outputs "matrix(1, 0, 0, 1, 0px, 0px)". All other browsers (IE9, Chrome 17 dev, Opera Next 12.00 alpha) omit the "px" part. See <https://www.w3.org/Bugs/Public/show_bug.cgi?id=15431>. Other browsers omit the "px", of course, because they don't support it (bug 719054, <https://www.w3.org/Bugs/Public/show_bug.cgi?id=15628>). But even if bug 719054 winds up WONTFIX, I still think "px" should be omitted from computed styles: * The matrix works in all browsers without "px", including Gecko, but only in Gecko with "px". * A length or percentage is always resolved to "px" anyway, so the length unit never adds anything. It's not like Gecko outputs things like "50%" in the last entries, where you'd lose information by converting to pixels. * Without "px" it's shorter. * All other browsers omit "px" already, so if we want interop, the no-"px" behavior is easiest to converge on. I can see the advantages to *accepting* length units in these entries, but not *outputting* them.
Created attachment 595748 [details] [diff] [review] Patch v1 David Baron said in bug 719054 comment 1 that <length>/<percentage> should still be accepted in matrix()/matrix3d() until we unprefix. But even if that's the case, I don't see any reason why it should be output in getComputedStyle().
Autoland Patchset: Patches: 595748 Branch: mozilla-central => try Destination: http://hg.mozilla.org/try/rev/a88990c581cb Try run started, revision a88990c581cb. To cancel or monitor the job, see: https://tbpl.mozilla.org/?tree=Try&rev=a88990c581cb
Try run for a88990c581cb is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=a88990c581cb Results (out of 211 total builds): success: 178 warnings: 19 failure: 14 Builds (or logs if builds failed) available at: http://firstname.lastname@example.org