The Best of the Internets

Les Défis Du “progressive Enhancement”

This is a nice overview (in French) of how Hopwork handles progressive enhancement in their SaaS product. Their back-end is Java too. It’s nice to see folks talking about how to progressively enhance products in that language; we don’t hear about that often enough.

I Totally Forgot About Print Style Sheets

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

See also:

iOS Doesn’t Support Progressive Web Apps, So What?

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.

Technical Credit

This is an excellent post about progressive enhancement from the “technical credit” (as opposed to “technical debt”) point of view.

Is Progressive Enhancement Over?

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.

A (Not So) Short Note on ARIA to the Rescue

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.

Flex-grow 9999 Hack

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.