[Robin]: One of the strangest things about front-end development is that there can be giant gaps in your experience, even if you’re a senior engineer. You might be entirely unaware of how certain elements work, or how something very specific like CSS animations function, simply because the project you’ve been working on for years didn’t call for it.
One of my favorite examples is someone I once worked with ― let’s call him Gerald. When Gerald joined our team, he had never used Sass before and this was at a time where it was extremely difficult not to use Sass. Front-end architecture and maintainable CSS was all the rage, with Sass being at the center of all these discussions. I was hesitant about Gerald’s skills as a front-end developer because he hadn’t worked with Sass at all.
But Gerald was a practically a Sass expert within a week or so and, soon enough, I had to ask him how the complex parts of it work. Gerald completely changed my opinion on what a great front-end developer is and how we should test their skills; I realized it’s not about technical know-how really or even familiarity with a language, it’s more about adaptation and applying what you know to this new thing you’re encountering for the first time.
Anyway, I stumbled upon a giant gap in my own knowledge of front-end development this week: flexbox. In most situations, and in my day-to-day work, I use flexbox as a way to vertical or horizontally align things. However, many of the flexbox sub-properties are still very much foreign to me.
For example, I stumbled into a little problem when I was designing a tabbed navigation with flexbox where one of the flex-items would have more content in it, like this:
In this UI, we have a width set on the nav element and overflow set to scroll so that if there are 20 items in this navigation a user could scroll through them and access them all still.
I’d rather that longer navigation item not break the word like that. And I knew why this was happening – each flex-item, by default, will take up an equal amount of space inside a flex-container. That much made sense to me. But which of the many sub-properties would allow me to make sure that the width of each item was dependent on the size of the content within that child? In this case, how do I make each item have a variable width?
After quite a bit of searching and fiddling about I found the answer: it’s the
flex-shrink CSS property. Although a lot of the descriptions about that property are super difficult to understand and parse and often feel as if they’re written by a robot. Even in our Almanac entry on the subject, we write that the
[…] specifies the “flex shrink factor”, which determines how much the flex item will shrink relative to the rest of the flex items in the flex container when there isn’t enough space on the row.
I’m sure that’s an accurate description of the
flex-shrink property but also huh? What does this mean in practice?
Okay, anyway, back to my example. I figured out that if you set the
flex-shrink property to
0 then it will tell each item in this navigation not to shrink and instead assume the width of the content instead, like this:
Huzzah! We figured it out, even though it’s just a single line of code.
I guess my point writing about this is that it’s important as a front-end developer to realize that some things are not entirely always common sense; that documentation about CSS is really hard to write, layouts are difficult to style. It’s impossible to remember everything about CSS, and front-end development is complex enough that we should be paid as much as back-end engineers.
From the Blog
Semantic HTML and ARIA roles are vital for modern web development and so Adam Silver looked into the who, what, why, and how of semantics. He looks into how we can make better interfaces that are more accessible:
[…] when semantic HTML alone is not enough on its own, ARIA can provide more context for users of assistive technologies, but use it with caution. It’s not a hard and fast cure for unsemantic markup and can become complicated…
In short, do the hard work to make things inclusive. It’s a win for you and a win for the web.
We wrote up some thoughts about Jason Grigsby’s new book Progressive Web Apps and why it’s so gosh darn great:
Jason explains what PWAs are and how they work while while doing a bang-up job covering the business case for using them them, too. But perhaps you might be thinking that a PWA isn’t necessary for the project you’re working on right now. Well, Jason argues that progressive web apps are for everybody.
If you’ve heard about PWAs but never looked into them that much, then we would heartily recommend you pick up his book right away!
The IntersectionObserver API is an incredibly handy tool for pretty much anything at all that needs to deal with scrolling on web sites. If you need to know something that has anything at all to do with the size of the window and where it has scrolled to, chances are your best bet is doing it with IntersectionObserver, because the performance of it is really great, particularly compared to the alternative: watching for scroll DOM events and doing all the math and performance handling yourself.
Preethi gets practical with it and shows off a few functional uses for Intersection Observer to know when an element is in view. Aside from fancy animations and interactions, there are very practical things like lazy loading media, pausing video, and analytics.
Jetpack brings a whole range of features to your self-hosted WordPress site. From realtime backups that keep your site safe (and make it easy to move!) to improved search results. From related posts to social media integration – it’s a no-brainer plugin for people serious about making their sites better.
It’s especially a no-brainer for us here at CSS-Tricks. We rely on Jetpack for a whole slew of things, from shortcodes and social sharing to security alerts and downtime monitoring. Heck, it even helps power this newsletter!