The Best Of The Internets

Ever wonder if websites can track your every move?

Privacy matters.

A nice overview (in Dutch) of why you should combine progressive enhancement with RWD.

This is an excellent summary of print style recommendations from Manuel Matuzovic. I’m glad I wrote the tweet that prompted it :-)

See also:

As usual, Jason Grigsby nails it:

• Progressive Web Apps still work on iOS
• Progressive Web Apps perform better on iOS
• Billions of people use browsers that support Progressive Web Apps
• Apple appears to be warming to Progressive Web App technology
• Progressive Web Apps benefit all users

Done and done.

This is an excellent missive from Nicholas covering the progressive enhancement debate.

First … progressive enhancement isn’t about having a JavaScript vs. JavaScript-disabled experience, it’s about providing the best possible user experience throughout the entire lifecycle of the web application. …

Second, progressive enhancement isn’t a strict prescription, it’s a way of thinking about the software you’re building. … Instead, it encourages you to think more deeply about the problem you’re trying to solve, and guides you towards solutions that work for the maximum number of users.

These two points are why I believe progressive enhancement is as relevant today as it has ever been. The only difference now is that we have more options for improving the user experience than ever before.

I couldn’t have said it better myself.

Accessibility is hard. It’s a broad term encompassing a variety of special needs ranging from low vision and color blindness to motor impairment and language barriers (to name but a few) which means guaranteeing our projects are “100% accessible” is a significant challenge.

Accessibility becomes even more of a challenge when you begin to factor in the dependency chain. Blind and low-vision users, for example, often use screen readers in order to access the Web. With screen readers, we need to consider the capabilities of both the browser and the screen reader being used. If either piece of software isn’t up to the task or contains a bug our users suffer for it.

Getting multiple inter-dependent programs on the same page sometimes requires that we do things we’d rather not do. This post from Steve Faulkner chronicles one such case where the particular versions of Chrome and JAWS required for a project didn’t see eye-to-eye on the semantics of heading levels. He talks about the issue and the less-than-optimal fix he had to put in place to ensure users got the experience they were meant to.

Very clever bit of flexbox here for laying out text optimally when you don’t know its length.

I don’t know that I would consider it a hack so much as pushing flexbox beyond what most people would even consider doing.

I love how Mandy deftly wove progressive enhancement into her content strategy and publishing discussion:

Perhaps ironically, we’ve found that the best way to create that resiliency is by harking back to the web principle of progressive enhancement: each story created in Chorus begins as a platform-neutral collection of text, images, and video. That foundation ensures that we can publish that story as easily to our own platform as to, say, AMP or Apple News, and be confident that our audience will experience that story in a way that fits whichever platform they are using. On our own platform, we’re then free to enhance up, adding stylistic or experiential flairs that elevate the experience of the story. This practice — which I refer to unoriginally as progressively enhanced storytelling — also has the added benefit of helping us make our content more accessible to more kinds of users, especially those with disabilities. (It wouldn’t be inaccurate to consider speaking browsers one among the many platforms we must publish to.)