Over the last year or so, I’ve really been trying to catch up on what’s happening in the web development world – I spent a few years falling behind a bit due to… life things. While my skillset is by no means outdated, as I’ve seen what’s coming up I’m getting really excited for the future of front-end development. It’s amazing to see things that used to be major headaches, and take a lot of Javascript to pull off, boiled down to simple, standardized little bits of code.
While there are so many impressive things being spec’d out, I think these ones are the most exciting for me, and will make the biggest impact on my work.
Scroll-driven Animations
Animations are engaging and give websites a fun, modern feel. But it’s always irked me that so many things that should be simple – like adjusting header styles as the user scrolls down – require not only CSS to manipulate the styles, but also Javascript so you’re able to trigger the change. If you can detect where a user is hovering on a page, or what element they have in focus, and style the UI accordingly, why can’t you detect scrolls?
Well now you can. Mostly. In some browsers.
CSS scroll-driven animations are exactly what they sound like – elements transitioning styles based on the user’s scroll position. But with pure CSS. This is super exciting to me because:
- I don’t like JavaScript. For many reasons. Most of them stupid, personal, and totally unrelated to the actual programming language.
- They’re smoother. Look at this header example. See how it’s smooth as butter, but also pauses if you only scroll down a smidge? That’s a little attention-to-detail thing that makes a site feel polished. I love it.
- It makes for more efficient coding. I can write scroll interactions in my preferred language and all in once place, instead of bouncing between the stylesheet and the script. We love doing less.
I can’t wait for wider browser support so I can really jump in and start using these in my day-to-day projects. For now, alas, I’m stuck with JS.
<dialog>
Modal windows and off-screen content are a staple of most websites nowadays. But it used to be that building them was… cumbersome. It’s not as easy as just showing or hiding an element with display: none; and display: block; – you need to consider accessibility, styles, and user interactions. Plus, most of the time you’d need a good chunk of JavaScript to make them work the way you anticipated.
The <dialog> element simplifies a lot of that by providing a semantic, native way to create modal windows. The markup is dead simple, they’re easy to style (especially combined with some nifty CSS attributes like @starting-style, :has(), and ::backdrop) and they handle almost all of the accessibility concerns for you.
Yes, they do require a bit of JS to work, but it’s minimal compared to writing your own modal window script. Once support was wide enough, I refactored my go-to WordPress mobile menu to use a dialog and trimmed my JS from 83 lines of code to 9.
See the Pen Dialog Exploration by Kyrie Tompkins-Overlock (@ketoverlock) on CodePen.
light-dark()
You can probably tell that I am a light mode girlie. The only place I typically default to dark mode is my code editor, and even that is customized up the wazoo.
I’m glad my personal brand is strong.
That said, I think I’m in the minority in preferring a light UI. Most people I know keep their devices on dark mode 24/7. And while most native apps will default to the device color scheme, websites typically stick to light. I think that’s because for a long time, accommodating different color preferences often meant a lot of granular style rewrites – webpages are in “light mode” by default, and using media queries to re-skin an entire website for dark mode takes a lot of time.
Enter light-dark(). Which is basically just a fun little snippet you can use in your CSS to specify colors for both modes in one attribute. You’ll need to tell the browser “hey, I support both modes!” and then from there it’s as easy as using light-dark() to declare your colors for each mode. It makes accommodating user color preferences a lot easier, and gives you the same granular level of control of your design for both modes without basically doubling the amount of CSS you have to write.
Everybody wins.
Truthfully, I haven’t had a reason to dive into too much, yet – support is pretty good but I haven’t quite found the right project (or a client that cares). But I’m so excited to use it on a project at some point in the near future.
A Future to Look Forward to
I’ll be honest – in many, many cases the future looks very… bleak. But when it comes to the state of front-end development, I’m actually excited. Making things simpler, more efficient, and simultaneously more powerful seems like a leap in the right direction, and I’m really looking forward to more dev goodies.