| 5th | 10th | 15th | 20th | 25th | 30th | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 12am | ||||||||||||||||||||||||||||||
| 4am | ||||||||||||||||||||||||||||||
| 8am | ||||||||||||||||||||||||||||||
| 12pm | ||||||||||||||||||||||||||||||
| 4pm | ||||||||||||||||||||||||||||||
| 8pm |
See, when I first heard about background-repeat: round; I thought it was something to do with making things circular. But no, it’s about tiling a background image so that nothing gets cut off. The amount of tiling required is rounded to the nearest whole number.
Now I get it.
This
will-changeproperty that was intended to SOLVE problems for animators may end up doing the opposite.It seems wise for the browsers to step back and let the spec authors fill in the implementation details and gain consensus before moving forward.
Sous vide lamb.
In the latest issue of Justin’s excellent Responsive Web Design weekly newsletter, he includes a segment called “The Snippet Show”:
This is what tells all our browsers on all our devices to set the viewport to be the same width of the current device, and to also set the initial scale to 1 (not scaled at all). This essentially allows us to have responsive design consistently.
<meta name="viewport" content="width=device-width, initial-scale=1">
The viewport value for the meta element was invented by Apple when the iPhone was released. Back then, it was a safe bet that most websites were wider than the iPhone’s 320 pixel wide display—most of them were 960 pixels wide …because reasons. So mobile Safari would automatically shrink those sites down to fit within the display. If you wanted to over-ride that behaviour, you had to use the meta viewport gubbins that they made up.
That was nine years ago. These days, if you’re building a responsive website, you still need to include that meta element.
That seems like a shame to me. I’m not suggesting that the default behaviour should switch to assuming a fluid layout, but maybe the browser could just figure it out. After all, the CSS will already be parsed by the time the HTML is rendering. Perhaps a quick test for the presence of a crawlbar could be used to trigger the shrinking behaviour. No crawlbar, no shrinking.
Maybe someday the assumption behind the current behaviour could be flipped—assume a website is responsive unless the author explicitly requests the shrinking behaviour. I’d like to think that could happen soon, but I suspect that a depressingly large number of sites are still fixed-width (I don’t even want to know—don’t tell me).
There are other browser default behaviours that might someday change. Right now, if I type example.com into a browser, it will first attempt to contact http://example.com rather than https://example.com. That means the example.com server has to do a redirect, costing the user valuable time.
You can mitigate this by putting your site on the HSTS preload list but wouldn’t it be nice if browsers first checked for HTTPS instead of HTTP? I don’t think that will happen anytime soon, but someday …someday.
It’s Geek Mental Help Week from Monday. You can get involved.
I believe that talking about mental health issues and sharing our experiences—not just those of people who suffer, but also those who live with and support us—can help everyone. Whether you struggle with your own mental health or care for someone who does, you can help others to understand how you cope. Geek Mental Help Week is all about sharing those experiences.
A spot of six-up sketching at @Clearleft.
Kebab.
Eagerly anticipating a kebab from @TheTrollsPantry.
Sci-fi book covers and posters from the 1970s.
So long and thanks for all the pics.
https://www.flickr.com/photos/europeanspaceagency/sets/72157638315605535/
Napoletana.
A thorough and compelling demonstration of why it makes sense to size all the properties of your components—font size, margins, borders, etc.—in ems or rems rather than mixing in pixels for some properties. It’s all about the scalability, innit?
This is not only a really good explanation of CSS grid layout, it’s also a practical walkthrough, recreating the layout of the Financial Times. I think if I followed along at home, writing the markup and CSS outlined here, it would me to get this stuff “clicking” in my brain.
Passed by a second-hand book stall on the way into work. My defences were down.
Not a bad haul for a fiver.
Gazing at moonlander.seb.ly like it’s one big interactive screensaver.
Ramen.
Playing a game of “spin the sharpie” with @LotteJackson’s topics for @FrontEndNorth.
Jen tackles six aspects of web design that were true …but no longer.
- Everything must be a floating bar of soap
- Rectangles; only rectangles
- We can’t control the fold
- 12 columns is best
- We have to use a layout framework
- We are stuck in a rut because of RWD
Chrome is going to refuse to parse document.write for users on a slow connection. On the one hand, I feel that Google intervening in this way is a bit icky, but I on the other hand, I totally support this move.
This keeps happening. Google announce a change (usually related to search) where I think “Ooh, that could be interpreted as an abuse of a monopoly position …but it’s for ver good reason so I’ll keep quiet.”
Anyway, this should serve as a good kick in the pants for bad actors (that’s you, advertisers) to update their scripts to be asynchronous.
Scribble’s hanging out in the @Clearleft office.
Chris runs through the process and pitfalls of POSSEing a site (like CSS Tricks) to Apple’s News app, Facebook’s Instant Articles, and Google’s AMP.
Hey, whatever you want. As long as…
- It’s not very much work
- The content’s canonical home is my website.
I just want people to read and like CSS-Tricks.
Slack ammo.
Here’s a handy graph from Paul:
Powered by data from caniuse.com and StatCounter, this page indicates the percentage of users who have a browser that natively supports various web platform features.
Freshly shorn.
Disappointed in your cakes I am.
Feeling very fortunate today to have seen sneak peeks of conference talks by both @LotteJackson and @MikeRiethmuller.
My brain is full.
This is a really great step-by-step walkthrough of adding a service worker to a website. Mike mentions the gotchas he encountered along the way, and describes how he incrementally levelled up the functionality.
If you’ve been going through a similar process, please write it down and share it like this!
Dining with the Cult of the Triangle Eggs for breakfast.
It’s playback time at @Clearleft.
My new favourite Twitter account.
The Museum of Wi-Fi exists to preserve these vestiges of our neighbourhood battlefields.
Some are brilliantly smart, some are just purely gross. They all belong in the museum.
Indie Web Camp Brighton 2016 is done and dusted. It’s hard to believe that it’s already in its fifth(!) year. As with previous years, it was a lot of fun.
The first day—the discussions day—covered a lot of topics. I led a session on service workers, where we brainstormed offline and caching strategies for personal websites.
There was a design session looking at alternatives to simply presenting everything in a stream. Some great ideas came out of that. And there was a session all about bookmarking and linking. That one really got my brain whirring with ideas for the second day—the making/coding day.
I’ve learned from previous Indie Web Camps that a good strategy for the second day is to have two tasks to tackle: one that’s really easy (so you’ve at least got that to demo at the end), and one that’s more ambitious. This time, I put together a list of potential goals, and then ordered them by difficulty. By the end of the day, I managed to get a few of them done.
First off, I added a small bit of code to my bookmarking flow, so that any time I link to something, I send a ping to the Internet Archive to grab a copy of that URL. So here’s a link I bookmarked to one of Remy’s blog posts, and here it is in the Wayback Machine—see how the date of storage matches the date of my link.
The code to do that was pretty straightforward. I needed to hit this endpoint:
http://web.archive.org/save/{url}
I also updated my bookmarklet for posting links so that, if I’ve highlighted any text on the page I’m linking to, that text is automatically pasted in to the description.
I tweaked my webmentions a bit so that if I receive a webmention that has a type of bookmark-of, that is displayed differently to a comment, or a like, or a share. Here’s an example of Aaron bookmarking one of my articles.
The more ambitious plan was to create an over-arching /tags area for my site. I already have tag-based navigation for my journal and my links:
But until this weekend, I didn’t have the combined view:
I didn’t get around to adding pagination. That’s something I should definitely add, because some of those pages get veeeeery long. But I did spend some time adding sparklines. They can be quite revealing, especially on topics that were hot ten years ago, but have faded over time, or topics that have becoming more and more popular with each year.
All in all, a very productive weekend.
Monday morning strategies from 1982 courtesy of @qwertykate.
Seb is going to be closing out the Brighton Digital Festival with a bang.
Seb unravels all the geeky details about how your favourite retro gadgets work, including Nintendo light guns, Casio keyboards and the cathode ray tube televisions that once dominated our living rooms.
It’s going to be like Seb: The Musical …with lasers.
Adding @aaronpk to the bedroll on https://adactio.com/
Dessert.
The new album from @TheOrchid is the perfect soundtrack for hacking through day two of Indie Web Camp Brighton.
I’m following Remy’s experiments with great interest—his approach sounds like the holy grail:
I’m trying to build a web app that uses progressive enhancement as a design principle with state as a core value to the coding approach.
Val Head and Sarah Drasner have teamed up to offer a two-day workshop on web animation. If you have a chance to attend, do it!
Heydon asked screen readers some questions about their everyday interactions with websites. The answers quite revealing: if you’re using headings and forms correctly, you’re already making life a lot easier for them.
Ready for day two of Indie Web Camp Brighton.
If you fancy working on your own website today, swing on by @68MiddleSt.
That’s a wrap for day one of Indie Web Camp Brighton.
Excited for day two!
This is rather lovely: explore a network of nodes, each of which contains the audio of a child describing a dream.
Inspired by the concept of an 8th continent to which all children belong, RadioEight is an interactive soundscape dedicated to the hidden world of dreams.
Sous-vide cod with peppers on lentils.
Met up with @rem for a coffee and now my brain is buzzing with ideas about the web.
Whisked home on the URL-tipped wings of a flying machine.
PPK reads a Hacker News thread so you don’t have to.
I can very much relate to Jonathan’s learning process (except for the bit about reading Hacker News—spit):
- Reading
- Building
- Writing
I think I read about 20-30 times more than I write, but the writing part is still crucial for helping me get stuff straight in my own head.
Lamb.
If it’s Thor’s Day, it must be Oslo.
Listening to @clagnut deliver an utterly captivating talk on web typography at the Making Web conference.
A gripping history lesson of the internet and the ARPANET before it, emphasising the role of government funding.
Silicon Valley often likes to pretend that innovation is the result of entrepreneurs tinkering in garages. But most of the innovation on which Silicon Valley depends comes from government research, for the simple reason that the public sector can afford to take risks that the private sector can’t.
It’s precisely the insulation from market forces that enables government to finance the long-term scientific labor that ends up producing many of the most profitable inventions.
Today we have an internet effectively controlled by a small number of private companies.
Instead of trying to escape the bigness of the Internet, we should embrace it — and bring it under democratic control. This means replacing private providers with public alternatives where it’s feasible, and regulating them where it’s not.
There is nothing in the pipes or protocols of the Internet that obliges it to produce immense concentrations of corporate power. This is a political choice, and we can choose differently.
Going to Oslo. brb
Jen has some ideas for a new CSS Region spec to turbo-boost Grid. I’m still trying to wrap my head around it, but in the meantime, if you have feedback on this, please let her know.
Progressive Web Apps versus native is the wrong question because every step on the path to a Progressive Web App makes sense on its own, irrespective of what a company does with their native apps.
Not all of your customers are going to have your app installed. For those who visit via the web, providing them with a better experience will make them happier and generate more revenue for your business.
It’s really that simple.
Steve describes a script you can use on WebPageTest to simulate going offline so you can test how your progressive web app performs.
This is easily the most wrong-headed piece of writing I’ve read in a long time.
“But customers benefit from smaller file sizes too, because that makes web pages faster.” Certainly, that was true in 1996. And some web developers persist with political objections. But with today’s faster connections—even on mobile—optimizing for file size is less useful than ever.
I’ll leave it to you to see the logical flaws in every one of the arguments presented here by Matthew Buterick. Meanwhile I’m going to get off his lawn.
Can’t move. Dog on foot.
Tomato, sumac, pomegranate and mint salad.
This is a terrific read that gets to the heart of why progressive enhancement is such a solid methodology: progressive enhancement improves resilience.
Meeting our many users’ needs is number one on our list of design principles. We can’t know every different setup a person might use while building our systems, but we can build them in a way that gives all of our users the greatest chance of success. Progressive enhancement lets us do this.
The article is full of great insights from a very large-scale web project.
Kate and Poppy.
Alas, no Brighton Homebrew Website Club this week …but Indie Web Camp this weekend!
A nice introduction to progressive web apps. There’s a little bit of confusion about permissions—whether a site has been added to the home screen or not has no effect on the permissions granted to it (for things like push notifications)—but the wrap-up nails the advantages of using the web:
No more waiting to download an app, no more prompts for updating an app. From a developer perspective, it means we will be able to iterate a lot quicker. We don’t need to wait for app store approvals anymore, and we can deploy at our own leisure.
Another advantage that a progressive web app has over a native mobile app is that it is linkable, hence it is easier to share and, probably even more importantly, can be indexed by search engines. This makes discoverability of the app a lot better.
This is what Nick Sherman has been banging on about for years, and now the time has come for variable fonts …as long as typographers, browser makers, and standards bodies get behind it.
More details on Ev’s blog.
Poppy’s in the @Clearleft office today!
Giving @qwertykate a souvenir of Berlin.
I’m just back from a little mini 3-conference tour of Europe where I was delivering my talk on resilience. The first stop was Stockholm for Nordic.js and the video is already online.
Jonathan takes a look at the physical web. Like me, he’s excited by the possibilities. Although he says:
Sadly, my mind quickly devolved into the annoyance of numerous notifications, like popup windows and other distracting adverts, vying for my attention.
This is a common worry with the physical web, but it’s unfounded. All a beacon does is broadcast a URL. You have to actively look for the URLs being broadcast—they can’t send notifications.
It all just feels like QR codes. They’ll be all over the place and most of them won’t be very useful.
I understand this concern, but whereas QR codes are completely opaque to humans, at least URLs can—and should—be human-readable …so, unlike QR codes, a URL can give you some idea of what awaits.
But, like, have you have ever really looked at your hand?
This one is definitely for service worker nerds only. I’ve been trying to get my head around this idea of “foreign fetch” which allows third parties to install service workers—could be handy for sites with APIs like Huffduffer and The Session. This article does a good job of explaining the somewhat tangled process.
Alex runs through the features that a progressive web app must have, should have, and would be nice to have.
In general, installability criteria are tightening. Today’s Good-To-Haves may become part of tomorrow’s baseline. The opposite is unlikely because at least one major browser has made a strong commitment to tightening up the rules for installability.
Right now, this is in the nice-to-have category:
Mobile-friendly, not mobile-only.
Personally, I’d put that in the must-have category, and not just for progressive web apps.
Anyway, read on for some advice on testing and tooling when it comes to evaluating progressive web apps.
Lyza put together some example code for her Smashing Conference talk on service workers. If you haven’t written a service worker before, these are really nice examples of how to grok it bit by bit.
Roast chicken and potatoes.
Back home in Brighton after a lovely little trip around some delightful European cities:
English breakfast.
Tripa e fagioli.
Spaghetti vongole.
I think @wordridden likes Venice.
Gondola.
Portal.
Canal.
Admiring the craftsmanship of an 18th century Neopolitan mandolin.
Light on the water.
Passage.
Canalettoesque.
Ah, Venice!
Cappuccino.
Rigatoni.
Dessert madness!
Bologna at night.
Aperitivo.
Pizza.
Mushroom tagliatelle.
Cheeses.
Listening to @bensauer deliver a fantastic talk at From The Front.
Listening to klezmer jazz (complete with bouzouki) in a balmy Bologna courtyard.
I think I can hear @patrickhamann rehearsing his From The Front talk in the hotel room next door. Sounds good.
Tagliatelle al ragu.
Zucchini.
Mascarpone with strawberries.
Tagliere di salumi.
Photo shoot.
Arches.
Bologna ballerina.
Recharging with an espresso.
Looking down on a tower from a tower.
Ciao bella!
A room with a view.
Going to Bologna. brb
Bye bye, Berlin.
This should be a lot more straightforward than process I linked to before.
Hey @ScottJenson, check out all the physical web beacons here at @viewsourceconf.
Shout-out to @clagnut from @helenvholmes at the View Source conference.
Guten Morgen, @viewsourceconf.
Cooling off with a hefeweizen.
Currywurst.
It’s always, um …”interesting” when a mainstream publication covers a topic from the web’s bikeshed. In this case, it’s progressive web apps, and—apart from the sensationalist headline—it’s actually not that bad at all.
This slide deck is a whistle-stop tour of all things styleguide and pattern-library related. Nice to see Charlotte’s excellent exercise get a shout-out.
Bookmark this page! Who knew that so much knowledge could be condensed into one document? In this case, it’s life-saving git commands, explained in a user-centred way.
So here are some bad situations I’ve gotten myself into, and how I eventually got myself out of them in plain english.
I’m no fan of mega menus, and if a site were being designed from scratch, I’d do everything I could to avoid them, but on some existing projects they’re an unavoidable necessity (the design equivalent of technical debt). In those situations, this looks like a really nice, responsive approach.
Some typically smart thinking from Mike—what if success were measured in learning rather than shipping?
Organizations that learn the quickest seem the most likely to succeed over the long haul.
This really resonates with me, and it aligns so closely with our values at Clearleft that I think this is something we should be pursuing. Fortunately Mike’s post comes with plenty of examples and ideas.
A good ol’ polemic in favour of using web fonts. It’s a good read although I strongly disagree with this line of reasoning:
The average internet speed in the United States today is three times as fast as it was in 2011.
But that americentric view is redeemed later on:
The World Wide Web may be a creation of the West, but now, at long last, it needs to get ready for the rest.
I may not agree with all the points in this article, but I think we can all agree that if we’re going to use web fonts, we must use them responsibly …otherwise users are going to treat them as damage and route around them.
Gyoza.
Sashimi.
Mauer.
Ein bisle Schwarzwald im Hauptstadt.
Hello, Berlin.
Going to Berlin. brb
Stockholm street.
Rigging.
Finngrundet.
Captain Jessica.
Sankt Erik, icebreaker.
Swedish meatballs.
On a boat.
I love listening to @ag_dubs talk.
Going to Stockholm. brb
I’m recovering from an illness that laid me low a few weeks back. I had a nasty bout of man-flu which then led to a chest infection for added coughing action. I’m much better now, but alas, this illness meant I had to cancel my trip to Chicago for An Event Apart. I felt very bad about that. Not only was I reneging on a commitment, but I also missed out on an opportunity to revisit a beautiful city. But it was for the best. If I had gone, I would have spent nine hours in an airborne metal tube breathing recycled air, and then stayed in a hotel room with that special kind of air conditioning that hotels have that always seem to give me the sniffles.
Anyway, no point regretting a trip that didn’t happen—time to look forward to my next trip. I’m about to embark on a little mini tour of some lovely European cities:
The only downside to leaving town for this whirlwind tour is that there won’t be a Brighton Homebrew Website Club tomorrow. I feel bad about that—I had to cancel the one two weeks ago because I was too sick for it.
But on the plus side, when I get back, it won’t be long until Indie Web Camp Brighton on Saturday, September 24th and Sunday, September 25th. If you haven’t been to an Indie Web Camp before, you should really come along—it’s for anyone who has their own website, or wants to have their own website. If you have been to an Indie Web Camp before, you don’t need me to convince you to come along; you already know how good it is.
Sign up for Indie Web Camp Brighton here. It’s free and it’s a lot of fun.
The importance of owning your data is getting more awareness. To grow it and help people get started, we’re meeting for a bar-camp like collaboration in Brighton for two days of brainstorming, working, teaching, and helping.
No Brighton Homebrew Website tomorrow evening, alas—I’m going to be out of town.
The font-display property is landing in browsers, and this is a great introduction to using it:
If you don’t know which option to use, then go with
swap. Not only does it provide an optimal balance between custom fonts and accessibility of content, it provides the same font loading behavior that we’ve relied on JavaScript for. If you have fonts on the page that you’d like to have load, but could ultimately do without, consider going withfallbackoroptionalwhen usingfont-display.
Until it’s more widely supported, you can continue to use a JavaScript solution, but even then you can feature detect first:
if ("fontDisplay" in document.body.style === false) {
/* JavaScript font loading logic goes here. */
}
Miso sockeye salmon, miso sweet potato, cabbage salad, and padron peppers.
This is a really good overview of progressive web apps:
An ideal web app is a web page that has the best aspects of both the web and native apps. It should be fast and quick to interact with, fit the device’s viewport, remain usable offline and be able to have an icon on the home screen.
At the same time, it must not sacrifice the things that make the web great, such as the ability to link deep into the app and to use URLs to enable sharing of content. Like the web, it should work well across platforms and not focus solely on mobile. It should behave just as well on a desktop computer as in other form factors, lest we risk having another era of unresponsive m.example.com websites.
Jason shared some thoughts on designing progressive web apps. One of the things he’s pondering is how much you should try make your web-based offering look and feel like a native app.
This was prompted by an article by Owen Campbell-Moore over on Ev’s blog called Designing Great UIs for Progressive Web Apps. He begins with this advice:
Start by forgetting everything you know about conventional web design, and instead imagine you’re actually designing a native app.
This makes me squirm. I mean, I’m all for borrowing good ideas from other media—native apps, TV, print—but I don’t think that inspiration should mean imitation. For me, that always results in an interface that sits in a kind of uncanny valley of being almost—but not quite—like the thing it’s imitating.
With that out of the way, most of the recommendations in Owen’s article are sensible ideas about animation, input, and feedback. But then there’s recommendation number eight: Provide an easy way to share content:
PWAs are often shown in a context where the current URL isn’t easily accessible, so it is important to ensure the user can easily share what they’re currently looking at. Implement a share button that allows users to copy the URL to the clipboard, or share it with popular social networks.
See, when a developer has to implement a feature that the browser should be providing, that seems like a bad code smell to me. This is a problem that Opera is solving (and Google says it is solving, while meanwhile penalising developers who expose the URL to end users).
Anyway, I think my squeamishness about all the advice to imitate native apps is because it feels like a cargo cult. There seems to be an inherent assumption that native is intrinsically “better” than the web, and that the only way that the web can “win” is to match native apps note for note. But that misses out on all the things that only the web can do—instant distribution, low-friction sharing, and the ability to link to any other resource on the web (and be linked to in turn). Turning our beautifully-networked nodes into standalone silos just because that’s the way that native apps have to work feels like the cure that kills the patient.
If anything, my advice for building a progressive web app would be the exact opposite of Owen’s: don’t forget everything you’ve learned about web design. In my opinion, the term “progressive web app” can be read in order of priority:
Jason asks questions about how your progressive web app will behave when it’s added to the home screen. How much do you match the platform? How do you manage going chromeless? And the big one: what do users expect?
Will people expect an experience that maps to native conventions? Or will they be more accepting of deviation because they came to the app via the web and have already seen it before installing it?
These are good questions and I share Jason’s hunch:
My gut says that we can build great experiences without having to make it feel exactly like an iOS or Android app because people will have already experienced the Progressive Web App multiple times in the browser before they are asked to install it.
In all the messaging from Google about progressive web apps, there’s a real feeling that the ability to install to—and launch from—the home screen is a real game changer. I’m not so sure that we should be betting the farm on that feature (the offline possibilities opened up by service workers feel like more of a game-changer to me).
People have been gleefully passing around the statistic that the average number of native apps installed per month is zero. So how exactly will we measure the success of progressive web apps against native apps …when the average number of progressive web apps installed per month is zero?
I like Android’s add-to-home-screen algorithm (although it needs tweaking). It’s a really nice carrot to reward the best websites with. But let’s not carried away. I think that most people are not going to click that “add to home screen” prompt. Let’s face it, we’ve trained people to ignore prompts like that. When someone is trying to find some information or complete a task, a prompt that pops up saying “sign up to our newsletter” or “download our native app” or “add to home screen” is a distraction to be dismissed. The fact that only the third example is initiated by the operating system, rather than the website, is irrelevant to the person using the website.
My hunch is that the majority of people will still interact with your progressive web app via a regular web browser view. If, then, only a minority of people are going to experience your site launched from the home screen in a native-like way, I don’t think it makes sense to prioritise that use case.
The great thing about progressive web apps is that they are first and foremost websites. Literally everyone who interacts with your progressive web app is first going to do so the old-fashioned way, by following a link or typing in a URL. They may later add it to their home screen, but that’s just a bonus. I think it’s important to build progressive web apps accordingly—don’t pretend that it’s just like building a native app just because some people will be visiting via the home screen.
I’m worried that developers are going to think that progressive web apps are something that need to built from scratch; that you have to start with a blank slate and build something new in a completely new way. Now, there are some good examples of these kind of one-off progressive web apps—The Guardian’s RioRun is nicely done. But I don’t think that the majority of progressive web apps should fall into that category. There’s nothing to stop you taking an existing website and transforming it step-by-step into a progressive web app:
See? Not exactly a paradigm shift in how you approach building for the web …but those deceptively straightforward steps will really turbo-boost your site.
I’m really excited about progressive web apps …but mostly for the “progressive” and “web” parts. Maybe I’ll start calling them progressive web sites. Or progressive web thangs.
Lamb shoulder’s looking good.
Prepping lamb shoulder for the oven.
Heartfelt congratulations to Remy on ten years of blogging.
More importantly, every single URL on my blog that’s ever been published still works, and even better than that (for me) is my archive showing off the decade of writing I’ve been producing over all this time 💪