Link tags: red

197

sparkline

Practice the future | A Working Library

I want to posit that, in a time of great uncertainty—in an era of climate change and declining freedom, of attrition and layoffs and burnout, of a still-unfolding rearrangement of our relationship to work—we would do well to build more space for practicing the future. Not merely anticipating it or fearing it or feeding our anxiety over the possibilities—but for building the skill and strength and habits to nurture the future we need. We can’t control what comes next, of course. But we can nudge, we can push, we can guide and shape, we can have an impact. We can move closer to the future we want to live in, no matter how far away it seems to be.

WWC22 - Design Principles For The Web - YouTube

Here’s the video of the talk I gave in front of an enormous audience at the We Are Developers conference …using a backup slidedeck.

WWC22 - Design Principles For The Web

Changing with the times · Chris Burnell

I think, with the sheer volume of functionality available to us nowadays on the front-end, it can be easy to forget how powerful and strong the functionality is that we get right off shelf with HTML. Yes, you read that right, functionality.

“Evergreen” Does Not Mean Immediately Available | CSS-Tricks - CSS-Tricks

Smart advice on future-proofing and backward-compatibility:

There isn’t a single, specific device, browser, and person we cater to when creating a web experience. Websites and web apps need to adapt to a near-infinite combination of these circumstances to be effective. This adaptability is a large part of what makes the web such a successful medium.

Consider doing the hard work to make it easy and never remove feature queries and @supports statements. This creates a robust approach that can gracefully adapt to the past, as well as the future.

The Web in 2036: Predictions on a Whim - Jim Nielsen’s Blog

Prompted by the rhetorical question at the end of my post Today, the distant future, Jim casts his gaze into a crystal ball. I like what he sees.

It’s possible the behemoth that is JavaScript in 2022 continues to metastasize as we move towards 2036, especially with technologies like WASM. I wouldn’t rule out the lordship of JavaScript as a possibility of the future.

However, I also think it’s possible—and dare I predict—to say we are peaking in our divergence and are now facing a convergence back towards building with the grain of the web and its native primitives.

Why do I say that? In our quest for progress, we explored so far beyond the standards-based platform that we came to appreciate the modesty of the approach “use the platform”.

He also makes one prediction that lies within his control:

This blog post will still be accessible via its originally published URL in 2036.

Unveiling the new WebPageTest UI - WebPageTest Blog

If you haven’t seen it yet, the new redesign of WebPageTest is lovely!

canistilluse.com - Jim Nielsen’s Blog

…you would be forgiven if you saw an API where a feature went from green (supported) to red (unsupported) and you thought: is the browser being deprecated?

That’s the idea behind my new shiny domain: canistilluse.com. I made the site as satire after reading Jeremy Keith’s insightful piece where he notes:

the onus is not on web developers to keep track of older features in danger of being deprecated. That’s on the browser makers. I sincerely hope we’re not expected to consult a site called canistilluse.com.

It’s weirdly gratifying to see a hastily-written sarcastic quip tuned into something real.

WICG/shared-element-transitions

I’m very excited about this proposal for animating transitions between web pages!

I’m less excited about doing it for single page apps, but I get why it’s the simplest place to start.

This builds on Jake’s earlier proposal which I always thought was excellent and much needed. I’m not the only one. Chris agrees.

Stay alert - DEV Community 👩‍💻👨‍💻

It’s not just a story about unloved APIs, it’s a story about power, standards design, and who owns the platform — and it makes me afraid for the future of the web.

A thoughtful, considered post by Rich Harris on the whole ballyhoo with alert and its ilk:

For all its flaws, the web is generally agreed to be a stable platform, where investments made today will stand the test of time. A world in which websites are treated as inherently transient objects, where APIs we commonly rely on today could be cast aside as unwanted baggage by tomorrow’s spec wranglers, is a world in which the web has already lost.

Choice Words about the Upcoming Deprecation of JavaScript Dialogs | CSS-Tricks

Believe it or not, I generally am a fan of Google and think they do a good job of pushing the web forward. I also think it’s appropriate to waggle fingers when I see problems and request they do better. “Better” here means way more developer and user outreach to spell out the situation, way more conversation about the potential implications and transition ideas, and way more openness to bending the course ahead.

Google vs. the web | Go Make Things

With any changes to the platform, but especially breaking ones, communication and feedback on how this will impact people who actually build things with the web is super important, and that was not done here.

Chris has written a thoughtful reflection on last week’s brouhaha around confirm, prompt, and alert being deprecated in Chrome. The way that the “developer relations” folks at Google handled feedback was less than ideal.

I reached out to one of the Google Chrome developer advocates I know to see if I could learn more. It did not go well.

Bruce Lawson’s personal site  : prefers-reduced-motion and browser defaults

I think Bruce is onto something here:

It seems to me that browsers could do more to protect their users. Browsers are, after all, user agents that protect the visitor from pop-ups, malicious sites, autoplaying videos and other denizens of the underworld. They should also protect users against nausea and migraines, regardless of whether the developer thought to (or had the tools available to).

So, I propose that browsers should never respect scroll-behavior: smooth; if a user prefers reduced motion, regardless of whether a developer has set the media query.

Don’t Feed the Thought Leaders - Earthly Blog

A great tool is not a universal tool it’s a tool well suited to a specific problem.

The more universal a solution someone claims to have to whatever software engineering problem exists, and the more confident they are that it is a fully generalized solution, the more you should question them.

Earth Restored — Toby Ord

Beautifully restored high-resolution photographs of the Earth taken by Apollo astronauts.

prefers-reduced-motion: Taking a no-motion-first approach to animations

Given the widespread browser support for prefers-reduced-motion now, this approach makes a lot of sense.

Should The Web Expose Hardware Capabilities? — Smashing Magazine

This is a very thoughtful and measured response to Alex’s post Platform Adjacency Theory.

Unlike Alex, the author doesn’t fire off cheap shots.

Also, I’m really intrigued by the idea of certificate authorities for hardware APIs.

Creating websites with prefers-reduced-data | Polypane Browser for Developers

There’s no browser support yet but that doesn’t mean we can’t start adding prefers-reduced-data to our media queries today. I like the idea of switching between web fonts and system fonts.

Goodbye.Domains

A graveyard for good domains you let expire.

Copying is the way design works || Matthew Ström: designer & developer

A people’s history of copying, from art to software.

Designers copy. We steal like great artists. But when we see a copy of our work, we’re livid.