The spec describes a behavior for background-attachment:fixed where the transformed element behaves as if it were a "porthole" through which the fixed background shows.
This is tricky, but implementable for 2D transforms, but very difficult for implementors of 3D transforms.
We may wish to punt and just say that any background-attachment:fixed on an element that is transformed, or has a transformed container, behaves like background-attachment:scroll.
I'm okay with this if implementers agree. What do other implementers think? If it's easy for some implementers but not others, and if we agree that the proposed behavior is a punt and not really correct, I'd say we should leave the spec more "correct" for now even though we know not all implementations will be able to make it -- much like for intersections.
Another option is to say that you draw the same piece of background as though there were no transforms, and then you transform it.
Created attachment 1145 [details]
IE10 Release Preview does what David suggests i.e.:
1. Render the fixed background as if there were no transform
2. Transform the result from #1
As a result:
- Subsequent adjustments to the position of the element preserves the 'porthole'-like behavior of background-attachment:fixed i.e. as the element moves around its background continues to adjust
- But any transform applied to the element applies to the rendering of the fixed background within that element.
(In reply to comment #2)
> Another option is to say that you draw the same piece of background as though
> there were no transforms, and then you transform it.
This is also what we already do (although we don't get the invalidation right when scrolling), and it's our preference as well.
Proposal at <http://lists.w3.org/Archives/Public/www-style/2012Jun/0635.html>
Consensus is to follow my proposal.
One final question: for an element with a transform or transformed ancestor, what's the computed value for background-attachment, if the specified value is 'fixed'?
Leaving bug open for the computed style issue.
My inclination is that it's better for the computed value not to change (i.e., still be 'fixed' even if it won't actually be fixed).
I would also background-attachment's computed value to remain 'fixed' in thie case; the property's computed value is 'as specified' and I'd rather leave it that way. We're only changing the used value.
*** Bug 19636 has been marked as a duplicate of this bug. ***
We resolved that the computed values are not affected.
Do we need to state this on the spec?
What about this sentence at the end of the paragraph, right before the issue text: "The computed style of 'background-attached' is not affected." If it is ok, I go ahead and do the change.
The same issue applies to transform-style when combined with opacity. I think it's fine to say that the computed value of the property is not affected.
Fixed after 177d757a1f34.