3 ms·
> I'm so tired of having to write my own JavaScript to get annoying flashy text Fret no more: <style> .blink { animation: blink 1s steps(2, start
by lelandfe 2y ago
> I'm so tired of having to write my own JavaScript to get annoying flashy text
Fret no more:
<style>
.blink { animation: blink 1s steps(2, start) infinite; }
@keyframes blink { 50% { visibility: hidden; } }
</style>
<p class="blink">Lorem ipsum</p>
https://jsfiddle.net/xrkLt2nz/ https://jsfiddle.net/xrkLt2nz/
- tombert 2y agoThis is certainly better than nothing, but it should just be a tag! I shouldn't need this fancy new-fangled "CSS" fad to bail me out of the problems that W3C created by removing it in the first place!
- Sohcahtoa82 2y agoIf front-end devs would stop reinventing things using JS that can be done in CSS, I'd be so happy.
- wruza 2y agoWhy?
- thesuitonym 2y agoNot the GP, but my two cents: because JS sucks and CSS can already do it.
- Sohcahtoa82 2y agoBecause the JS version will likely take more resources and probably end up being done wrong anyways. I just don't get why front-end devs feel the need to reinvent everything. I mean, for fuck's sake, front-end devs for some reason have a fascination with reinventing fucking SCROLLING. And 100% of the time, it either doesn't work, has less functionality than what was built-in, or is annoying for the simple fact that it changes an expected behavior. If I click my scroll wheel once, and the page keeps scrolling and the scrolling slowly comes to a stop as if it had momentum, that's a bug, not a feature. Stop wasting time deliberately writing bugs.
- wruza 2y agoScrolling is sort of a strawman here, so I’ll focus on blinking and css features and the need to reinvent these. First, not all css features are consistent enough from the side you usually tend to approach things, due to various backgrounds and thinking modes. Css is notoriously overcomplicated, nuanced and ad-hoc applicable, and tendency to neglect it is its own self-imposed problem. Second, there’s no law that dictated some true way to do things. People use instruments they know, and if these work, there’s no need to go and find true ways. Overall, there’s no difference if you do something in js that css can do, apart from hurting someone’s feelings. All the difference you see is in multi-megabyte tracking scripts, not in js-dom chain per se. The difference betwen css and js ways is barely measurable when you start actually testing it. But js is more powerful in expression and familiar to a developer (except for 60fps+ animations and such). I say this as a non-frontend dev who makes dashboards and other report/control pages for myself, so opinions may vary. But I’ve never seen a higher resource consumption from avoiding css. To my understanding, literally all sites I ever visited can be implemented in a straightforward way in js and will never “take more resources” and will work as fast as just html. Because it’s literally how any non-C GUI app works on desktops. An interpreted jit-able language controlling some widgets. It’s nothing new or unusual or bizarre. In fact, css is also a language, even if declarative, and keyframes structures and other calc()s also get interpreted many times per second, even if not using a full-blown vm. In my opinion, people’s web bloat ideas are all over the place and miss the basics comletely, e.g. https://news.ycombinator.com/item?id=42990724 https://news.ycombinator.com/item?id=42990724 , and tend to blame wrong parts.