[Robin]: “Perhaps for what we’re losing in browser engine diversity, we’ll gain in browser UI/UX diversity” Chris quipped the other day in a post all about Bonsai. It’s an interesting little browser that’s pretty different from the browsers that we’re most familiar with today, mostly because it’s designed to do just one thing really well: research. A hotkey makes the app appear as a tiny floating window on your screen and you can organize “tabs” into workspaces, which certainly looks neat and certainly helps clean up all those messy tabs.
But I agree with Chris here—it feels like there’s something in the air when it comes to browsers. Folks are starting to think about them differently and that’s exciting. And although in the front-end world we’re constantly bemoaning the convergence of browsers towards Chrome and WebKit—and for good reason, too (ideally we’d have both browser engine and UI diversity). But I think that this can sometimes be a little short-sighted because UI diversity is just as important, perhaps.
For example! The other day I stumbled upon Opera GX, “a browser for gamers” that tells you when certain video games are about to be released and adds CPU, RAM, and Network limiters. That’s certainly cool and weird.
Then there’s The Browser Company which hopes to reinvent tabs and how we navigate around websites. Or Brave, who’s trying to position itself as a faster and more secure alternative to Chrome that also lets you tip writers (heck yeah!). Then there’s Sidekick, which is trying to be one of those omni-app things that lets you quickly get into Gmail, Notion, Slack, etc. Synth looks like something similar, except that it lets you quickly make Jira tasks and lets you jump into Zoom meetings and whatnot real quick. Mighty, on the other hand, lets you search across all your Google docs from within the browser which saves you having to bookmark a million things. There are just so many of them!
These variations on a theme make me realize that, at this point, I don’t know what a browser is. Sure, it can take a URL and show you a bunch of information, and lets you search for stuff. But beyond that, boy, I’m not so sure. Should a web browser have bookmarks? Should it have the latest and greatest CSS features? I can imagine a browser without CSS Grid and Flexbox. I can imagine a browser that says eff you entirely to CSS itself. And what about a browser without tabs? Or a browser without color? What about a browser with no UI or a browser designed only for this one, tiny community?
My point here is this: what we think browsers are today are not what they’ll be in the future. And because of that, I’m excited about browsers for the first time in a real long time.
This makes me wonder if Progressive Web Apps are going to make a comeback in the future once we move away from this Chrome UI world. The way we use browsers and operating systems today don’t really encourage us to use them at all but perhaps in the near term future, as these weirder browsers take hold, maybe that’s when PWA usage will explode.
It also makes me wonder what’s the difference between an operating system and a web browser? At one point or another, the line starts to blur for me.
And how will this play out with CSS? What new tools will we need if our websites become more app-like, more front-and-center on people’s devices? And what new tricks will we be talking about here?
These are exciting times indeed.
🧹
What happens if you want to have your tidy little four-column CSS Grid that—once you click a button—opens up a bigger card underneath? That’s the question that Kev Bonnett answers in this post about expandable sections within a CSS Grid and here’s the demo that he ends up building:
Turns out there is a nice solution to it, and in the spirit of CSS Grid itself, it only involves a couple of lines of code. In this article, I’ll combine three one-line CSS Grid “tricks” to solve this. No JavaScript needed at all.
Neato.
🕶
Chris wrote about CSS Custom Properties and how folks use them in a variety of different ways:
One way to work with Custom Properties is to think of them as design tokens. Colors, spacings, fonts, and whatnot. You set them at the root of the page and use them throughout your CSS. Very useful, and the classic use case for not only Custom Properties but for preprocessor variables for the last one million years.
Another way to work with Custom Properties, which can be done in addition to the design tokens approach, is to go a lot harder and use them for every major unique styling choice on any given element.
The example Chris shows looks like this:
.card {
--card-background: hsl(200deg 15% 73%);
--card-border: 4px solid rgb(255 255 255 / 0.5);
--card-padding: 2rem;
--card-border-radius: 8px;
--card-title-margin: 0 0 1rem 0;
--card-title-border: 3px solid rgba(0 0 0 / 0.2);
background: var(--card-background);
border: var(--card-border);
padding: var(--card-padding);
border-radius: var(--card-border-radius);
}
.card > h2 {
margin: var(--card-title-margin);
border-bottom: var(--card-title-border);
}I’ve worked with components written like this and sometimes it can get a little… much. To me, the above can sometimes feel like someone was trying a bit too hard to be programmatic and focused intently on reusability. But sometimes code like the above is really nice and encourages you to think like a system.
I also love Chris’s second suggestion that’s a little less verbose here when declaring these variables:
.card {
background: var(--card-background, hsl(200deg 15% 73%));
border: var(--card-border, 4px solid rgb(255 255 255 / 0.5));
padding: var(--card-padding, 2rem);
border-radius: var(--card-border-radius, 8px);
}So what’s happening here is that Chris is declaring a Custom Property, like --card-background, and adding a default to it (the code after the comma in the brackets). That way you don’t have to have all the variables listed at the top of the CSS class and it makes things a bit more readable.
🕹
This is something that’s going to take ages for me getting used to: we sorta don’t need absolute positioning anymore. Or, rather, we don’t need to rely on it as much as we did in the past. That’s the gist of this post by Ahmad Shadeed:
When we have a card that contains text over an image, we often use
position: absoluteto place the content over the image. This is no longer needed with CSS grid.
Whoa, whoa, whoa. Hold your horses there, pal. As much as this makes me panic a bit—learning and unlearning CSS things makes me feel like that—Ahmad shows a great example:
Now if you asked me five minutes ago how to make that text stick to the bottom I would’ve said there’s two main ways to go about it. First, you could set the .card to position: relative and then absolutely position the text with bottom: 10px or something. The second way to do it would be the nifty CSS trick where you could set the .card to display: flex and then make the .card__text component have margin-top: auto on it.
Ahmad argues that a good solution is CSS Grid because you can set up the columns and rows and tell that text block to sit at the bottom on the very last row. I’m sure this is how all the cool kids are already thinking about CSS layout and positioning at this point, but to me this feels like a tiny revolution in my brain.
Chris then made a great example riffing off this idea that messes with my mental model of CSS, too:
Both the Plant text and the on sale tag are both using CSS Grid, with no CSS absolute positioning in sight. That’s pretty neat to me but it’s going to take a while to change how I think about positioning in CSS.
📋
I like this sentiment from Michelle Barker where she writes about developer decisions for building flexible components:
We simply can no longer design and develop only for “optimal” content or browsing conditions. Instead, we must embrace the inherent flexibility and unpredictability of the web, and build resilient components. Static mockups cannot cater to every scenario, so many design decisions fall to developers at build time. Like it or not, if you’re a UI developer, you are a designer — even if you don’t consider yourself one!
During my day job, I’m now more of a designer than I am a front-end developer, and because of this career switch, I’ve begun to see the world from this other side of the relationship and how it feels. Instead of making lots of mockups for responsive designs or lots of examples documenting how something should work precisely, I’ve slowly learned that the front-end developer I’m working with should be my partner in crime. My designs are nothing more than hints and suggestions, with their work filling out all the gaps in between.
That means lots of design work gets done while development is happening. Not the big UX stuff, but the extremely important tiny details that lead to something going from “meh” to “okay, this is neat.”
So what I’m trying to do now is not treat my mockups as a Final Design™ but rather a blueprint that we then have to build together in discussion, as partners in crime.
Sponsor
Ecwid Ecommerce
There’s never been a better time to start offering eCommerce! Partnering with Ecwid makes the process quick and hassle-free. Your customers will love their robust, customizable new online store. And the added value for you as a developer? Our secure, cloud-hosted solutions mean you can hand off a finished project with little to no maintenance or customer support necessary! With Ecwid’s suite of robust APIs, you can also customize eCommerce to fit your business as seamlessly as you want. Read more on why developers choose Ecwid for WordPress eCommerce.
Sponsor
Jamstack Community Survey 2021 Results
Which new framework should I learn this year? Is it time to ditch my CMS? What tools should I pick up if I want to scale my site to an audience of millions? The 2021 Jamstack Community Survey is here with answers to those questions and more.
With over 7,000 respondents this year, more than twice as many as our previous year’s survey, there’s a lot of great data to cover.
[Chris]: To the surprise of no one, CSS has some really weird quirks! I keep thinking about Miriam’s explainer that CSS has no concept of proximity. Maybe scoped styles will solve that one for us. I also keep getting hit by this custom properties gotcha that there doesn’t seem to be a clear wonderful solution for. And speaking of custom properties, remember how you can declare their type with @property? Turns out that can fix (or cause?) some rather odd quirks. PPK blogged one the other day.
Try hitting this Pen in Chrome (because it supports @property) and commenting and un-commenting the property declaration at the top. You’ll see the child font-size change quite a bit. It’s like if the browser knows that the custom property is a length, then it can resolve against the grandparent value right away and get that value. But if it doesn’t know the type, then it resolves later, making the relative value factor in the parent in a way it otherwise wouldn’t. That is straight-up weird to me. Definite gotcha territory.