Keeping style applied using :hover until transition complete? - css

I have a bunch of tiles on a page that expand as the user mouses over them. The expanded one should have the highest z-index, and this works, but I need the z-index to remain until the size transition is complete. Is there a way to do this using CSS only, no JavaScript? Since I'm using transitions, I'm not too worried about compatibility here, I applied progressive enhancement correctly.
Here's a jsFiddle that demonstrates this. Mouse over A; it transitions out. Mouse off of it, however, and it falls behind B. I need it to stay in front of B until the transition completes. Is there an elegant way to do this?

You need to define the z-index, as well as animate it.
This works in Firefox (8.0.1) and Webkit.

You need to set z-index to transition too: http://jsfiddle.net/uHJwT/2/

Try using transitions like in http://jsfiddle.net/frozenkoi/YK52N/ (note the comments in the CSS section, for both the .item and .item:hover)
The trick is to use transitions for the z-index property too. You can set, for example, a value of 10 for the normal items and 11 for the hovered ones. You also have to use transition-delay so that the animation for moving the mouse out doesn't reset the z-index inmediately. Next, add a different value to transition-delay to the rule for :hover with a value of zero so that the z-index does update inmediately when the mouse goes into the item.
In short, .item has the transition for mouse out of the item and .item:hover the rules for when the mouse moves in.

Here's the one solution: http://jsfiddle.net/uHJwT/4/
Essentially, it uses another wrapper div that has sufficient width & height to cover animated surface - on hover, it elevates its z-index so that the animated div remains on top. Of course, this is not full-proof solution - it is based on the fact that typical hover off would be down movement and it works for that - but hover off in diagonal direction would not work. But seems to be a reasonable CSS only solution - I would rather used js to get a perfect one.

Related

Why doesn't this animation appear in DevTools Animations tab?

I am attempting to work out how Invision's blog animation works. Specifically the zoom and shading on the title image pictured below when scrolling.
I would have thought this would be a CSS animation, but it doesn't appear in Chrome DevTools 'Animations' tab.
How does this animation work, and why doesn't it appear in the 'Animations' tab?
I had a quick look and here is what I came up with:
Let's start at the element .post-hero: this acts as a wrapper and has position: fixed to make the image more or less stay in place as we scroll.
Inside this there is the .hero-bg element which contains the background image itself. Note that this element has inline styles setting its background to none, but it has a data-bg attribute pointing to the background image itself. My guess is that on page load, some JavaScript is used to take this attribute and add the actual image.
The actual image is set as an <img> element, inside the .backstretch element inside .hero-bg. Now, the .backstretch element is where the animation itself happens: the opacity on this element changes as we scroll (to change the amount of shading), and there's a transform with 3D translation and scaling on the element changing as well. I guess this is done using JavaScript and a scroll event listener on the page.
Following .hero-bg, there is .hero-overlay which has a background color of #252b33 and an opacity of 0.35 to provide the shading effect on the image, together with the opacity of the actual image changing as the page is scrolled.
Edit: if you right click the .backstretch element and select "break on attribute modifications", then scroll, you'll find that the attributes of the element are modified in a file called CSSPlugin.min.js. Googling this seems to point to CSSPlugin being a plugin for the GSAP animation library... I don't have experience with it myself but I know it's popular, others can probably confirm whether or not this is what's used to do the animation. My guess is that the animation is done using GSAP CSSPlugin.

Why does adding a keyframe animation alter z-index?

I have a scenario where I need to animate a div that has a children acting as background helpers. The children need to stay behind the div's background at all time. Without animation adding
z-index: -1 keeps them behind the tranparent background. However they do not stay behind the background when animating.
I have prepared a jsFiddle to show this:
-->https://jsfiddle.net/Jonathan002/gmv70wz7/6/
I know I can fix this by adding an extra div tag to be the background instead. I want to avoid this and direct the question on why the animation will alter my z-index values. Is there another property change happening when the div is animating?
How can I get the div to animate-in naturally (with no changes to dom) while retaining the z-index values?
Elements with transform and opacity don't obey regular z-index order.
That's because browsers create a separate layer to accelerate animations with transform, and per spec the opacity property requires special handling for compositing.

IE8 & IE9 gradients using -ms-filter cover the element

When applying:
-ms-filter:"progid:DXImageTransform.Microsoft.gradient(GradientType=1,startColorstr=#FFFFFF,endColorstr=#000000)";
to a DIV, the gradient behaves as if its an element covering the div and therefore mouse cursor no longer changes nor does mousemove events occur on the div. The only part of the div still responding is the border.
I've googled and cried and put the cows to bed but all to no avail. It displays perfectly but I need to have the containing div respond to mouse events and I've no more hair to tear out.
A happy day indeed it will be when we no longer care about the poor sods using IE8/9
Unfortunately, you're right; that's exactly how a gradient filter works.
I think your only recourse here is to either use a traditional, pre-rendered gradient image as a CSS background, or apply the filter to another element that's positioned directly behind the div (or a :before pseudo-element possibly? I'm not sure how gradients work with generated boxes).

CSS3 transition affects parent div

I'm trying to find out why this CSS3 transition affects the parent div:
http://jsfiddle.net/BpUqt/5/
I'm trying to move an object up inside a div without changing the height of its parent div.
But what happens is that the height of the box shrinks by 1px each time the transition begins/ends (with or without border)
While I want to use three of these in a row my content beyond begins to jump up too if the user hovers over these items very quickly.
Setting an fixed height is not an option since I'm working on an responsive layout.
Instead of animating margin (which means the box height needs to be recalculated, so rounding errors on partial pixels causes movement), use transforms.
Also, remember that IE10 has transitions, so use the ms prefix as well.
Have a look at http://jsfiddle.net/BpUqt/10/
Ok, here's a simple work-around. Simply add a negative margin and it works:
http://jsfiddle.net/BpUqt/12/
Here's how it actually looks like (minimal version):
http://jsfiddle.net/sSjQt/

hover and unhover goes into infinite loop

The code : http://jsfiddle.net/Gwx6E/
When you mouse over the div, and when the div boundary reaches the cursor the normal styles of the class .a are applied.
Making it to move under the cursor, which triggers the hover. This goes into the infinite loop.
Is there any way to slove this problem, with css3 alone ?
Nope, it's the desired behavior (however there are the differences in some browsers: not everyone updates the hover state without the cursor's moving).
You can try to change the way your code is: add a wrapper and trigger the hover on it, so only the child block would move, but the hover would still be on the parent.
Here is an example: http://jsfiddle.net/kizu/Gwx6E/1/
Another way is to use the pseudo-element, that would be positioned over the screen so the hover would be always on the element when it would animate, here is an example: http://jsfiddle.net/kizu/Gwx6E/2/ — however the drawback is that you could't de-hover this block until there won't be any blocks with bigger z-index that would be positioned in places where you'd like to unhover the block.

Resources