Open Bug 736253 Opened 14 years ago Updated 3 years ago

Handle CSS transforms of root element's background per spec

Categories

(Core :: Layout, enhancement)

Product:
Core
Component:
Layout
Type:
enhancement

Tracking

()

People

(Reporter: ayg, Unassigned)

References

Details

Spec bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15834 Reftests: http://hg.csswg.org/test/rev/a240ed94de4f More reftests: http://hg.csswg.org/test/raw-file/892c3ee4d42e/contributors/aryehgregor/incoming/ref-2d/background-2c.html http://hg.csswg.org/test/raw-file/892c3ee4d42e/contributors/aryehgregor/incoming/ref-2d/background-2d.html http://hg.csswg.org/test/raw-file/892c3ee4d42e/contributors/aryehgregor/incoming/ref-2d/background-2-ref.html The transforms spec previously said nothing about how the root element's background gets transformed. It now says """ If the root element is transformed, the transformation applies to the entire canvas, including any background specified for the root element. Since the background painting area for the root element is the entire canvas, which is infinite, the transformation might cause parts of the background that were originally off-screen to appear. For example, if the root element's background were repeating dots, and a transformation of ‘scale(0.5)’ were specified on the root element, the dots would shrink to half their size, but there will be twice as many, so they still cover the whole viewport. """ http://dev.w3.org/csswg/css3-transforms/#transform-rendering Gecko seems to just ignore transforms for the root element. This is bad, because it means html { transform: rotate(180deg) } will rotate everything on the whole page except the root element's background, which is unexpected.
I really doubt we ignore transforms on the root. For example, we presumably rotate the root's border. It sounds like we should propagate the root's transform to the canvasframe, though.
Yeah, I meant "for the root element's background", not "for the root element". My bad.
I sort of wish the spec didn't special-case transforms on the root element to transform the canvas. Propagating stuff from the root element to the canvas is always a pain. Is there a real need for the spec to say that?
Well, the spec doesn't *have* to say it. I suggested it in the W3C bug <https://www.w3.org/Bugs/Public/show_bug.cgi?id=15834>, and no one objected, so I changed the spec. The problem with making transforms not affect the root element's background is that it means html { transform: rotate(180deg) } or something will rotate the entire page *except* if the root element happens to have a background image, in which case it will rotate everything except that. I don't think that's correct. But if you want to suggest that the spec instead say the root element's background is unaffected by any transforms, I could change it back. That's closer to how most browsers behave right now. I just don't think it's as useful, in the corner cases where it's relevant.
(In reply to Aryeh Gregor from comment #4) > Well, the spec doesn't *have* to say it. I suggested it in the W3C bug > <https://www.w3.org/Bugs/Public/show_bug.cgi?id=15834>, and no one objected, > so I changed the spec. The problem with making transforms not affect the > root element's background is that it means html { transform: rotate(180deg) > } or something will rotate the entire page *except* if the root element > happens to have a background image, in which case it will rotate everything > except that. I don't think that's correct. Would you have it transform the viewport scrollbar or not? > But if you want to suggest that the spec instead say the root element's > background is unaffected by any transforms, I could change it back. Technically it's not the root element's background, but the canvas background. > That's > closer to how most browsers behave right now. I just don't think it's as > useful, in the corner cases where it's relevant. Yeah, I guess authors would find not rotating the canvas background to be surprising. I guess we should just fix this.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #5) > Would you have it transform the viewport scrollbar or not? I'd say no. I could add that to the spec, but I expect everyone will get that right. > Technically it's not the root element's background, but the canvas > background. Yep.
So, do you want to fix this? :-)
If you give me some pointers on where I should start, sure.
We need to propagate the transform from the root element's frame to the nsCanvasFrame. So we have to do two things: make sure that nsCanvasFrames get the right transform, and make sure that their child frames aren't transformed. For the latter, nsFrame::Init could check the type of the parent frame before setting the MAY_BE_TRANSFORMED flag, and bail out if it's a canvas frame. For the former, nsCanvasFrame::SetInitialChildList/InsertFrames/AppendFrames/RemoveFrame could check the child's GetStyleDisplay()->HasTransform(), and set MAY_BE_TRANSFORMED based on that. The harder part is that everywhere we get the transform from nsStyleDisplay, we need to check if it's a canvas frame and if it is, get the style from the child instead. For that we'd want a helper function similar to nsCSSRendering::FindBackground. Hmm ... for transforms on the root element, should transform logic that depends on the element's geometry use the canvas's geometry instead?
I don't think I can do this right now, because my computer is getting packed on a lift soon and I won't have access to it for a few weeks. I probably won't be doing a whole lot of dev work on my comparatively puny laptop. Maybe later. (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #9) > Hmm ... for transforms on the root element, should transform logic that > depends on the element's geometry use the canvas's geometry instead? Like what? Percentages in the transform and perspective origins should go by the geometry of the root element, not the canvas.
See Also: → 1610255
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.