Test case: data:text/html,<!doctype html> <body> <script> alert(getComputedStyle(document.body).MozTransformOrigin) </script> alerts "50% 50%" in 12.0a1 (2012-01-06) on Ubuntu 11.10 32-bit. In IE9, Chrome 17 dev, and Opera Next 12.00 alpha it's in pixels, like "468px 0px". (Obviously, I'm changing MozTransformOrigin to the appropriate prefixed variant.) Also, in Gecko, data:text/html,<!doctype html> <body style=-moz-transform:translate(1px)> <script> alert(getComputedStyle(document.body).MozTransformOrigin) </script> alerts in pixels, like "472px 0px". The CSS 2D Transforms spec doesn't technically say what to do here. But all non-Gecko UAs seem to interoperably return pixel values, and so does Gecko in the interesting case (i.e., when there's a transform other than "none"). I filed a spec bug suggesting the spec say to always return pixels: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15433 I suggest Gecko change to do this too, to match other browsers.
This seems to be quite purposeful: nsComputedDOMStyle::GetFrameBoundsWidthForTransform returns false if not transformed. David, do you happen to know why? That check was in the original landing of all this code in bug 435293 and I see nothing about it in the bug. That said, per current spec we should be alerting "50% 50%" in both cases here. Are there pending spec changes or something?
The current spec actually doesn't define a .transformOrigin property at all, in <http://dev.w3.org/csswg/css3-transforms/#dom-interfaces>, so the format isn't defined AFAICT. That's <https://www.w3.org/Bugs/Public/show_bug.cgi?id=15433>. Are you looking at a different spec? Or are you figuring the format of .transformOrigin should follow the "Computed value" entry in the transform-origin definition? Either way, always returning pixel values seems like the right thing to spec based on current browsers' behavior. It's simpler for authors, too.
> The current spec actually doesn't define a .transformOrigin property at all The relevant spec is http://dev.w3.org/csswg/cssom/#dom-window-getcomputedstyle which claims that the resolved value is the computed value for all but a small list of properties; see http://dev.w3.org/csswg/cssom/#resolved-value And the computed value is defined in the transforms spec, in the "Computed value" entry as you note. It's too bad UAs are already ignoring the CSSOM spec drafts.... :(
Aha, I see. Thanks -- I've mostly been working with DOM so far, so my CSS isn't always so great. Personally, I'm fine with sticking with the current spec, if implementations are willing to change to match. Gecko needs to change anyway -- which way does it want to go?
We should probably just match the other UAs and "fix" the spec...
(In reply to Boris Zbarsky (:bz) from comment #3) > > The current spec actually doesn't define a .transformOrigin property at all > > The relevant spec is > http://dev.w3.org/csswg/cssom/#dom-window-getcomputedstyle which claims that > the resolved value is the computed value for all but a small list of > properties; see http://dev.w3.org/csswg/cssom/#resolved-value I'm not at all confident that spec is stable enough to change UA behavior based on. (I think it may still be in the stage where we're more likely to change the spec based on UAs.)
The same issue exists for perspective-origin.
Summary: getComputedStyle().MozTransformOrigin sometimes returns percentages → getComputedStyle().MozTransformOrigin and MozPerspectiveOrigin sometime return percentages
Created attachment 595137 [details] [diff] [review] Patch Patch attached, some tests run but not all so there might be new failures I don't know about. Comment #1 suggests it's not clear yet whether we want this, so should I request review or not?
Assignee: nobody → ayg
I think you should probably request review.
Attachment #595137 - Flags: review?(roc)
Attachment #595137 - Flags: review?(roc) → review?(bzbarsky)
Comment on attachment 595137 [details] [diff] [review] Patch r=me
Attachment #595137 - Flags: review?(bzbarsky) → review+
Autoland Patchset: Patches: 595137 Branch: mozilla-central => try Destination: http://hg.mozilla.org/try/rev/592efbbd58f2 Try run started, revision 592efbbd58f2. To cancel or monitor the job, see: https://tbpl.mozilla.org/?tree=Try&rev=592efbbd58f2
Try run for 592efbbd58f2 is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=592efbbd58f2 Results (out of 212 total builds): success: 192 warnings: 20 Builds (or logs if builds failed) available at: http://firstname.lastname@example.org Timed out after 06 hours without completing.
None of the test failures seem related.
Target Milestone: --- → mozilla13
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.