Live data from Hacker News

Maintaining CSS Style States using "Infinite" Transition Delays

joelb.me

1–10 of 19 posts

Re: Maintaining CSS Style States using "Infinite" Transition Delays

#2
This is pretty cool, but it also represents one of my main beefs with the HTML5/CSS standards and their past, current and future direction. That is the substantial amount of cognitive friction involved in doing many relative simple, even sometimes common things.

Implementation of often basic UI design concepts and interactions can quite often require some serious contortions of the HTML, CSS or both (though very fortunately, less and less the HTML). CSS is designed around being exceptionally flexible but nonetheless, there is no real consideration for usability or common patterns and use cases (or for the poor souls who may have to wrap their heads around these styles later on). I think in the end this is leading towards some pretty ugly legacy issues.

Sadly, I have no real solution here so I'm just bitching. I sort of see why we are at this point, and I don't currently see any way that a somewhat haphazard standards definition process can possibly focus on usability. Perhaps someone else here does?

Re: Maintaining CSS Style States using "Infinite" Transition Delays

#4

This is pretty cool, but it also represents one of my main beefs with the HTML5/CSS standards and their past, current and future direction. That is the substantial amount of cognitive friction involved in doing many relative simple, even sometimes common things. Implementation of often basic UI design concepts and interactions can quite often require some serious contortions of the HTML, CSS or both (though very fort…

Very true. It would be the job of the implementors to provide new properties that handle common use cases. For this example in particular, we now have:

animation-fill-mode

Re: Maintaining CSS Style States using "Infinite" Transition Delays

#5
Very clever. I disagree that this kind of thing should only be done in javascript. This is a very light-weight solution to various animation problems. In the old man in a room demo, it works perfectly for letting the GPU-accelerated browser handle that very smoothly, while freeing up your javascript thread for other duties.

Re: Maintaining CSS Style States using "Infinite" Transition Delays

#6
Everytime I see a new technique I get all excited. Then I check it on Internet Explorer and the excitement fades.

On IE-9 it works the first time you try it but then the other buttons don't have any effect.

Just once I'd like an organization to have a corporate standard that mandates Chrome's latest version.

Re: Maintaining CSS Style States using "Infinite" Transition Delays

#7

This is pretty cool, but it also represents one of my main beefs with the HTML5/CSS standards and their past, current and future direction. That is the substantial amount of cognitive friction involved in doing many relative simple, even sometimes common things. Implementation of often basic UI design concepts and interactions can quite often require some serious contortions of the HTML, CSS or both (though very fort…

Very true. It would be the job of the implementors to provide new properties that handle common use cases. For this example in particular, we now have: animation-fill-mode

The problem is that right now implementors are all building different browsers that are attempting to provide a single consistent implementation of features as read off a spec document. A daunting, unenviable task to be sure.

Perhaps the solution is in frameworks or abstractions but that is also troubling. Who knows, it's still the best we've got right now, and that's going to have to be good enough for me.

Re: Maintaining CSS Style States using "Infinite" Transition Delays

#9
post #3

In the demo, there seems to be a change in responsiveness as you approach a wall.

Yep, because every time you re-initiate the animation (by clicking a button), it starts an animation from the current position to the wall and sets it to get there in 2 seconds. So the speed is dependent on the distance from the target.

Given how easy it is to duplicate the same effect in Javascript, I see no reason to use this hack.

Post reply on HN