Links of Interest

Your app should work in a read-only mode without JavaScript. 

Per usual, Jeremy distills things down to simple and unobjectionable points. So many of the arguments against progressive enhancement seem to follow the the thinking from when we collectively believed that sites should look the exact same in every browser.

Progressive enhancement isn’t either/or. It’s a helpful spectrum where the more functionality that can be accessible without JavaScript the better, but just because it may not be pragmatic to have everything accessible without JavaScript all the time, there’s plenty of ways to ensure information can still be accessible without massive engineering efforts.

A free 15 min daily stretch routine to help desk workers avoid aches and pains 

Getting older and sitting too much has increasingly felt more and more painful. This felt like a great way to remember to take a stretch break and covers most of the stretches I’ve been trying to work into a morning routine. I set it to my home page for new browser windows to see about getting the routine to stick.

I haven’t shared anything about the inner workings of my recent site update, and I’m not planning on it. However, supporting a “Site Fidelity” option inspired by Jim Nielsen is one of the little things I’m more excited about. 

It’s a sort of hybrid “progressive enhancement” demo meets “a perpetual option for CSS Naked” that provides both a handy feature for some visitors and a constant reminder to always keep things as simple and semantic as possible.

Some interesting and fun exploration here by Robin. The Details element is one I haven’t built for with my site update, but there’s certainly some good opportunities to use this more in the future. 

Play is a key component of the arts and aesthetics in myriad ways. Art and play are like two sides of the same coin, with play being a part of artistic expression, imagination, creativity, and curiosity. Though it often gets buried in adulthood, the urge to play exists in all of us. It has been a major part of how we’ve evolved as a species. 

Daniela Baron writes up some great advice and a thorough list for thinking about documentation on a project.   It’s one of those where you find yourself aggressively nodding along, but there’s one that really stuck out because it feels so often overlooked. So often, people focus on well-written code not needing extensive documentation, and that can be partial true in terms of understanding what the code is doing.

Good names and understandable code can’t, however, explain the why of how a certain section of code is written. We talk about making sure code can be intention-revealing, but it’s never going to be able to communicate the state and context of the project at that specific point in time and how that informed the approach.