Z-index breaks on Chrome when using transitions with scale - vue.js

A demo of the bug can be found here: https://github.com/Twinbird24/vue-scale-transition-example/tree/simplified
A video demonstration of the bug can be found here: https://gofile.io/?c=4HwzAT
Here is the code on Stackblitz: https://stackblitz.com/edit/vuejs-starter-ndpy8b?file=styles.css. Click on the css file (styles.css) to change the scale and you'll discover the bug.
The code found in the GitHub/ Stackblitz linked above contains two divs that are fading in and out through the use of Vue transitions. There is a third div that is absolutely positioned above these transitioning divs. The bug appears when you change the scale of the container that holds all of these divs (look for the commented CSS for the source of the bug). After a certain point, the z-index of the third absolutely positioned div will break, and it will become covered up by the transitioning div. This bug appears in Chrome, but doesn't seem to be apparent in Firefox.

Related

Why does Safari not display some elements even though web inspector shows they are there

I am struggling with an application using custom elements that is just not working properly in Safari. Here is a screen shot with what Safari is showing v what it is supposed to show in chrome. It was taken on a Macbook Air, although I originally discovered the issue on an iPad.
However this screen shot shows that web inspector does think there is an element there whose foreground color is white and opaque (I set those deliberate) even though nothing is displayed.
So why is Safari not displaying the elements?
For anyone else out there wondering about the same thing. I think I found the answer!
One of the surrounding elements has some css with overflow-y: auto, but without a specific height. I believe what is happening is that safari has shrunk that element to height 0, but that the inspector is still showing where the element would have been, if its not been hidden by a zero length scroll bar, scrolled so that item is below the cutoff area of the scrollable element.
I haven't yet figured out why it works in chrome, my guess is slightly different handling of overflow.

Is there a way to prevent my CSS keyframe animation from starting until that element scrolls in view?

I've used keyframes to animate the entrance of some elements onto my page, however the elements are located at the bottom of the page, so the animation takes place before you see them.
Is there a way to stop the animation from happening until the user scrolls into view of the elements? Preferably not a jQuery solution since I am not familiar with it.
Note: I know there is a library called wow.js that solves this issue, but it uses animate.css for it's animations. This is a problem for me because I was using animate.css originally but it was overwriting/conflicting with some other css I had. That is why I switched to using keyframes for the animations, and in order to have all the properties of elements working correctly I believe I have to stay with keyframes rather than animate.css
I found my own answer! Wow.js still works because you don't have to necessarily use animate.css animations, you can still use your own custom animations.

Pseudo element animations doesn't work in Safari and iOS

I'm using web components in a shadow dom, and all animations work fine in Chrome. However, in Safari and thus iOS Safari, the animations on elements work fine, but not on pseudo elements. This baffles me, because it's ONLY on pseudo elements like :after and :before.
There is nothing wrong with the code, because when I run it without a shadow dom everything triggers just fine and works perfectly in all browsers.
Why is this, and how can I remedy this problem?
I've tried setting important on the animation css, didn't work.
Tried moving #keyframes higher up in the shadow dom, didn't work.
Tried including the #keyframes in the document that includes the shadow dom, this worked.
However, I'd prefer not to solve it like this because then I have to include a shared animation css asset in both the main document and the document that is meant to be included via shadow dom. And it's still weird that the normal animations work, but not pseudo elements. The pseudo elements are there, the ONLY thing lacking is that the animation doens't trigger.

Polymer paper-fab with position:fixed behaves strangely when used with core-list that has a scrollTarget

I took the polymer demo messages example, put it into a jsbin and then edited it to pull out the list and fab into a separate polymer element. In other words pretending that we wanted to make the inbox editor a reusable component.
This more closely resembles my application, as I have broken it into many such components to make it more modular (one of the great benefits of web components IMO).
As the fab is part of this new element then leaving it position absolute puts it at the very bottom off the list rather than always bottom right of the window.
To fix that I simply changed it to position fixed. See this jsbin
It loads fine but when you start scrolling (in latest chrome) the fab scrolls with the list content, instead of remaining fixed at the bottom right.
Interestingly if you click the mouse on the bottom right of the window (where the fab should have been) the fab jumps down to the right place. Now when you scroll it remains in the correct position.
Very strange. Any ideas of the cause and whether I am doing something wrong or it is a polymer bug?
After a quick googling around I found that adding -webkit-transform: translateZ(0); to paper-fab element fixes it to the viewport.
Working jsbin
Related question: position:fixed not working in Google Chrome
I have no idea why this happens, the only vaguely relevant bug that I found is https://code.google.com/p/chromium/issues/detail?id=420534 but it's the other way round: it's about transform: translateZ(0); on parent element that makes its children scrolling and not fixed.

CSS transition and fixed positioning in Safari

I'm having some issues with a website that only occur in Safari. I'm running version 5.1.7 (7534.57.2) on a Mac.
You can view the site here: http://mcad.edu/annual-report-2011-12/.
The website is parallax scrolling, with a relative positioned content div that holds everything, including the 3 parallax scrolling backgrounds which are all fixed, top and left set to 0.
Within the fixed parallax background containers, colorized images fade into full color images when a user mouses over them. For each "image", there are two divs stacked, each with background images that are positioned by background-position. The div on the bottom has the colorized image. The div on top has the full color image as a background and has its opacity set to 0 until mouseover. The fade is achieved using a CSS transition on the opacity property so that the top div becomes visible.
So, in Safari only, when I mouse over any of these divs, the transition occurs smoothly but all of the content in the same parallax scrolling background div shifts/jumps in the process. If I remove the CSS transition, this does not occur.
I think that it might have something to do with the transition/webkit-transition property not playing nicely with a fixed position container in Safari. However, all of the issues I've found that relate to that are from 2010 and mention a Safari bug that I assume has been fixed…two years later. But maybe not.
There's also another issue with the Catalyst section (3rd dot down on the right navigation). These animated images work as links in Chrome, Firefox and Opera, but not Safari. Any ideas?
I have a similar issue with a fixed position and transition-duration for a header menu I've created. When a visitor scrolls down, the menu has a box shadow that fades into place. Well when this is viewed on safari in a MacOS, I get a weird sliding in issue. To easily fix this, after spending way to much time searching for answers, I'm removing the transition effect for macs. This fixes the slide in issue but gets rid of the transition effect sadly.
So as you were speculating, it probably is the transition duration on your project as well. The best thing for this would probably be to make a Mac-Safari CSS file, get rid of the transition-duration for that particular area and move on with your project.
Best I can suggest for now. Hope it helps.