“When can I start using CSS grid layout?” “Too bad that it’ll take some more years before we can use grid in production.” “Do I need Modernizr in order to make websites with CSS grid layout?” “If I wanted to use grid today, I’d have to build two to three versions of my website.” The CSS grid layout module is one of the most exciting developments since responsive design. We should try to get the best out of it as soon as possible, if it makes sense for us and our projects.

This 2017 article from Manuel Matuzović goes deep on how to creatively use CSS Grid Layout in a progressively-enhanced manner. Naturally, the baseline techniques we use will change over time, but Manuel’s demo illustrates how you might think about design and layout as experience layers.

The GitHub Engineering team recently completed a gradual transition away from jQuery and wrote in-depth about the experience. There’s a lot of good detail in the post, but I’m particularly fond of this bit:

As part of our refined approach to building frontend features on GitHub.com, we focused on getting away with regular HTML foundation as much as we could, and only adding JavaScript behaviors as progressive enhancement. As a result, even those web forms and other UI elements that were enhanced using JS would usually also work with JavaScript disabled in the browser. In some cases, we were able to delete certain legacy behaviors altogether instead of having to rewrite them in vanilla JS.

Stick around through the end of the article for more on how the team is using Custom Elements to enhance the user interface.

Most developers think of <script type="module"> as way to load ES modules (and of course this is true), but <script type="module"> also has a more immediate and practical use-case—loading regular JavaScript files with ES2015+ features and knowing the browser can handle it!

To put that another way, every browser that supports <script type="module"> also supports most of the ES2015+ features you know and love.

This very helpful article outlines how you can take advantage of modern JavaScript features while still serving usable code to older browsers.

In a lengthy response to a hyperbolic, ill-informed opinion piece, Aaron Gustafson describes progressive enhancement:

It’s a philosophy that recognizes the nature of the Web as a medium and asks us to think about how to build products that are robust and capable of reaching as many potential customers as possible. It isn’t concerned with any particular technology, it simply asks that we look at each tool we use with a critical eye and consider both its benefits and drawbacks. And it’s certainly not anti-JavaScript.

I spent a good deal of time in 2015 writing and speaking on the benefits of this approach to designing and building for the Web:

• Designing Experience Layers
• In Defense of Progressive Enhancement
• The Practical Case for Progressive Enhancement
• Designing with Progressive Enhancement

The observant reader would note that Aaron and I address the same tenuous arguments made—coincidentally—by the same people.

This is a new and excellent resource from UK-based front-end developer Jaime Caballero designed as a space for information about progressive enhancement. Check out the articles page for a couple of entries from yours truly!

I find myself with IoT talking about progressive enhancement all the time, even though it’s a Web thing, but it makes even more sense. Really, it should be the thing it was designed to be first and then the smarts layered on top.

Stephanie Rieger on a recent episode of The Web Ahead podcast, speaking with Jen Simmons about designing network-connected physical devices—ahem the Internet of Things—with the philosophy of progressive enhancement baked in. Sure, you could build a Web-connected light switch, but if it isn’t first a well-designed light switch, you’ve missed the mark.

Marking up and styling an effective donate form.