Tags: gin

503

sparkline

Monday, October 19th, 2020

Continuous partial browser support

Vendor prefixes didn’t work. The theory was sound. It was a way of marking CSS and JavaScript features as being experimental. Developers could use the prefixed properties as long as they understood that those features weren’t to be relied upon.

That’s not what happened though. Developers used vendor-prefixed properties as though they were stable. Tutorials were published that basically said “Go ahead and use these vendor-prefixed properties and ship it!” There were even tools that would add the prefixes for you so you didn’t have to type them out for yourself.

Browsers weren’t completely blameless either. Long after features were standardised, they would only be supported in their prefixed form. Apple was and is the worst for this. To this day, if you want to use the clip-path property in your CSS, you’ll need to duplicate your declaration with -webkit-clip-path if you want to support Safari. It’s been like that for seven years and counting.

Like capitalism, vendor prefixes were one of those ideas that sounded great in theory but ended up being unworkable in practice.

Still, developers need some way to get their hands on experiment features. But we don’t want browsers to ship experimental features without some kind of safety mechanism.

The current thinking involves something called origin trials. Here’s the explainer from Microsoft Edge and here’s Google Chrome’s explainer:

  • Developers are able to register for an experimental feature to be enabled on their origin for a fixed period of time measured in months. In exchange, they provide us their email address and agree to give feedback once the experiment ends.
  • Usage of these experiments is constrained to remain below Chrome’s deprecation threshold (< 0.5% of all Chrome page loads) by a system which automatically disables the experiment on all origins if this threshold is exceeded.

I think it works pretty well. If you’re really interested in kicking the tyres on an experimental feature, you can opt in to the origin trial. But it’s very clear that you wouldn’t want to ship it to production.

That said…

You could ship something that’s behind an origin trial, but you’d have to make sure you’re putting safeguards in place. At the very least, you’d need to do feature detection. You certainly couldn’t use an experimental feature for anything mission critical …but you could use it as an enhancement.

And that is a pretty great way to think about all web features, experimental or otherwise. Don’t assume the feature will be supported. Use feature detection (or @supports in the case of CSS). Try to use the feature as an enhancement rather than a dependency.

If you treat all browser features as though they’re behind an origin trial, then suddenly the landscape of browser support becomes more navigable. Instead of looking at the support table for something on caniuse.com and thinking, “I wish more browsers supported this feature so that I could use it!”, you can instead think “I’m going to use this feature today, but treat it as an experimental feature.”

You can also do it for well-established features like querySelector, addEventListener, and geolocation. Instead of assuming that browser support is universal, it doesn’t hurt to take a more defensive approach. Assume nothing. Acknowledge and embrace unpredictability.

The debacle with vendor prefixes shows what happens if we treat experimental features as though they’re stable. So let’s flip that around. Let’s treat stable features as though they’re experimental. If you cultivate that mindset, your websites will be more robust and resilient.

Thursday, October 8th, 2020

Parties and browsers

Tess calls for more precise language—like “site” and “origin”—when talking about browsers and resources:

When talking about web features with security or privacy impact, folks often talk about “first parties” and “third parties”. Everyone sort of knows what we mean when we use these terms, but it turns out that we often mean different things, and what we each think these terms mean usually doesn’t map cleanly onto the technical mechanisms browsers actually use to distinguish different actors for security or privacy purposes.

Personally, rather than say “third-party JavaScript”, I prefer the more squirm-inducing and brutually honest phrase “other people’s JavaScript”.

Wednesday, September 30th, 2020

Aegir.org | Canvassing

Strong same:

I’m glad I have this site to play with things, almost all web development and ‘front-end’ stuff leaves me cold these days. It’s all so process driven, so full of unnecessary complexities and dependencies, it’s as if the entire industry wants you to forget you can write HTML by hand and upload it somewhere and it’s a working website. It’s complexity for complexity’s sake, like what accountancy software companies did to the tax code: “Oh this is too complex you need to pay us lots of money to sort it out.” Annoying. I can see some resistance to it and there are still people making blogs and playing around with stuff, so hopefully the professional professionals will calm the fuck down at some point.

Tuesday, September 22nd, 2020

Indexing My Blog’s Links - Jim Nielsen’s Weblog

You might not think this is a big deal, and maybe it’s not, but I love the idea behind the indie web: a people-focused alternative to the corporate web. Seeing everything you’ve ever linked to in one place really drives home how much of the web’s content, made by individuals, is under corporate control and identity.

Monday, September 14th, 2020

The tangled webs we weave - daverupert.com

So my little mashup, which was supposed to be just 3 technologies ended up exposing me to ~20 different technologies and had me digging into nth-level dependency source code after midnight.

The technologies within technologies that Dave lists here is like emptying a bag of scrabble pieces.

The “modern” web stack really is quite something—we’ve done an amazing job of taking relatively straightforward tasks and making them complicated, over-engineered, and guaranteed to be out of date in no time at all.

The plumbing and glue code are not my favorite parts of the job. And often, you don’t truly know the limitations of any given dependency until you’re five thousand lines of code into a project. Massive sunk costs and the promise of rapid application development can come screeching to a halt when you run out of short cuts.

Tolerance | Trys Mudford

Trys ponders home repair projects and Postel’s Law.

As we build our pages, components, and business logic, establish where tolerance should be granted. Consider how flexible each entity should be, and on what axis. Determine which items need to be fixed and less tolerant. There will be areas where the data or presentation being accurate is more important than being flexible - document these decisions.

15 years of blogging (and 3 reasons I keep going) - Austin Kleon

Why keep blogging? For me, there are at least 3 good reasons:

  1. To leave a trace.
  2. To figure out what I have to say.
  3. Because I like it.

Monday, September 7th, 2020

What is the Value of Browser Diversity? - daverupert.com

I’ve thought about these questions for over a year and narrowed my feelings of browser diversity down to two major value propositions:

  1. Browser diversity keeps the Web deliberately slow
  2. Browser diversity fosters consensus and cooperation over corporate rule

Tuesday, September 1st, 2020

100words — 🐙 woohooctopus

Well, this is impressive (and brave)—competing a 100 words for 100 days during lockdown …with a baby.

And remember, this isn’t writing and publishing at least 100 words every day; it’s writing and publishing exactly 100 words (that’s the hard part).

Thursday, August 27th, 2020

Autonomy Online: A Case For The IndieWeb — Smashing Magazine

A wonderful introduction to the indie web—Ana really conveys her sense of excitement!

Thursday, August 20th, 2020

Service Workers | Go Make Things

Chris Ferdinandi blogs every day about the power of vanilla JavaScript. For over a week now, his daily posts have been about service workers. The cumulative result is this excellent collection of resources.

Sunday, August 9th, 2020

Chapter 1: Birth | CSS-Tricks

This is wonderful! A whole series on the history of the web from Jay Hoffman, the creator of the similarly-themed newsletter and timeline.

This first chapter is right up my alley, looking at the origins of hypertext, the internet, and the World Wide Web.

Wednesday, August 5th, 2020

In a Land Before Dev Tools | Amber’s Website

A great little history lesson from Amber—ah, Firebug!

Friday, July 31st, 2020

How would I improve RSS? Three ideas (Interconnected)

Matt has thoughts on RSS:

My sense is that RSS is having a mini resurgence. People are getting wary of the social media platforms and their rapacious appetite for data. We’re getting fatigued from notifications; our inboxes are overflowing. And people are saying that maybe, just maybe, RSS can help. So I’m seeing RSS being discussed more in 2020 than I have done for years. There are signs of life in the ecosystem.

ongoing by Tim Bray · Meta Blog

But aren’t blogs dead? · Um, nope. For every discipline-with-depth that I care about (software/Internet, politics, energy economics, physics), if you want to find out what’s happening and you want to find out from first-person practitioners, you end up reading a blog.

Dense information from real experts, delivered fast. Why would you want any other kind?

Why Medium is Not the Home for Your Ideas – The Hulry

Some good blogging advice.

Building a blog for the long run? Avoid Medium.

Monday, July 27th, 2020

the Web at a crossroads - Web Directions

John weighs in on the clashing priorities of browser vendors.

Imagine if the web never got CSS. Never got a way to style content in sophisticated ways. It’s hard to imagine its rise to prominence in the early 2000s. I’d not be alone in arguing a similar lack of access to the sort of features inherent to the mobile experience that WebKit and the folks at Mozilla have expressed concern about would (not might) largely consign the Web to an increasingly marginal role.

Friday, July 24th, 2020

Make me think! – Ralph Ammer

This is about seamful design.

We need to know things better if we want to be better.

It’s also about progressive enhancement.

Highly sophisticated systems work flawlessly, as long as things go as expected.

When a problem occurs which hasn’t been anticipated by the designers, those systems are prone to fail. The more complex the systems are, the higher are the chances that things go wrong. They are less resilient.

Saturday, July 18th, 2020

Works offline

How do we tell our visitors our sites work offline? How do we tell our visitors that they don’t need an app because it’s no more capable than the URL they’re on right now?

Remy expands on his call for ideas on branding websites that work offline with a universal symbol, along the lines of what we had with RSS.

What I’d personally like to see as an outcome: some simple iconography that I can use on my own site and other projects that can offer ambient badging to reassure my visitor that the URL they’re visiting will work offline.

Your blog doesn’t need a JavaScript framework /// Iain Bean

If the browser needs to parse 296kb of JavaScript to show a list of blog posts, that’s not Progressive Enhancement, it’s using the wrong tool for the job.

A good explanation of the hydration problem in tools like Gatsby.

JavaScript is a powerful language that can do some incredible things, but it’s incredibly easy to jump to using it too early in development, when you could be using HTML and CSS instead.