Open Bug 1017889 Opened 10 years ago Updated 2 years ago

[regression] backface is now visible in an old demo of a CSS rotation transform

Categories

(Core :: CSS Parsing and Computation, defect)

Other
Other
defect

Tracking

()

People

(Reporter: bugs, Unassigned)

References

()

Details

So, a quick test in a nightly from 2012-12-12 shows that the backface hides properly there.
Also, oddly, the demo in the link at the top of the page, that this was drawn from, works fine.

The backface doesn't work in chrome either, but chrome was rather late to handling backface correctly so it could be an implementation bug.

Nonetheless, given two browsers are voting against this page, it might be some flaw in the actual page, but figured it couldn't hurt to file a bug and see what you guys think.
Do you know what this is, or would a regression window help?
Flags: needinfo?(matt.woodrow)
This is almost certainly a regression from 968555.

I'm not sure, but it seems like we're following spec here.

backface-visibility:hidden is set on the <a class="face"> element, but the image is drawn by a descendant of that, the <img>.

The spec only talks about the backface of the element being hidden, not the backface of descendents. backface-visibility also doesn't establish a containing block or stacking context.

I think you want/need transform: translate(0px); (or similar no-op transform) on the elements with backface-visibility:hidden. This will establish a stacking context for that element and cause all descendent elements to be rendered into it, before the hidden rules are applied.
Flags: needinfo?(matt.woodrow)
huh. That's odd and inconvenient.  So if you do any particularly complex layout, you have to set backface visibility on every single descendent?  Makes me wonder what other demos out there might be broken.
Nevermind. I reread and got how I failed.
I was transforming at the <figure> level, but hiding at the image level. Which frankly doesn't make much sense anyway.
http://m8y.org/tmp/testcase248b.xhtml
corrects that, and it does indeed work fine in Firefox.
... well, doesn't make sense in this case.  I imagine there are times you might want only parts of a transform to have visible backfaces, but in that case your noop thing would probably work just fine.

Thanks. I suppose this gets closed out invalid?
So this is maybe mildly interesting.  After I push backface visibility to the <figure>  the backface hiding works correctly, however the shadow in figure::after disappears while :active.

I'm guessing that's not a bug either, although it happened even when I tried setting backface-visibility: visible in figure:active::after.
No idea why, but I switched to your 0 deg transform on the <a> and <figcaption> after all in http://m8y.org/tmp/testcase248c.xhtml and that fixed things nicely.

Also, FWIW, my testing Chromium means nothing, because as far as I can tell, none of the backface-visibility demos I've tried appear to be working in my Chromium 34, whether -webkit-backface-visibility is set or not.
It looks like a regression to me. I just saw this bug introduced on http://www.cocones.com/products/leather-card-wallet-smokey-grey-black — images flipped on hover stopped revealing images on the reverse side today in FF 30. The feature was introduced in April 2013 and worked up until Firefox 29.0.1 (I just checked on another computer before and after upgrading FF on it).

The way I see it, backface-visibility: hidden on front images stopped working.

Setting transform: translate(0px); on descendants does not fix the problem.

Interestingly though, this demo the feature is based on, still works:
http://desandro.github.io/3dtransforms/examples/card-02-slide-flip.html

OSX 10.9.3, FF 30.0
I fixed this in HTML on cocones.com, changing the html order of cards(sides) to "front back" from "back front" (they were initially reversed to fix a display issue in IE but I am willing to sacrifice it now). 

Here the problem is preserved, based on the original DeSandro demo:
http://stagingpad.com/fliptest/flip-test.html
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.