Better typography with text-wrap pretty | WebKit
Everything you ever wanted to know about text-wrap: pretty
in CSS.
Everything you ever wanted to know about text-wrap: pretty
in CSS.
I can’t resist bookshelves.
If I’m shown into someone’s home and left alone while the host goes and does something, you can bet I’m going to peruse their bookshelves.
I don’t know why. Maybe I’m looking for points of commonality. “Oh, you read this book too?” Or maybe it’s the opposite, and I’m looking for something new and—pardon the pun—novel. “Oh, that book sounds interesting!”
I like it when people have a kind of bookshelf on their website.
Here’s my ad-hoc bookshelf, which is manually mirrored on Bookshop.org.
I like having an overview of what I’ve been reading. One of the reasons I started keeping track was so that I could try to have a nice balance of fiction and non-fiction.
I always get a little sad when I see someone’s online reading list and it only consists of non-fiction books that are deemed somehow useful, rather than simply pleasurable. Cameron wrote about when he used to do this:
I felt like reading needed to have some clear purpose. The topic of any book I read needed to directly contribute to being an “adult”. So I started to read non-fiction – stuff that reflected what was happening in my career. Books on management, books on finance, books on economics, books on the creative process. And for many years this diet of dry, literary roughage felt wholesome … but joyless. Each passage I highlited in yellow marker was a point for the scoreboard, not a memory to be treasured.
Now he’s redressing the imbalance and rediscovering the unique joy of entering other worlds by reading fiction.
For a while, I forced myself to have perfect balance. I didn’t allow myself to read two non-fiction books in a row or two fiction books in a row. I made myself alternate between the two.
I’ve let that lapse now. I’m reading more fiction than non-fiction, and I’m okay with that.
But I still like looking back on what I’ve been reading and seeing patterns emerge. Like there’s a clear boom in the last year of reading retellings of the Homeric epics (all kicked off by reading the brilliant Circe by Madeline Miller).
I also keep an eye out for a different kind of imbalance. I want to make sure that I’m not just reading books by people like me—middle-aged heterosexual white dudes.
You may think that a balanced reading diet would emerge naturally, but I’m not so sure. Here’s an online bookshelf. Here’s another online bookshelf. Plenty of good stuff in both. But do either of those men realise that they’ve gone more than a year without reading a book written by a woman?
It’s almost certainly not a conscious decision. It’s just that in the society we live in, the default mode tends towards what’s been historically privileged (see also films, music, and painting).
It’s like driving in a car that subtly pulls to one side. Unless you compensate for it, you’ll end up in the ditch without even realising.
I feel bad for calling attention to those two reading lists. It feels very judgy of me. And reading is something that doesn’t deserve judgement. Any reading is good reading.
Mind you, maybe being judgemental is exactly why I’m drawn to people’s bookshelves in the first place. It might be that I’m subsconsciously looking for compatibility signals. If I see a bookshelf filled with books I like, I’m bound to feel predisposed to like that person. And if I see a bookshelf dominated by Jordan Peterson and Ayn Rand, I’m probably going to pass judgement on the reader, even if I know I shouldn’t.
I’ve always associated good design with thoughtfulness. Like, I should be able to point to any element in an interface and the designer should be able to tell me the reasons it’s there. Those reasons may be rooted in user needs or asthetics or some other consideration, but the point is that there’s a justification for it. Justify every pixel!
But I’ve come to realise that this is a bit reductionist. Now when I point at an interface element, I still expect the designer to be able to justify its inclusion, but I’d also like to know the trade-offs that were made.
Suppose there’s a large hero image. I’m sure the designer would have no problem justifying its inclusion on the basis of impact and the emotional heft it delivers. But did they also understand the potential downsides? Were they aware of the performance implications of including a large image?
I hope the answer to both questions is yes. They understood the costs, but they decided that, on balance, the positives outweighed the negatives.
When it comes to the positives, universal principles of design often apply. Colour theory, typography, proximity, and so on. But the downsides tend to be specific to the medium that the design is delivered in.
Let’s say you’re designing for print. You want to include an extra typeface just for footnotes. No problem. There isn’t really a downside. In print, you can use all the typefaces you want. But if this were for the web, then the calculation would be different. Every extra typeface comes with a performance penalty. A decision that might be justified in one medium might not work in another medium.
It works both ways; on the web you can use all the colours you want, without incurring any penalties, but in print—depending on the process you’re using—you might have to weigh up that decision very differently.
From this perspective, every design decision is like a balance sheet. A good web designer understands the benefits and the costs behind each decision they make.
It’s a similar story when it comes to web development. Heck, we even have the term “tech debt” to describe decisions that we know aren’t for the best in the long term.
In fact, I’d say that consideration of the long-term effects is something that should play a bigger part in technical decisions.
When we’re weighing up the pros and cons of using a particular tool, we have a tendency to think in the here and now. How might this help me right now? How might this hinder me right now?
But often a decision that delivers short-term gain may well end up delivering long-term pain.
Alexander Petros describes this succinctly:
Reopen a node repository after 3 months and you’ll find that your project is mired in a flurry of security warnings, backwards-incompatible library “upgrades,” and a frontend framework whose cultural peak was the exact moment you started the project and is now widely considered tech debt.
When I wrote about making the Patterns Day website I described my process as doing it “the long hard stupid way”—a term that Frank coined in a talk he gave a few years back. But perhaps my hands-on approach is only long, hard and stupid in the short time. With each passing year, the codebase will retain a degree of readability and accessibility that I would’ve sacrificed had I depended on automated build processes.
Robin Berjon puts this into the historical perspective of Taylorism and Luddism:
Whenever something is automated, you lose some control over it. Sometimes that loss of control improves your life because exerting control is work, and sometimes it worsens your life because it reduces your autonomy.
Or as Marshall McLuhan put it:
Every extension is also an amputation.
…which is fine as long as the benefits of the extension outweigh the costs of the amputation. My worry is that, when it comes to evaluating technology for building on the web, we aren’t considering the longer-term costs.
Maintenance matters. With the passing of time, maintenance matters more and more.
Maybe we avoid thinking about the long-term costs because it would lead to decision paralysis. That’s understandable. But I take comfort from some words of wisdom on the web from the 1990s. Tim Berners-Lee’s style guide for hypertext:
Because hypertext is potentially unconstrained you are a little daunted. Do not be. You can write a document as simply as you like. In many ways, the simpler the better.
Past some point, making a system more efficient will mean making it less resilient, and, conversely, building in robustness tends to make a system less efficient (at least in the short run).
This is true of software, networks, and organisations.
When we set metrics or goals for a system or a team or an organization that ask for efficiency, let us be aware that, absent countervailing pressures, we are probably also asking for the system to become more brittle and fragile, too.
Ahmad runs through some of the scenarios where text-wrap: balance
could be handy.
Even though it’s not well-supported yet in browsers, there’s no reason not to start adding it to sites now; it’s classic progressive enhancement.
Rich explains what text-wrap:balance
does …and what it doesn’t.
Trys has written up how he made that nifty little resizing widget on the Utopia homepage.
I love the idea of cultivating a sixth sense for the location of Sagittarius A.
(I bet Matt would get a kick out of Charlotte’s magnet fingers too.)
This is terrific! Jeremy shows how you can implement a fairly straightforward service worker for performance gains, but then really kicks it up a notch with a recipe for turning a regular website into a speedy single page app without framework bloat.
Playing Mulqueen’s (reel) on mandolin:
2010 was quite a year:
And exactly three weeks after Jeremy Keith’s HTML5 For Web Designers was first published, “Responsive Web Design” went live in A List Apart.
Nothing’s been quite the same since.
I remember being at that An Event Apart in Seattle where Ethan first unveiled the phrase and marvelling at how well everything just clicked into place, perfectly capturing the zeitgeist. I was in. 100%.
John’s article, A Dao Of Web Design, is twenty years old. If anything, it’s more relevant today than when it was written.
Here, John looks back on those twenty years, and forward to the next twenty…
- Write Chronologically, Not Spatially
- Write Left to Right, Top to Bottom
- Don’t Use Colors and Icons Alone
- Describe the Action, Not the Behavior
Celestial objects ordered by size, covering a scale from one astronaut to the observable universe.
Aaron outlines some sensible strategies for serving up images, including using the Cache API from your service worker script.
This chimes nicely with my recent post on third-party scripts. Here, Jeremy treats third-party JavaScript at technical debt and outlines some solutions to staying on top of it.
Convenience always has a price, and the web is wracked by our collective preference for it. JavaScript, in particular, is employed in a way that suggests a rapidly increasing tendency to outsource whatever it is that We (the first party) don’t want to do. At times, this is a necessary decision; it makes perfect financial and operational sense in many situations.
But make no mistake, third-party JavaScript is never cheap. It’s a devil’s bargain where vendors seduce you with solutions to your problem, yet conveniently fail to remind you that you have little to no control over the side effects that solution introduces.
A look at the ubiquitous computing work that Bret Victor has been doing over the past few years at Dynamicland.
A bit of a tangent, but I love this description of reading maps:
Map reading is a complex and uniquely human skill, not at all obvious to a young child. You float out of your body and into the sky, leaving behind the point of view you’ve been accustomed to all your life. Your imagination turns squiggly blue lines and green shading into creeks, mountains, and forests seen from above. Bringing it all together in your mind’s eye, you can picture the surroundings.
The story of Jack Garman and the 1202 alarm—as covered in episode two of the 13 Minutes To The Moon podcast.
Next time you’re faced with a decision, ask yourself: how can this decision be made on the lowest level? Have you given your team the authority to decide? If you haven’t, why not? If they’re not able to make good decisions, you’ve missed an opportunity to be a leader. Empower, enable, and entrust them. Take it from NASA: the ability to delegate quickly and decisively was the key to landing men on the moon.
On an individual and small collective basis, the IndieWeb already works. But does an IndieWeb approach scale to the general public? If it doesn’t scale yet, can we, who envision and design and build, create a new generation of tools that will help give birth to a flourishing, independent web? One that is as accessible to ordinary internet users as Twitter and Facebook and Instagram?
This is a fascinating insight into what it’s like to use the web if you’ve got vertigo (which is way more common than you might think):
Really, there are no words to describe just how bad a simple parallax effect, scrolljacking, or even
background-attachment: fixed
would make me feel. I would rather jump on one of those 20-G centrifuges astronauts use than look at a website with parallax scrolling.Every time I encountered it, I would put the bucket beside me to good use and be forced to lie in bed for hours as I felt the room spinning around me, and no meds could get me out of it. It was THAT bad.