[Robin]: In a post the other day about text stroke and CSS, Chris wrote:
Whenever I think of stroked text on the web I think: nope.
This is interesting to me because whenever someone asks me about a new design that they want to implement that’s the first thing that goes through my head: is this possible to make on the web? And by possible I mean a lot of different things I guess. Have I built something like this before? Is it technically possible? Will I need to learn something new in order to build it? Will it require a ton of hacks? Is it worth doing all that work and is the effort worthy of the payoff?
I feel like at this point I have a fairly decent grasp of the limits of my knowledge when it comes to web design and development and a good understanding of what’s technically possible, too.
But most of those things have changed over time! There used to be a ton of things I’d say “nope” to today. There are so many gaps in the web platform that have been filled in with things like CSS Grid and Flexbox—I remember my first web design gig more than a decade ago and needing something like subgrid desperately.
In the end, I told the designer “nope.” This design is too much of a pain in the ass, the web cannot do this, please go back and make it less stressful. Sorry, thank you, you’re welcome.
The same can be said for images, there are plenty of times where I would simply avoid adding images to a website because of the performance concerns but now with response images that gap has been filled in, too.
So, my question: what gaps are there left to be filled in? Where on the web is that work left to do? I reckon that by looking at different design systems we can see what’s lacking in CSS and HTML, where most of the gaps can be found. I have opinions!
This reminds me: the other day I read this great post by Dave Rupert all about his concerns with browser diversity:
I think the Web platform’s most frustrating aspect is also it’s greatest asset: it’s slow. It’s not just slow, it’s “it took 10 years to ship the
<main>element which is just a spicy div” kind of slow. It’s glacial.This can be agonizing while you wait for a much needed feature to roll out in all browsers, only to find out five years in the process one browser refuses the entire premise of the feature (RIP HTML Imports). The big tradeoff is that web platform features have to run the gauntlet and more thinking is applied over time: robustness, naming, internationalization, accessibility, security, etc. all have proper time for consideration and aren’t rushed through like it’s a product sprint.
Dave hits the nail on the head here: the most frustrating thing about the web as a developer is its slowness. But, strangely enough, I think that as a user it is a feature and not a bug. The fact that all browsers have to communicate and garner consensus from the whole web platform before just doing a kickflip and introducing is vital for the health of the web.
So, let me re-frame my question then: where are the gaps in the web platform? And then, most importantly, how do we gather the consensus required to build them?
Better forms with tiny bits of HTML
Arslan Khalid made a great thread on Twitter about making better forms with just a tiny sprinkling of HTML:
Autocomplete, autofocus, using the pattern attribute, there’s a lot of HTML tricks that go into this thread but they vastly improve the overall experience of using forms. Some of the smaller points I like here include adding lots of padding between elements, using a large font-size on desktop.
I feel like there’s a debate taking place on the web when it comes to the design of form elements. Particularly in how big they should be. There are some real clunkers out there, where form inputs take up the whole screen and I personally love that. It makes me trust the website, for reasons unknown to me. It just feels good hitting a massive button to send a form.
Sticky footers + headers with CSS Grid
Huh, I didn’t know you could do this. But Adam Rackis shows us how to make sticky footers and headers with CSS Grid:
One area where it shines is dealing with headers and footers. With a little adjustment in our thinking, we can pull off headers and footers that behave like they are fixed, or have that “sticky” treatment (not position: sticky, but the kind of footer that hugs the bottom of the screen even if there isn’t enough content to push it there, and is pushed away with more content).
The interesting thing is that this is done with… the overflow property!? After reading the post I’m still confused as to how this works but it makes a bunch of sense to use Grid in this way: you don’t have to use absolute positioning and you don’t have to worry about the height of the header or footer.
With Grid, the header and footer content will get larger or smaller and things will just work the way you expect them to.
Also this is a good reminder to plug Rachel Andrew’s book about The New CSS Layout that explains why Flexbox and Grid are so dang powerful. I feel like my knowledge of Grid is…okay, but there’s some kickflip stuff, like what Adam shows above, that is totally foreign to me.
So I just ordered Rachel’s book too and am now patiently waiting at my front door for it.
Query-less Card Components
Speaking of pushing the state of layouts on the web forward, Geoffrey Crofte has written this great bit about avoiding media queries when making components. Here’s the little card component that they end up building:
The nifty thing here is that Geoffrey does this just by using flex-basis which is “the default size of an element before the remaining space is distributed”, so says our Guide to Flexbox. But also combining that with the flex-wrap property.
So! With flex-basis you’re effectively setting the min-width of a flex item, sort of. And if the width of that element can’t be met, and if flex-wrap: wrap is set on the parent, then it’ll break onto a new line. I’ve always avoided flex-basis, flex-shrink, and flex-grow because they mess with my brain a little bit but this post goes into great detail as to why learning how they work is important for making responsive components like this.
Ground Rules for Web Animations
This is a mighty smart post from Prasanjit Singh about how to think about animations when building a website. There’s all sorts of different types, too: loading animations, state changes, user feedback animations, etc. They can be short, sweet, and subtle or they can be thundering and all-consuming animations that take over the whole experience.
I prefer looking at the smaller animations because there’s a lot more for me to learn there. For example, Singh gives this example of a calendar app:
The ever-so-slight change when the total is calculated feels much better than if the number just appeared (in this humble blogger’s opinion). But much bigger animations might be required if whole pages of content change based on click or some other input. And that’s where animations don’t just become a nice to have, but instead become vital to understanding the user’s place within the UI.
That’s where animations like this become much more important:
Sponsor
Netlify
High fives and a fist bump to Netlify for sponsoring this week’s newsletter! We love Netlify for so many reasons, it would take an entire post to cover — and we just so happened to do that. Netlify is probably the easiest way to run an SSG, and makes HTTPS a breeze because that’s what it is by default. We’re big fans and think you will be too when you give Netlify a try.
Sponsor
Fauna
No matter which stack you use, or where you’re deploying your app, FaunaDB gives you effortless, low-latency and reliable access to your data via APIs familiar to you. So unleash your creativity and build fearlessly, without boundaries.
[Chris]: I liked Will Boyd’s The Surprising Things That CSS Can Animate article in part because it touches on some quirky stuff about CSS that is really worth knowing. Is it interesting that z-index can be animated? Sort of! If you ever found yourself in a position where an element had an animation where it goes both in front of and behind another element (for example, think of a moon orbiting a planet), you might be able to time the stacking order charges along with the movement. Plus, while looking at that idea explored in this way, we learn that z-index doesn’t interplate with decimals, it goes integer-at-a-time (so that the value is always valid) which may not be what you expect. Then visibility is also covered as animatable. But it’s only two values, right? Right… but… if the value wasn’t animatable, the value would switch to the new value as soon as a change is applied. Because it is animatable, and because it has special rules, it only applies the change at the end of the animation. That means it is 10× more useful, as it can be used along with, for example, an opacity animation to hide and show things with, which is super common. So at opacity: 1; visibility: visible; the element is shown and part of the accessibility tree, and it can be animated to opacity: 0; visibility: hidden; where it is hidden and removed from the accessibility tree. Thanks, CSS!