(CSS) Better to animate via 'keyframes' or 'transition'?

[Under S.]

As a career visual designer who likes to dabble in web programming -- and began the process of "catching up" to today's advancements after 4-5 years away from the programming side of things -- I was ecstatic to learn that CSS-only animations are now a thing.

Here is the basic method I researched and already began employing :

a:hover {

     animation: links .3s 1;

     filter: brightness(125%);

}

@keyframes links {

     from { filter: brightness(100%); }

     to  { filter: brightness(125%); }

}

However, I just this morning came across this random bit of someone else's code :

a {

     transition: opacity 3s;

}

a:hover {

     opacity: .8;

}

As much as the first solution works, the second seems to require way less code.

So the question becomes, if I wanted every <a> tag to react on mouseover via a short 3s animation (using either 'opacity' or 'filter:brightness') how would I go about it in 2018... keyframes, or transition? Or is the question faulty to begin with?

Thanks!

[pziecina]

css filters do not work in IE, so if you want IE10/11 support do not use.

As for animations, it depends on what you wish to do. Keep the code as simple as possible, use keyframes when you wish to animate at various rates of speed, or to animate multiple properties at one time.

[ALsp]

Keyframes require no interaction from user. Hover obviously requires the user to hover, which presents problems on touch devices. That's the short story. There are many other iterations of CSS animations beyond your example. Hover is to be avoided unless you don't care about touch devices. There is a third way to animate with CSS and that is to augment with simple class change scripts. We have a free one:

CSS Class Switcher for Dreamweaver

[Under S.]

ALsp  wrote

Keyframes require no interaction from user. Hover obviously requires the user to hover, which presents problems on touch devices. That's the short story. There are many other iterations of CSS animations beyond your example. Hover is to be avoided unless you don't care about touch devices. There is a third way to animate with CSS and that is to augment with simple class change scripts. We have a free one:

CSS Class Switcher for Dreamweaver

That's actually a good simple explanation of the difference. And no, I'm not leaving hover effects behind on desktop just because mobile is here. You can if you want, but as a designer, I will continue to use every tool at my disposal to enhance the UX until desktops and laptops are extinct.

Sounds like the answer to my question depends on context, so here is that context again : if all I want to do is universally style the <a> selector on mouseover and animate that change, am I better off using 'animation/keyframes' or 'transition'? In other words, this question is specifically about the easiest (least code?) way of animating the restyling of a:hover, specifically.

As for IE, I don't much care about older Internet Explorer versions at this point, but still care about modern-day Edge (and probably will until it stops being shipped w/ Windows).

[ALsp · Accepted solution]

Sounds like the answer to my question depends on context, so here is that context again : if all I want to do is universally style the <a> selector on mouseover and animate that change, am I better off using 'animation/keyframes' or 'transition'? In other words, this question is specifically about the easiest (least code?) way of animating the restyling of a:hover, specifically.

a:hover is unequivocally best animated by a:hover (no keyframes). If it's a link and you want the link to spin or slowly change background, etc., then there is no usability downside with respect to touch as touch users will simply activate the link and leave the page anyway.

[pziecina]

https://forums.adobe.com/people/Under+S.  wrote

Sounds like the answer to my question depends on context, so here is that context again : if all I want to do is universally style the <a> selector on mouseover and animate that change, am I better off using 'animation/keyframes' or 'transition'? In other words, this question is specifically about the easiest (least code?) way of animating the restyling of a:hover, specifically.

The simplest method would be to just use a transition.

If you do use transition, make certain that the 'hit' area is not too small as I have seen drop down menus that do not function correctly due to there being no overlap of 'hit' areas.

[Jon Fritz]

Typically, I'll use Transitions when I'm changing between two steps and Keyframes when I have multiple steps after the animation is fired.

[Nancy OShea]

https://forums.adobe.com/people/Jon+Fritz+II  wrote

Typically, I'll use Transitions when I'm changing between two steps and Keyframes when I have multiple steps after the animation is fired.

I do the same.

[osgood_]

Just dont waste too much time on stupid :hover events that dont work on mobile. Mobile accounts for the majority of users now, so think about how to achieve what eye-candy you want on those devices as priority.

[ALsp]

Agreed. But it's still hard to figure out the OP's true intentions here. A simple hover transition on a live link is fine as the touch device will be leaving the building anyway. Image or content effects, such as overlays should definitely be done via scripted class changes (unless you want to heed Birnou's advice and support only Android 🙂

But, yes, people need to be very mindful of what they do in terms of :hover because, as you say, mobile is the majority, and with so many laptops coming with touch screens, it's even more important.

[B i r n o u]

I have always loved exploring interface paths that were only exploitable at first sight on a single platform, or even a single context... because the game is intoxicating... and sometimes paths and tracks open up... exploring hazardous paths and also a guarantee of entrepreneurship... not to confuse exploring and producing...

and paradoxically in all the developments in which I have participated, and although the process has not been undertaken in this sense... I have won much more money and contracts by exploring completely unexplored tracks than by following the path that everyone was trying to follow...

I had the opportunity to approach and work with research teams at accenture, havas group, cap gemeny, arthur andersen... and a few others... and there in these projects, the more hallucinatory and improbable the project and ways explored seemed, the more they were retained...;)

[pziecina]

https://forums.adobe.com/people/B+i+r+n+o+u  wrote

and paradoxically in all the developments in which I have participated, and although the process has not been undertaken in this sense... I have won much more money and contracts by exploring completely unexplored tracks than by following the path that everyone was trying to follow...

I think that is more a buisness model than anything else, (its also roughly the one I follow).

Designing and building to each devices/browsers strength has worked very well for me, but I'm not certain if it would work for those building the small everyday sites. I think it is one of those approaches to development that larger companies/organisations are more willing to accept.

As a community web design/development has retreated mainly into its shell, (not certain if you will understand the meaning Birnou). Back to the days of, 'everything must look and feel the same across all devices/browsers'.

[B i r n o u]

I 1000% agree... and completly understand it... I never said that using acceleration, front camera and pythagore was a way to go to simulate the hovering location .... say differently it wasn't a solution for the OP... just to keep in mind to explore new way, future way, hallucinatory way... ... keeping the adventure open...

[B i r n o u]

pziecina  a écrit

As a community web design/development has retreated mainly into its shell, (not certain if you will understand the meaning Birnou). Back to the days of, 'everything must look and feel the same across all devices/browsers'.

I think that I got it...

[B i r n o u]

just about hovering on touch screen, it can be simulated playing with... Sensor  |  Android Developers  and android.hardware.camera2  |  Android Developers 

[ALsp]

Wow. Where's the CSS Birnou? Can you show us an actual working example? On a side note, it looks like it's only for Android, and it most certainly does not look like CSS  - unless my quick scan of the page is inaccurate, that's a really dumb way to approach something that could be solved using very simple JavaScript.

[B i r n o u]

I never that was CSS...

[ALsp]

So you are answering a question that was never asked? That's about par for the course

[B i r n o u]

because it is not unusual for subjects to skid on fundamental reflections, I open doors to approaches that can be the subject of research on the evolution of the HMI relationship... so since it would have been mentioned the pseudo :hover I thought it would be appropriate to mention some nice tracks.

no more and no less... sorry I did not wish to disturb you

[ALsp]

You didn't disturb me. But I do think you disturbed the thread. There was a definite disturbance in the force

It's wonderful that Android is doing this, but there are a whole lot of non-android devices and the best way to approach this is with scripted class changes when :hover or keyframes provide too little.