A look at why ARIA should be treated like any other web technology:
All web technology has compatibility issues... [and] ARIA is a web technology.
ARIA should be the last tool you pull out of your toolbox, not your first.
An interesting read that covers some of the basic terminologies of typesetting, as well as the technicalities of how browsers actually interpret the line-height value. Hint: it's not what you'd probably expect. Line height is more accurately a "line box", another layer of the HTML box-model, which is why you can set padding and margin to zero on text and you'll still have a gap between lines.
That's interesting stuff, but Caleb also shares a Sass mixin based on a formula used in the Basekick package which can actually get the browser to remove the intrinsic line-box whitespace. As he explains, that means you can create web layouts which are actually aligned to the pixel, not an arbitrary box object that you can't really control. It's a hack and I'm not sure I'd ever want to use it personally (not least of all because it would make Sass a core dependency), but the idea that native support might be coming to CSS in the shape of line-height-trim or leading-trim is very exciting. I foresee a future where a CSS value like one of those becomes a part of universal resets, much like box-sizing is today.
Important Caveat: YMMV on this trick. Matt himself notes that there are potential issues and there's a discussion with Šime in the comments which highlights actual problems in Chrome on Android. With that said, the whole "Safari ignores 100vh" issue is a pain and this is a simple workaround that may have some applications:
/* mobile viewport bug fix */
Obviously, body can be whatever element you want. The hope is that the -webkit prefix here is good enough for all other browsers to ignore it. Whether or not that's true is, as I mentioned, debatable.
It's also really interesting to see them take a swing at npm as a not-particularly-great ecosystem structure:
Furthermore the mechanism for linking to external libraries is fundamentally centralized through the NPM repository, which is not inline with the ideals of the web.
I'll be intrigued to see if Deno and Entropic end up with a tight relationship as a result.
Most of what the blog post goes into flies straight over my head, but the notes on improved HTTP server performance and their commitment to stability both caught my eye. This is clearly a product which has been thought through, not just on paper but with the benefit of (heaps of) actual experience thanks to NodeJS' popularity. Sounds very intriguing.
Also, I'd just like to take a moment to note both the excellent URL choice (deno.land) and the adorable mascot art:
short manifesto about the future of online interaction
It's a call to look at the processes and concepts which have made the shift from in-person to online as a result of the pandemic, taking square aim at meetings and lectures in particular. He raises some valid points:
Most meetings boil down to an opportunity for someone to show off or demonstrate their status;
Good meetings may include an element of discussion or a venue for raising questions, but it's an imperfect system still;
Lectures/education are just sequences of long meetings where discussion is almost dissuaded and attendance/engagement is maintained via withholding grades, diplomas etc.
His hope is that we can use a change in circumstance to evaluate and address these issues by redefining meetings, both for education and for work. If a meeting is about transferring information, replace it with a memo or a recorded tutorial. Meetings are only truly useful when they're for transforming information (his words, which I like). And the best method of transforming information is through conversation.
Seth has had success with using Zoom's breakout session features to manage that process, effectively using the main call to present an idea or problem, then sending students into breakout rooms to discuss.
The fediverse is an interesting concept that's long had competitors for a number of mainstream social sites, the most infamous of which is probably Mastodon. I hadn't realised that there was an Instagram-clone running on the ecosystem, but it looks pretty neat. Better still, the latest release refactors the core concept away from "image sharing" to "collections", meaning that you can create photo albums as well as make posts, in an attempt to provide a free alternative to the likes of Google Photos.
Considering you can create closed-networks (the whole point of having federated users), PixelFed presents an excellent option for friend- or family-specific image collections, without having to hand that information over to big corporations. Cool.
I have to admit: I didn't know what an accessibility statement was until I read Ethan's post 🙋♂️ That's not great. Now I do, so hopefully, in the near future, I'll get around to adding one here. That will need a little bit more thoughtfulness than I can currently give, though, so for now I just want to record the key points:
First and foremost, an accessibility statement’s meant to help the reader. Put another way, it’s a document that helps them better understand the accessibility features of the website they’re using.
Ethan specifically mentions elements like the focus styles he's designed and how he's tested his colour palette.
For someone visiting my site—whether it’s the first time or the fiftieth—my accessibility statement hopefully provides them with the information they need to better navigate my site.
He also makes a point of having a "not great" section of known accessibility issues or areas which are planned for improvement. That makes the statement a living document, which feels right. Inclusion requirements will shift with technological change; accessibility is never "finished". I'm a fan of using GitHub issues, a laEric Bailey, as a way to allow users to flag these as well.
The Known Issues section is an attempt tried to acknowledge that my site has plenty of flaws—not unlike myself—and that I’m working to fix them.
Ethan's post also contains numerous links to other worthy examples (like Eric's) that are all well worth visiting and considering. I'll definitely be coming back to this in the – hopefully near – future.
While things were changing, I kept working. After a few weeks tinkering with this redesign, I realized I wasn’t working on a website, not really: it was a worry stone.
There's a lot to love in Ethan's thoughts. I saw his tweet weeks ago but found myself returning to it time and time again in my mind, what with, well, everything right now. It's great to see that expanded into a full piece (I actually don't know which came first). Plus, obviously, Icanrelate. So excuse me; I think there's something about "reviews" that needs working on 😉 After all:
That’s not to say any of these things are done, mind you. But they’re done until I come back to them: until I find something else to revisit, to sand down, to turn over and over and over.
YouTube embeds can be expensive on page load metrics, but what alternative is there? How about loading a thumbnail that hot-swaps itself for an <iframe> when clicked? Sounds great, but wouldn't that mean you have to create custom thumbnails for each video? Nope, YouTube has a bunch of weird and wonderful hidden features in its API that will give you everything you need:
IndieWebify.Me is the main service I've been using to get my site set up with IndieWeb technologies. It's a great, step-by-step tutorial on how to get involved and helps you easily test your implementation. I've still got a bit I need to do but it would have taken a lot longer without this resource.