Closed Bug 715946 Opened 13 years ago Closed 12 years ago

getComputedStyle().MozTransformOrigin and MozPerspectiveOrigin sometime return percentages

Categories

(Core :: DOM: CSS Object Model, defect)

Product:
Core
Component:
DOM: CSS Object Model
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla13

People

(Reporter: ayg, Assigned: ayg)

Details

Attachments

(1 file)

Patch
6.22 KB, patch
bzbarsky
: review+
Details | Diff | Splinter Review 
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
Attached patch Patch — — Splinter Review 
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+
Whiteboard: [autoland]
Whiteboard: [autoland] → [autoland-in-queue]
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://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/autolanduser@mozilla.com-592efbbd58f2
 Timed out after 06 hours without completing.
Whiteboard: [autoland-in-queue]
None of the test failures seem related.
Keywords: checkin-needed
Flags: in-testsuite+
https://hg.mozilla.org/mozilla-central/rev/fd7620f86092
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: