Open Bug 716524 Opened 13 years ago Updated 4 months ago

'perspective' only affects child nodes, not further descendants

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
10 Branch
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

Project Flags:
blocking-kilimanjaro -

People

(Reporter: ihuzum, Unassigned)

References

Details

Attachments

(3 files)

perspective.html
1.02 KB, text/html
Details
Expected result
16.80 KB, image/png
Details
Result
11.72 KB, image/png
Details
Attached file perspective.html — 
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7

Steps to reproduce:

Created perspective.html:
- root element has perspective
- parent element has transform-style: preserve-3d
- child elements have float:left and rotateY with different degrees


Actual results:

Child elements are not rendered with perspective. (see attachment result.png)


Expected results:

Child elements should be rendered with perspective (see attachment expected.png)
Attached image Expected result — 

    
    

    
  

      
      
      
      

        Attached image
          
        Result
        — 
      

    


  

    
    

    
  
Corrected User Agent:
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20100101 Firefox/10.0

    
    

    
  
This is correct according to the spec, as I read it:

"""
multiply the accumulated matrix with the perspective matrix on the element's containing block (if any). That contining block is not necessarily a member of the 3D rendering context.
"""
http://dev.w3.org/csswg/css3-transforms/#transform-3d-rendering

So the only perspective that's respected is the perspective on the containing block, not on any of its ancestors.  This is how both Firefox 13.0a1 and IE 10 Developer Preview behave.  However, Chrome 18 dev respects perspective even on ancestors that are higher up.  Test-case (add prefixes as appropriate):

data:text/html,<!doctype html>
<div style="perspective: 500px;width:100px">
<div>
<div style="height:100px;background:lime;
transform:rotatey(45deg)">

I see perspective in Chrome but not IE/Firefox.  WebKit's behavior here is very weird -- it treats "perspective: none" the same as "perspective: inherit" if the element isn't in a 3D rendering context, and the same as no perspective if it is, or something like that.  But maybe we want to match WebKit regardless, because there might be existing content written for it.  In that case, we should get the spec changed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Transform rotateY with parent transform-style: preserve-3d does not apply perspective → 'perspective' only affects child nodes, not further descendants

        Attachment #586976 -
        Attachment mime type: text/plain → text/html

    
    

    
  
(In reply to Aryeh Gregor from comment #4)
> In that case, we should get the spec changed.

+1 for pushing for an amend to the spec, although WebKit's behaviour doesn't follow the spec it does make more sense (to me at least) and doesn't require repetitive CSS on descendants.

For reference I have a test case on this blog post: http://blog.joelambert.co.uk/2012/02/13/3d-transformations-with-firefox-10/

    
  
Component: Untriaged → Layout
Product: Firefox → Core
QA Contact: untriaged → layout

    
    

    
  
nom for k9o Webkit css transforms compat http://blog.joelambert.co.uk/2012/02/13/3d-transformations-with-firefox-10/
blocking-kilimanjaro: --- → ?

    
    

    
  
Jet, can you please comment on whether you think this bug should block k9o?

    
    

    
  
We're not blocking unprefixing (bug 745523) on this so I think k9o- is OK.

    
    

    
  
Going on Jet's recommendation I'm marking k9o-. We should renom if there are specific top sites that are impacted by this bug.
blocking-kilimanjaro: ? → -
Webcompat Priority: --- → ?
Webcompat Priority: ? → P3

    
  
Severity: normal → S3

    
    

    
  
StreamPowered no longer seems to use the perspective effect, and the other linked codepen is working fine on Firefox now, so we have no known webcompat breakage here anymore. Unsetting the webcompat priority for now.


Webcompat Priority: P3 → ---

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: