Changing list bullet styles
Yep, you can do that now without hacks or employing the somewhat awkward combination pseudo-elements and counters. Your best bet? The ::marker pseudo-element. We just updated the Almanac entry on that for your reference pleasure.
ul li::marker {
font-size: 150%;
font-weight: bold;
color: lightgreen;
}You can also control the text of the marker itself, meaning you can swap out bullets for emoji, or numbers for custom counters. Manuel Matuzović made note of this week that it was just a few years ago this was much more difficult. Go CSS!
Support is pretty darn good and it’s been around for a little while but I always tend to forget about :marker so this is a good reminder to use it more often.
Responsible Web Applications
Joy Heron made a fabulous website called Responsible Web Applications where she writes about how to make such a thing:
It is extremely difficult and expensive to add responsiveness and accessibility after the fact. For this reason, we need to take them into account from the very beginning.
Hear, hear. Making an interface responsive once it’s shipped is so much harder than making things responsive from scratch. And yet for some reason I continue to hear that argument that Joy mentions here:
Do we really need responsive web design for our web application? We will only use our web application on desktop computers!
I’ve heard this argument many times, but in the long term, it has never turned out to be true. For this reason, I’ve created Joy’s two laws of web development:
- There is no such thing as a non-responsive web application
- Any work you do now to ensure that your web application behaves responsively WILL be appreciated in the future.
I love this whole piece but particularly the example that Joy gives when it comes to using flex-wrap: wrap to easily shift content around on a screen.
On this note, though, a while back I mentioned how accessibility and web performance are not features, they’re the baseline—the way we should measure the quality of an interface.
And now I’d add responsiveness to that list, too.
The Devil’s Albatross
Nils Binder has somewhat of an obsession with what he calls “algorithmic layout techniques”:
I’m fascinated with the concept of algorithmic layouts and got so used to building whole websites without using any media-query, that I sometimes forget they exist. (You got no idea what an algorithmic layout is? Long story short: It’s a component that uses some clever CSS hacks to mimic the behavior of container queries…)
Here’s one example where we can make a logo and a nav spread out on large screens and then stack on top of each other as the space decreases:
I really like this technique because it’s creating a layout system without having to split up our designs into “small,” “medium,” and “large” breakpoints. In projects I’ve worked on, there’s often a system for managing breakpoints—CSS variables or Sass mixins—and this sort of helps reduce that complexity, too.
Progressive Web Apps in 2021
Here’s a piece by Maximiliano Firtman about how many developers are making their websites progressive web apps today:
At the end of 2020, approximately 1% of websites included a Service Worker, and 2.2% had an installable Web App Manifest file. Remember that some platforms -such as Safari on iOS or Chrome on Android- do not require a Service Worker to have a standalone experience after installation. We can assume that 2.2% of websites are installable, and 1% may pass the PWA criteria on Android, 71% of which offer some offline experience.
There was so much enthusiasm and passion for progressive web apps just a few years ago though, as Chris riffs on in this note:
Anecdotally, I’d say PWAs fell out of general conversation last year. I don’t think anybody is exactly against the technologies that make them up, but they aren’t embracing them either. My guess? Everyone is scared of Service Workers. I’m scared of Service Workers. They do scary things, like aggressively hold onto cache. I think a whole dev team really needs to understand them and embrace them into their workflow and build process for them to be effective. Generally speaking, we just aren’t there yet.
I’d say this is three problems where each one causes the others:
- I avoid building PWAs: I’m definitely scared of Service Workers as Chris says above, so I sort of avoid building progressive web apps altogether. And I remember setting up a Service Worker for a personal project a while back and having to fight the cache for a while until I got mad and tore it all out. The difficulty of Service Workers for me makes me hesitant to go explore them more.
- I don’t use PWAs: I’m sure this is only partially true, but I don’t install web apps on my desktop or on my phone (only because I can’t there, I guess). If I don’t use PWAs then I’m hardly likely to build them.
- The user experience is weird: It’s not obvious you can install a website in the browser. That in and of itself is going to make the investment from other web developers less likely if no one knows you can “download” a “web app” from a “website,” I think that’s a huge missing piece of the puzzle here—teaching people that these things exist, and making the UI more prominent.
These sentiments might not last, and things might get easier. And I might just be immensely stubborn here. But back to Firtman’s piece—it’s great because he talks about what the future of progressive web apps might be and why he’s hopeful that they’ll catch on in the future.
Is CSS float deprecated?
An interesting conversation came up at work the other day: Should we use the CSS float property now that we have CSS Grid and Flexbox? So I wrote a few thoughts about how to use the float property today in 2021. The short answer is that it’s only really good for wrapping text around images, like this:
But! I’d avoid using the CSS float property for layouts that are any more complex than that. Over the years we unlocked CSS Grid and Flexbox so that float can sort of take a back seat when it comes to day-to-day development.
And that’s a good thing! It shows us that the web is getting better and better over time, just like Brad Frost mentioned the other day:
I can’t imagine designing interfaces today without the gap property.
A table with both a sticky header and a sticky first column
The first time I heard about position:sticky I knew it would help us make tables properly responsive: being able to “stick” headers and columns on smaller devices is one of the few ways you can make complex tables readable on the web. So, with that said, Chris looks at how to make a table with both a sticky header and a sticky first column. Here’s an example:
I like Chris’s demo here because it reminds me that we can make our tables look good while also being useful and easy to scan. But another walkthrough we did a while back was when we made a responsive spreadsheet interface with nothing but CSS:
There’s another table solution for smaller screens that’s worth taking a look at that doesn’t involve this scrolly table header/column stuff: making each row in a table a separate card with each column having it’s own heading. Like this:
Chris wrote about this technique ten years ago and I think it’s a super interesting technique still, although I’ve yet to see it out in the wild.
Sponsor
Sendbird
Save time building in-app chat, voice and video for mobile, and web applications with Sendbird! Get to market faster with Sendbird’s UIKit, pre-built UI components, best-in-class documentation and support for developers.
Sponsor
Jetpack Search
It’s the best search solution for WordPress sites, by far. We’ve tried lots of different search approaches on CSS-Tricks and came out flat. Jetpack Search cracked the code for super powerful and native WordPress search, without the tough technical hurdles to get it done. And, hey, it continues to get better. Just this month, Jetpack extended support for Jetpack Search for Internet Explorer 11. If search is a must-have on your WordPress site, then Jetpack Search is definitely worth a try.
[Chris]: Arthur C. Clarke said that “Any sufficiently advanced technology is indistinguishable from magic.” But he was a futurist and sci-fi writer guy. He was saying, “my predictions and weird books might seem like I’m inventing magic in my head, but just wait, future technology will be just as weird or weirder.”
Now, we’re reaching a time where we don’t even have to do the wait for the future part. There are constantly things emerging that feel like magic right now.
Look at Radio Garden. It’s a damn globe you can spin around and zoom into cities and listen to their radio stations. What?! I’ve been listening to a station in Kodiak Island, Alaska, because why not.
Look at Same Energy. You give it an image and it finds other images with the “same energy.” I have an ancient folder full of silly images on my computer, including this one:
Drop that onto the website (even websites supporting drag and drop is a little bit of magic), and I get:
Look at removebg. It yanks the background off images without you telling it anything at all. That’s incredible, but have you been on a Zoom call where the person replaces their background with some static image of something like some forest or a Studio Ghibli image? That’s like removebg in real time. Wow.
Look at quantum computers. Like, actually look at them:
I’m not even going to try to explain it, other than to say they can do certain types of computations quickly by, I believe, farting on the laws of physics. You’ll never get to play with one through, right? Wrong, you can just run your quantum desires right on AWS. How much?
A scientist runs a quantum algorithm on the Rigetti Aspen-8 quantum computer. This task includes 10,000 repeated shots of the same circuit design. The cost to execute this task includes a per-task charge of $0.30, plus 10,000 shots at a per-shot price of $0.00035.
Task charges: 1 task x $0.30 / task = $0.30
Shots charges: 10,000 shots x $0.00035 / shot = $3.50
Total charges: $3.80 = $0.30 + $3.50
That’s right folks, magic is now 3 Fiddy.
