? A small rant about tables
[Robin]: I’ve been interviewing a lot of folks lately for front-end roles at Gusto (where I work) and I’ve been noticing something peculiar about the interview process. In these interviews, I test a front-end engineer’s basic HTML and CSS skills with the following mockup that I ask them to build:
All I ask them to do is replicate that design in the browser with the help of CodePen (and without the need for them to do anything with interactivity or JavaScript). Anyway, I really like this exercise because the design makes things deceptively tricky. How will they organize the calendar? Will they use Grid or Flexbox? Will they stick to a regular old table? Will they care about accessibility? Do they know about ARIA roles? Do they care about different browsers and responsive design? How do they structure their code? And most importantly of all: are they focused? Do they tackle one problem at a time before moving onto the next? Those last questions are perhaps more important than any technical skill in this humble blogger’s opinion.
However! One point of anxiety I hear from a lot of folks in these exercises is whether they should use a table to markup that calendar. I’ve heard it perhaps a dozen times this year, where the interviewee mentions that they’ve heard that the table element is not good practice. And that they should never, ever use it.
Which is odd, because there’s nothing wrong with it! This calendar is the perfect use case for a table — any time you’re marking up tabular data then a table is just fine. The only problem comes in when you start using that element specifically for doing layouts. Like, say you want a grid of elements on a page – but that data is not tabular – then that’s not a great idea!
Anyway, I just thought I’d mention that because it’s mighty interesting to see this common concern leak out into our industry.
? Links from around the web
This right here is a fantastic use of CSS variables where Lucas Hugdahl shows us how not to repeat ourselves. In the code below, he sets a transform rule once without having to duplicate that code within the :hover declaration:
button {
transform: transform .5s ease-in-out;
--scale: 1;
transform: translateX(-50%) translateY(-50%) scale(var(--scale));
}
button:hover {
--scale: 2;
}This is so much easier to read than having to repeat things just a few lines down! And I love the use of CSS variables like this as it shows how the language itself is moving towards a cleaner, more legible future.
Here’s a post from earlier in the year that just caught my eye: Linzi Berry, the Design Systems Lead at Airbnb, wrote about the art of diplomacy when it comes to design systems:
Systems design is not only scientific and meticulous, it’s the mastery of interacting with people in a sensitive and effective way. It takes human connection and empathy to go from a sticker sheet to a living, thriving system. The time we invest in relationships with designers and engineers (and their bosses, their bosses’ boss, their project managers, and the accessibility guru down the hall) is as important as building the system itself.
It took me years to figure out that being a web designer is about so much more than just design or code. It’s about being able to communicate effectively in person, too.
In an interesting thread on Twitter, Alex Russell digs into why Apple is holding the web back with iOS. He argues that iOS is the “worst-case-scenario for the web, full stop. It’s hard to overstate how insidious and widespread its impact has been.” Well!
Why is that? Alex reminds us that no matter what browser you install on iOS, they all use Safari’s WebKit under the hood. The result is that effectively every other browser is limited in what features they can offer that are significantly different from what Apple already does in Safari. I’m not so much of a staunch anti-Safari chap as Alex is, but he certainly makes a very compelling argument.
This feels pretty anti-competitive to me and bad for the overall health of the web.
Although, when we blogged this, reader Rolf pointed out the fact that Google Chrome recently shipped an update that deleted a symlink at the root level of the boot volume. Gruber says:
And people wonder why Apple requires Chrome to be a sandboxed app that uses WebKit on iOS.
? This week on the blog
A Look at JAMstack’s Speed, By the Numbers
Artem Denysov wrote about the breakdown of just how fast websites are that use the JAMstack and just why that happens to be the case:
We’ll cover common metrics, like Time to First Byte (TTFB) among others, then compare data across a wide section of sites to see how different ways to slice those sites up compare.
Here’s a wild and shocking statistic that made my eyes bulge out of my head a bit:
According to the HTTPArchive metrics report on page loading, users wait an average of 6.7 seconds to see primary content.
This doesn’t sound like much, but on the web this is a pretty excruciating amount of time to wait for a website to show anything on the screen. Also, I have a sneaking suspicion that this is why so many folks prefer apps over websites – no page loading and no wait between actions – but websites don’t have to be slow. And this is why Artem’s blog post here is worth reading immediately.
Become a Front-End Master in 2020 With These 10 Project Ideas
If you’re looking to improve your front-end skills then here’s some excellent ideas from Chris to help you get started:
- Go find a Dribbble shot that appeals to you. Re-build it in HTML and CSS in the cleanest and most accessible way you can.
- Find a component you can abstract in your codebase, and abstract it so you can re-use it efficiently. Consider accessibility as you do it. Could you make it more accessible in a way that benefits the entire site? How about your SVG icon component — how’s that looking these days?
- Try out a static site generator (perhaps one that isn’t particularly JavaScript focused, just to experience it). What could the data source be? What could you make if you ran the build process on a timed schedule?
These are all wonderful examples and I’m definitely in the same camp here: the best way to learn how to do something is always by building things, instead of following along with tutorials. Not to say that tutorials are bad, they’re a perfect start to figure out the general scope of a thing, but the best way to learn is to build something.
I would also make one small recommendation here: spin up a blog! And if you pick one of these projects to build I’d write about what you thought was tricky and why. That way you get the added benefit of documenting that one weird thing for next time, too.
The Current State of Styling Selects in 2019
I really like this post from Chris about where we’re currently at with styling the default form element. There’s a few design things that’s possible to change today without requiring a ton of work from us developers.
My hot take on this front is pretty simple: I’d recommend not styling the insides of a select. There’s plenty of other issues for us to tackle and sure, it’s annoying, but it’s still a bit too difficult to do correctly and make sure everything is still accessible (today, at least).
SPONSOR
An Event Apart
What does it take to make your site inclusive? What does intrinsic design mean? Is it possible to extend CSS with SVG and Houdini? These are the types of questions you’ll be able to answer by attending An Event Apart, a conference for front-enders. With 17 speakers spread over three days of sessions, there’s so much valuable knowledge and information you’ll gain.
And hey, you get $100 off just for subscribing to this newsletter. Use code AEACP when registering for an upcoming conference near you.
Animated Position of Focus Ring
FocusOverlay is a library that lets you animate the focus ring as your focus moves from one element to the next whilst you tab, as shown here:
It’s pretty remarkable how much more accessible this feels to me than the standard in browsers today. It’s a lot easier to spot where the next element is when the focus ring animates in this way and I wonder if we’ll see something like this eventually move into a browser soon.
SPONSOR
WooCommerce
There’s a reason WooCommerce has been downloaded more than 40 million times and is the de-facto choice for e-commerce on WordPress sites — it’s powerful, flexible and designed to work seamlessly with WordPress. Plus, with 450+ extensions, WooCommerce meets the needs for small and large stores alike!
WooCommerce is open-source and free to use. Give it a try and see what everyone’s talking about.