| 5th | 10th | 15th | 20th | 25th | 30th | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 12am | |||||||||||||||||||||||||||||||
| 4am | |||||||||||||||||||||||||||||||
| 8am | |||||||||||||||||||||||||||||||
| 12pm | |||||||||||||||||||||||||||||||
| 4pm | |||||||||||||||||||||||||||||||
| 8pm |
I think this might be the most excited I’ve been in quite some time about an update to browser support, which probably says a lot about my priorities:
Support for the
avoidvalue of the CSS fragmentation propertiesbreak-before,break-after, andbreak-insidewhen printing.
Finally!
A lovely collection of blogs (and RSS feeds) that you can follow.
(Just in case, y’know, you might decide that following people on their own websites is better than following them on a website controlled by one immature manbaby who’s down with the racists.)
But most importantly, always write your most important thoughts on your own site. You can share the link on as many platforms as you like and have conversations with anyone who wants to connect with you and your work. But nobody can take it from you. You are in control. Forever.
This is how I feel when I open up my feed reader—it feels like the opposite of opening Twitter:
The web remains a sea of interconnected ideas, across a kaleidoscope of forms and sources. Spending most of my time on just a handful of billion dollar sites squanders the possibilities and runs contrary to my values. There’s so much to be said for diversifying inputs, but there are only so many hours. It makes sense to economize.
Some common geographic mental misplacements.
Pessimism always sounds smarter than optimism because optimism sounds like a sales pitch while pessimism sounds like someone trying to help you.
I usually hate these kinds of lists of bumper-sticker aphorisms but some of these have me pondering my own work, like this one:
People learn when they’re surprised. Not when they read the right answer, or are told they’re doing it wrong, but when they experience a gap between expectations and reality.
Or this:
There are two types of information: stuff you’ll still care about in the future, and stuff that matters less and less over time. Long-term vs. expiring knowledge.
A terrific piece by Maggie Appleton that starts with a comparison of graphical user interfaces and command line tools—which reminds me of the trade-offs between seamless and seamful design—and then moves into a proposed paradigm for declarative design tools:
Small, scoped areas within a graphical interface that allow users to read and write simple programmes
Here’s the video of the talk I gave at Web Dev Conf in Bristol recently. I think you can tell that I had fun—it was a good audience!
Your easy guide to starting a new blog.
A blog is an easy way to get started writing on the web. Your voice is important: it deserves its own site. The more people add their unique perspectives to the web, the more valuable it becomes.
A reminder that silos like Twitter can suspend your account without warning for no reason.
Having your own website is good.
I’ve smelt the same change in the wind that Chris describes here—there’s finally a reckoning happening in the world of JavaScript frameworks and single page apps.
I’ve seen the pendulum swing back and forth many times over my years building on the web. I too feel like there’s something in the air right now, and people are finally acknowledging that most single page apps are crap.
But Brad makes the interesting point that, because they were incubated when profligate client-side JavaScript was all the rage, web components may have ended up inheriting the wrong mindset:
So now the world of web components has egg on its face because the zeitgeist at the time of its design didn’t have such a strong focus on SSR/HTML-first/ progressive enhancement. Had web components been designed in the current zeitgeist, things would almost certainly be different.
Trys has written up how he made that nifty little resizing widget on the Utopia homepage.
I was talking about this with Léonie just yesterday. I, for one, would love to have CSS speech support. You know who else would love it? Content designers!
In these days of voice interaction on every platform, there is a growing expectation that it should be possible to design that experience just like we can the visual experience. In the same way an organisation chooses a logo and colour palette for its website, it stands to reason that they may also choose a particular voice that represents their brand.
It’s wild that there’s no way to do this on the web.
Guess which format is going to outlast all these proprietary syndication formats. I’d say RSS, which I believe to be true, but really, it’s HTML.
This observation feels spot-on to me:
The shift that I noticed, totally anecdotally, is literary writers are starting to write more dystopian climate futures and science fiction writers are starting to write about climate solutions.
A demonstration of how even reinventing a relatively simple wheel takes way more effort than it’s worth when you could just use what the brower gives you for free.
You don’t need to write for anyone else. You don’t need to share, or even keep it. You just need the act of it. Writing is a particle collider for reality and the imagination. And new discoveries are the result.
(That’s why I write here, of course. It’s how I think.)
It me.
If, like me, you despair at the tech stacking and JavaScriptification of everything, shut that out and pay attention to those who understand the material of the web, its inherent resilience and efficiency. We’re lucky that principled voices still advocate for simple and inclusive methods because building with efficiency and a lightness of touch makes the work feel meaningful and, sometimes, fun.
There are two JavaScripts.
One for the server - where you can go wild.
One for the client - that should be thoughtful and careful.
Yes! This! I’m always astounded to see devs apply the same mindset to backend and frontend development, just because it happens to be in the same language. I don’t care what you use on your own machine or your own web server, but once you’re sending something down the wire to end users, you need to prioritise their needs over your own.
It’s the JavaScript on the client side that’s the problem. What’s given to the visitor.
I’d ask you, if you’re still reading, that you consider a separation of JavaScript between client and server. If you’re a dev, consider the payload, your bundle and work to reduce the cost to your visitor. Heck, think progressive enhancement.
A free PDF with five articles:
Three of those authors spoke at this year’s UX London!
Doug casts an eye back on the Wired redesign he worked on 20 years ago. It’s hard to overstate the impact this had on the adoption of web standards.
We’ve come a long way:
We’ve come so far since this redesign in 2002. We no longer trip ourselves up trying to fit everything above an imaginable fold. Designs respond to various screen sizes. Text is comfortably larger and screens display at a much higher resolution. We tend to give everything more breathing room.
A whole lotta nice fonts—most of them variable fonts—from Indian Type Foundry.
The primary benefit of Progressive Enhancement is not that “your app works without JavaScript” (though that’s a nice side-benefit) but rather that the mental model is drastically simpler.
I think that’s the primary benefit to developers. The primary benefit to users is that what you build will faster and more resilient.
Anyway, this is a really good deep dive into different architectural choices for building on the web. Although I was surprised by this assertion in the first paragraph:
The most popular architecture employed by web developers today is the Single Page App (SPA)
Citation needed. Single Page Apps do indeed dominate the discussion, but I don’t think that necessarily matches the day-to-day reality.
I realised, progressive enhancement isn’t only about supporting that 1%. It’s about testing your app without JavaScript to ensure 100% of your users have a more performant, usable, available, and resilient experience.
A really good explanation of progressive enhancement as an approach to building anything on the web:
Progressive enhancement does not mean you need to provide the exact same UI without JavaScript. The enhanced experience should be better and it should do more, otherwise the enhanced experience is not needed at all. It enhances a degraded experience that also allows the user to accomplish their goal. For example, entering a postal code manually into a text box might be the degraded experience, and the progressively enhanced experience would prefill the text box based on Geolocation data.
A drop-in replacement for Google Fonts without the tracking …but really, you should be self-hosting your font files.
A lovely heartfelt personal look back at dConstruct.
dConstruct was about the big ideas, but not in a wanky TED way. It was about ideas on the horizon brought into focus, it always left me wanting to know more.
dConstruct was never about the big showy thing that will make you millions. It was about the interesting. It gave you seeds to take away with you, and that’s important.
I wrote a while back about descriptive and prescriptive design systems—and a follow-up post—but I didn’t realise there was such a thing as descriptive and prescriptive engineering.
This story of the Network Time Protocol hammers home the importance of infrastructure and its maintenance:
Technology companies worth billions rely on open-source code, including N.T.P., and the maintenance of that code is often handled by a small group of individuals toiling away without pay.
I’ve done this quite a bit: using ARIA attributes as “hooks” for styling and behaviour. It’s a way of thinking of accessibility as the baseline to build upon rather than something that can sprinkled on top later.
I get it. React feels good and it’s sticky. But all frameworks eventually fizzle out.
Thanks to Web Components, large companies are realizing you don’t need to rebuild buttons and other UI primitives every few years. Teams don’t need to argue about frameworks anymore. You can have your cake and eat it too!
I think this may be the best long-term argument for web components:
Any org that goes all in on a single framework will eventually find themselves swimming upstream to hire talent to maintain legacy code and avoid framework rot. But you can reduce this burden (and the associated costs) by using Web Components in your design system.
I love this list of ever-increasing timelines. All that’s missing is the time since the Carrington Event, just to remind us what could happen when the next one hits.