fa-translate breaks the rendering of surfaces when z is set to anything but 0

[steveblue]

If we translate on the z with fa-translate, surfaces get deployed but are not painted in the window.

In the latest build, if we comment out transform-style:preserve-3d on the .famous-angular-container but leave it elsewhere in the css this bug is fixed and 3D transformations still work.

This may be a chrome specific bug.

[bguiz]

If I put my renderable nodes (fa-surfaces or fa-*-layouts) nested inside of an fa-modifier, and put the fa-translate on the fa-modifier, everything works fine, and I believe this to be the recommended approach.

Are you placing fa-translate directly on the renderable nodes, by any chance? Can you post a sample HTML snippet that demonstrates this problem?

[steveblue]

We are using the approach you recommend. i.e.

<fa-modifier fa-translate="[0,0,100]">
<fa-surface></fa-surface>
</fa-modifier>

[bguiz]

Hmm, that works without issue for me though. On both chrome and firefox. Sorry I couldn't be of much help!

[steveblue]

Maybe we have some sort of conflict with our main app CSS. Everyone on my team can replicate the issue.

[zackbrown]

I am also unable to reproduce this on my end: have you had any luck determining if this is related to CSS conflicts? Would you be able to paste the contents of the famous-angular.css you're working off of into a gist?

[steveblue]

I can reproduce this problem on another project I am working on based off the famous-angular-stater repo. When the z of both modifiers is the same, the view will render. When the z is different, the view will not render. The surfaces are deployed but the window is not painting the elements in Chrome, Safari, and Firefox. When I remove 'transform-style:preserve-3d' on the '.famous-angular-container' , the difference in z translation of these surfaces is drawn and the elements still have perspective. In Firefox, the elements won't even paint until I adjust '.famous-angular-container' as described above. This also means it is not problem caused by conflicting CSS in our web app.

<fa-app class="full-screen">
  <fa-modifier fa-size="scroll.size">
  <fa-surface class="grid-background" fa-pipe-to="pageScrollHandler"></fa-surface>
  </fa-modifier>

  <fa-scroll-view fa-pipe-from="pageScrollHandler">
  <fa-modifier fa-size="scroll.size">
        <fa-grid-layout fa-options="options">
        <fa-modifier ng-repeat="photo in model" fa-size="grid.item.size">
          <fa-modifier fa-translate="[0,0,10]">
           <fa-surface class="grid-item" fa-pipe-to="pageScrollHandler">

             <img ng-src="img/{{photo.image_url}}">

           </fa-surface>
          </fa-modifier>
          <fa-modifier fa-translate="[0,0,0]">
           <fa-surface class="grid-item-info" fa-pipe-to="pageScrollHandler">

             <h2>{{photo.name}}</h2>
             <p>{{photo.description}}</p>
             <ul class="grid-item-share">
                <li>{{photo.votes_count}} Votes</li>
                <li>{{photo.favorites_count}} Favorites</li>
             </ul>
           </fa-surface> 
          </fa-modifier>
        </fa-modifier>
        </fa-grid-layout>
  </fa-modifier>  
  </fa-scroll-view>
</fa-app>

[kilianc]

I have I maybe related problem where surfaces with the same translate.z change z order randomly when (I think) recycling DOM nodes.

[bguiz]

@kilian that sounds like something that I would expect famo.us to do on its own, and is possibly unrelated to famous-angular. Can you try to reproduce it using just famo.us? On 15 Nov 2014 04:32, "Kilian Ciuffolo" notifications@github.com wrote:

I have I maybe related problem where surfaces with the same translate.z change z order randomly when (I think) recycling DOM nodes.

— Reply to this email directly or view it on GitHub https://github.com/Famous/famous-angular/issues/186#issuecomment-63100039 .

[jordanpapaleo]

@steveblue Is this still a valid issue? Thanks - Jordan

[steveblue]

Oh, yeah still an issue, please reopen. A lot of people have been able to reproduce.

[steveblue]

Please read my comment from before that seems to fix this bug.