This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The spec currently contains this issue: """ What do fixed backgrounds do in transforms? They should probably ignore the transform completely, since - even transformed - the object should be acting as "porthole" through which the fixed background can be viewed in its original form. """ http://dev.w3.org/csswg/css3-transforms/#transform-functions Test-case 1 (assume "image" is the URL of an image, e.g. at http://software.hixie.ch/utilities/js/live-dom-viewer/): data:text/html,<!doctype html> <body style=margin:0> <div style="height:100px;width:100px; background:url(image) fixed;border:1px solid black; transform:translate(50px)"></div> <div style="height:100px;width:100px; background:url(image);border:1px solid black; transform:translate(50px)"></div> <div style="height:1000px"></div> IE9 and Opera Next 12.00 alpha display the two differently, transforming the regular background image but not the fixed one; scrolling leaves the fixed-position background in place. Firefox 13.0a1 displays the two the same, transforming both, and scrolling causes both to scroll -- there's no difference at all. Chrome 18 dev displays the two the same, transforming both, but scrolling causes only the second background to scroll; the first remains in place. Test-case 2: data:text/html,<!doctype html> <body style=margin:0> <div style="height:100px;width:100px; background:url(image) fixed;border:1px solid black; transform:rotate(90deg)"></div> <div style="height:100px;width:100px; background:url(image);border:1px solid black; transform:rotate(90deg)"></div> <div style="height:1000px"></div> Here, every browser rotates both background-images in some fashion, but the details vary. IE9 rotates the first and second images somewhat differently (looks like a different transform-origin), and the first stays fixed when you scroll. Firefox 13.0a1 treats them identically. Chrome 18 dev has them look identical if you don't scroll, but if you scroll something weird that I don't understand happens to the first one (it translates somehow). Opera Next 12.00 alpha also does something weird with the first one. IMO, there are only two behaviors that make sense: either the background-image is totally unaffected by the transform except for which parts are visible (no browser does this); or elements with transform other than "none" are treated as roots for fixed backgrounds, just like for position: fixed (Firefox does this). Since no browsers do the first and one browser does the second, I suggest we go with the second behavior, and change "The object acts as a containing block for fixed positioned descendants." to "The object acts as a containing block for fixed positioned descendants and fixed backgrounds." or similar. I don't see why fixed backgrounds should differ from fixed-position elements. If I write a bookmarklet that sets transform:rotate(180deg) on the current page, it should rotate everything, not everything except fixed backgrounds. The fixed background should then stay fixed to the transformed element, not the viewport.
Actually, I take back what I said. No one seems to treat transformed elements as roots for fixed backgrounds. So for instance, transform:translate(0) shouldn't affect the display of a fixed background (even though it will affect fixed-position descendants). This is true in IE10 Developer Preview, and Opera Next 12.00 alpha; it is not true in Firefox 13.0a1 or Chrome 18 dev, which seems wrong. On the other hand, if any browser followed the spec's suggestion, it would imply translate:rotate(90deg) on a square box wouldn't affect fixed backgrounds at all, since it wouldn't change the shape or position of the "porthole" you view the image through. No browser does this. I admit to being completely confused. What behavior should we require? Every browser treats fixed backgrounds differently for transforms right now.
Thinking about it some more, I observe the following: 1) Saying that you first paint the fixed background in the box's original position, then transform it along with the box, looks really really weird. For instance, if you have rotate(90deg), then when you scroll down, the image moves *sideways*. This is what WebKit and Opera seem to do in my test-case 2 from comment #0. I don't think it's desirable. 2) If I do html { transform: rotate(180deg) }, I would expect the effect to be the same as turning my monitor upside-down. I don't think fixed backgrounds should remain right-side-up in this case. Likewise for any other transform on the root element. It should transform the whole canvas. (See also bug 15834.) Thus I propose as follows: fixed backgrounds are affected by any transforms on the *root* element, but unaffected by any other transforms. This means that the element is still a "porthole" on the fixed background, in that if you scroll part of the element out of view, the background keeps locked to the viewport. But it also means that transforms on the root element don't mysteriously leave certain parts of the page untransformed. Does this make sense to anyone else, or am I crazy? (This doesn't match any browsers, FWIW, but I don't think any browsers are sane here.)
So I suggest something like """ Fixed backgrounds are affected by any transform specified for the root element, and not by any other transforms. (Note: Thus an element with a fixed background still acts like a "porthole" into an image that's fixed to the viewport, and transforms on the element affect the porthole, not the background behind it. On the other hand, transforming the root element will still transform everything on the page, rather than everything except for fixed backgrounds.) """ where the note is non-normative (class="note"?). Any objections? Again, this doesn't match what any browser does currently, but browsers currently don't make much sense and I'm pretty sure their behavior is accidental.
Since no one objected, I went ahead and made the change: http://dvcs.w3.org/hg/csswg/rev/cae1918b58d7 Reopen if you object.
Tests added: http://hg.csswg.org/test/rev/41a7369b5bf3
Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=735857