100 separate typographic designs, all using free Google fonts, with some absolutely stunning results. What Do-Hee has put together is one of the best showcases for Google's font library, as well as an excellent source of inspiration. Top stuff 👏
Building a tooltip? A carousel? A password input? I can strongly recommend checking if the Component Gallery has a page on whatever UI pattern you're working on.
Each entry collates examples from design systems and pattern libraries all over the web, so you can quickly compare how everyone from Google and Salesforce to Brighton & Hove City Council have solved your problem.
It's been invaluable for the design system project I've been working on, as much for uncovering best practices as simply dissecting the sometimes opaque terminology that has evolved around certain UI patterns.
A great resource for finding accessible patterns for common UI requirements, as well as including stacks of accessibility best practices 🔥♿
A great rundown of how to build a site using Preact and Eleventy that gives you the best of SPA-lite hydration and the speed/resilience of SSGs, all with the power of progressive enhancement.
Markus uses some very clever techniques, including "lazy" hydration (only run hydration when components are within/just outside the viewport) and a
component explicitly designed to bring hydration to 11ty/Preact in the first place.
Also, this perfectly sums up why I prefer working with tools like NextJS or Gatsby (or 11ty):
Component-based workflows make frontend development fun again, and it is a lot easier to do with modern frontend frameworks than with using templating languages like Nunjucks or Handlebars.
A short guide to removing Git history entirely. Particularly useful when you're forking an existing project as a base for something new.
- Delete the
git initto create a new one
- Add all files and create your new first commit
Not tricky, but surprised me that there wasn't a solution within Git itself.
This looks like a very interesting world-building tool. Create maps, family histories, write stories, track campaigns, all from a single profile. Neat 💪
- The web is losing to native because performance genuinely matters, and it shouldn't be.
On how one poorly performing site can lead users away from the web and towards apps:
Bad individual experiences can colour expectations of the entire ecosystem.
Plenty of native apps are happy to aggregate content and serve it up in a reliably fast package, given half a chance. The consistency of those walled gardens is a large part of what the mobile web is up against — and losing to.
CPUs are not improving fast enough to cope with frontend engineers' rosy resource assumptions
On how a single disruptive carrier forced India's mobile market to embrace 4G, significantly improve cost (as much as 95% reduction in some areas), and brought an entire country online with stable, fast connections:
In 2016, Jio swept over the subcontinent like a monsoon dropping a torrent of 4G infrastructure and free data rather than rain.
Interesting that slow 4G is now considered a global baseline speed. That's impressive, given that 5 years ago slow 2G was the baseline 😬
On global smartphone purchase trends:
The worldwide device replacement average is now 33 months. In markets near smartphone saturation, that means we can expect the median device to be nearly 18 months old.
As of 2021, the average smartphone looks a lot like a Moto G7: Android, mid-tier, about 2-3 years old, running Chrome.
But average is only half the market. A better baseline would be the Moto E6 (or even Moto G4): still Android and Chrome, quad-core, 2GB RAM.
On how those same trends are creating a significant inequality gap:
As high-end phone performance accelerates away from mass-market devices (still largely with the same performance as 2012) we're creating a high inequality gap:
When we construct a digital world to the limits of the best devices, the worse an experience we build, on average, for those who cannot afford iPhones or $800 Samsung flagships.
On the folly (and privilege) of making choices based on DX instead of UX:
But we must never forget that measurable improvement for users is the yardstick.
Trickle-down user experience from developer-experience is, in 2021, as fully falsified as the Laffer Curve. There's no durable substitute for compassion.
On what comes next:
But there's light at the end of the tunnel: if we can just hold back the growth of JS payloads for another year or two — or reverse the trend slightly — we might achieve a usable web for the majority of the world's users by the middle of the decade.
Often, when people with goodwill and shared values end up disagreeing, it’s because they didn’t understand the code words that were being used.
(I often wonder how much the Left's ever-changing vocabulary hurts its ability to work cohesively, for example)
The best overview of
z-index and stacking contexts that I've come across, plus it keeps getting better as Josh extends the useful tools section 👏👏
Top of the tips is
isolation: isolate, a very useful CSS function that I never remember; it effectively resets the stacking context, which means it's particularly useful for component-based UI structures.
Also a worthy shout-out to the CSS Stacking Context Inspector plugin (also available for Chrome). It's already helped me locate a rogue stacking context being created by a global
opacity attribute (of all things 😂).
A follow-up to Andy's previous explanation of his compound grid layout in which they explain their logic behind a 4 + 5 compound grid a bit more. It's neat, but this description is what really caught my eye:
Think of each column as a beat. When you drum the cadence of 12 evenly-sized columns with your fingers, the rhythm is monotonous.
That's a nice way of framing a layout. I'd like to give it a try in reverse one day: think of a drumbeat I like and work out what grid layout is equivalent to the hits and gaps, then see if it could be the foundation to a site. Sounds like fun 🥁
A very clever article (as ever) from Sara on how to ensure the content you create is accessible through RSS feeds and Reader modes (and a host of other applications).
This is something I'm guilty of. There's a kind of magic to automating content through CSS which I find very appealing, but Sara's warning here is something I'll need to keep in mind moving forward:
In order to ensure readers always get a proper reading experience, provide real content in HTML, and leave CSS pseudo-elements for decorational content that is not required for the core reading experience.
They also point out how problematic call-out content can be, and suggest hiding unnecessary content in a couple of ways. The simplest is removing it from the
<article> element, which should cater for a number of scenarios (and I wonder if things like Safari's Reader mode deal with
<aside> elements correctly?), but if your markup requires it to be kept there's a really clever trick using
hiddenattribute has a very low specificity, you can override it in your CSS using a simple
In other words, add the
hidden attribute to your content block, then have a utility class like
hide-reader-mode which sets it to
display: block (or just target directly). Users on your site will see it, but if your CSS doesn't load, neither will the content (so also useful if the stylesheet fails to download for some reason).
Sara also points out you can do the inverse, having a utility class like
reader-mode-only that shows content only where your CSS doesn't load. So you can still have fancy CSS pseudo-elements or drop caps etc. but RSS feeds will get plain text equivalents. Can be particularly useful for live examples (they point to a styled
<hr> example) which can be switched out for images.
Strikes me you could use similar tricks to show messages in RSS feeds that otherwise wouldn't appear. Just a lot of cool ideas going on here!
Cher has written an excellent, concise, and extremely evenly-handed response to the current Tech Twitter™ nonsense. I wanted to save it (alongside Andy's) to refer to next time this happens (because, unfortunately, there will be a next time) 😤
A response to the initial article that acted as a flashpoint (and some useful ideas around TailwindCSS for my own understanding to evolve a bit):
I do think it's important that we frame our critique and support for technology in a way that makes it clear we understand that while it did or did not work for us, or our team, or our project; we know it's for our case and our reasons are reflective of that specificity.
On the inherent bigotry on show (and that ending is just superbly well written):
Sara has had to earn his respect and admiration, as a non-American woman of color, instead of getting it from default in-group bias, and anything other than the admiration he gives her is felt as betrayal.
A man incited bullying onto a Lebanese woman for sharing a critique of a framework he wrote not for the critique itself, but because she didn't give him the admiration he felt he deserved. That's not respect. That's systemic entitlement.