A stylesheet for when you’re nostalgic for the old Mac OS.
Following on from that excellent blog post about removing jQuery from gov.uk, here are the performance improvements in charts and numbers.
This is a great thorough description of the process of migrating gov.uk away from jQuery. It sounds like this guide was instrumental in the process—I love that they’re sharing it openly!
I believe we aren’t nostalgic for the technology, or the aesthetic, or even the open web ethos. What we’re nostalgic for is a time when outsiders were given a chance to do something fun, off to the side and left alone, because mainstream culture had no idea what the hell to do with this thing that was right in front of it.
Much as I appreciate the optimism of this evaluation, I don’t hold out much hope that people’s expectations are going to change any time soon:
Indeed, when given a choice, users will opt for the [native] app version of a platform because it’s been considered the gold standard for reliability. With progressive web apps (PWAs), that assumption is about to change.
Nonetheless, this is a level-headed look at what a progressive web app is, mercifully free of hand-waving:
- App is served through HTTPS.
- App has a web app manifest with at least one icon. (We’ll talk more about the manifest shortly.)
- App has a registered service worker with a fetch event handler. (More on this later too.)
Are you a web dev that’s into progressive enhancement, accessibility, design systems, and all that good stuff?
You should come and work with me at Clearleft.
The day we started to allow email clients to be full-blown web browsers (but without the protections of browsers) was the day we lost — time, security, privacy, and effectiveness. Now we spend all our time fighting with the materials of an email (i.e. color and layout) rather than refining its substance (i.e. story and language).
I really, really enjoyed this deep dive into practical HTML semantics. Sit back and enjoy!
The algorithm I’m going after is pretty simple: If the grid of items has an odd number of items, then make the first item full-width. But CSS can’t do logic… right? Well… hold my proverbial beer.
Prompted by my recent post about using native
button elements, Trys puts forward a simple explanation for why someone would choose to use a
The one common feature between every codebase I’ve encountered on that doesn’t use
buttons well, is a bad CSS reset. Developers try to use a
button, and find that it still looks like a native browser button, so they grab a plain old, blank canvas
div, and build from there.
Occam’s Razor makes Trys’s explanation the most likely one.
I really enjoyed Laurie’s talk in Berlin a few weeks back. I must blog my thoughts on it.
But I must admit that something didn’t sit quite right about the mocking tone he took on the matter of “the fundamentals” (whatever that may mean). Chris shares my misgivings:
Those websites that don’t load on slow connections, or break completely when a JS file fails to load, or don’t work for people with visual or physical impairments?
That’s not an issue of time. It’s an issue of fundamentals.
I think I agree with Laurie that there’s basically no such thing as fundamental technologies (and if there is such a thing, the goalposts are constantly moving). But I agree with Chris with that there is such a thing as fundamental concepts. On the web, for example, accessibility is a core principle of its design that should, in my opinion, be fundamental.
Do I wanna see teenagers building frivolous websites? Absolutely. But when people are getting paid well to build our digital world, they have a responsibility to ensure the right to engage with that world for everyone.
So to me, this blog represents the original promise of the open web.
The one that’s here, and still is here, and always has been here, and is available to you.
The one where you can speak the truths that you believe without the permission, or the editorial control, or the power dynamics, of anyone claiming to hold authority over you; or, perhaps, anyone keen to impose it.
Heather takes a break from her relentless crusading in favour of users against the idiocy of the UK government and reflects on the joy of doing it all from her own personal website.
And perhaps you should too, on your own blog, owned on your own hosting space, using your own words, and speaking your own truth. That sounds like a good little weekend project, don’t you think?
I love this kind of spelunking into the history of why things are they way they are on the web!
Here, Detective Chief Inspector Suzanne tries to get to the bottom of why every browser has eight pixels of margin applied to the
body element in the user-agent stylesheet.
If only all thinkpieces on complexity in software development were written in such an entertaining style! (Although, admittedly, that would get very old very fast.)
A layman’s guide to thinking like the self-aware smol brained
The headline is clickbaity, but the advice is solid. Use progressive enhancement and don’t worry about polyfilling.
When I say ‘Stop supporting IE’ it means to me that I won’t go the extra mile to get unsupported features working in Internet Explorer, but still make sure Internet Explorer users get the basics, and can use the site.
The problem I’ve regularly encountered in my work is that I don’t get to do my job the way I think is best for both me and my employer or client. The employer, who isn’t the web development expert, almost always has a clear idea of what real web development is supposed to look like: Single-Page-Apps and React (or React-like frameworks).
An intimation that it wouldn’t be the right solution for this particular problem is taken as an admission of incompetence.
I’ve experienced this. And I think this observation is even more true when it comes to recruitment.
While I’ve always been bothered by the downsides of SPAs, I always thought the gap would be bridged sooner or later, and that performance concerns would eventually vanish thanks to things like code splitting, tree shaking, or SSR. But ten years later, many of these issues remain. Many SPA bundles are still bloated with too many dependencies, hydration is still slow, and content is still duplicated in memory on the client even if it already lives in the DOM.
Yet something might be changing: for whatever reason, it feels like people are finally starting to take note and ask why things have to be this way.
Interesting to see a decade-long perspective. I especially like how Sacha revisits and reasseses design principles from ten years ago:
- Data on the Wire. Don’t send HTML over the network. Send data and let the client decide how to render it.
It’s since become apparent that you often do need to send HTML over the network, and things seem to be moving back towards handling as much as possible of your HTML compilation on the server, not on the client.
This is such a great clear explanation from Lynn on how to add some tasteful parallax depth to scrolling pages.
That’s the way to do it!
Concepts like progressive enhancement allow us to deliver the best experience possible to the majority of customers, while delivering a useful experience to those using older browsers.
Read on for the nitty-gritty details…
I love these notes on my recent talk!