There’s a new term in town: soft navigations. Basically it means “single page app” (SPA) style navigations where page stuff changes, and the URL changes, but the browser didn’t do a traditional full-reload thing. I like the term in the sense that it sounds like a light insult. Whattaya too weak, child, to do a proper page load? Whattaya *soft? *Anyway the point of it is so that the browser itself has a way to detect these things, and testing Core Web Vitals is the entire reason. That feels like kind of a light reason to introduce a whole new API, but Google invented Core Web Vitals and their in-house initiatives like that get the juice.

And the out-of-house initiatives sometimes get the boot. So when there is a cool new image format in town, like JPEG XL, that isn’t from Google, things get weird. Declan Chidlow wrote about this in JPEG XL and Google’s War Against It. Google invented WebP in-house, so people feel it’s protected over better technology.

This would also partly explain why they adopted AVIF but not JPEG XL. AVIF wasn’t superior in every way and, as such, didn’t threaten to dethrone WebP.

JPEG XL, however, is better than WebP in every quantifiable way and would obsolete it.

But Google can do what they want with Chrome. It’s theirs, after all, a fact just recently confirmed. That’s for the better, if you ask me, but it does serve to tighten the iron grip they have over the web generally.

This is putting me in an HTML-y mood so allow me to share a few more HTML-y things.

I found Alex MacArthur’s article TIL: A Link’s Download Attribute Won’t “Just Work” for Cross-Origin Resources from a few years ago very useful recently. See, you’ll see advice where if you want a link-click on a website to immediately download a file, you just put the download attribute on it, like:

<a href="/files/thing.pdf" download>Download PDF</a>Code language: HTML, XML (xml)

But what nobody tells you is that if the URL is cross-origin, that just straight up doesn’t work.

<a href="https://api.site.com/files/thing.pdf" download>Download PDF</a>Code language: HTML, XML (xml)

So thankfully we have people like Alex to dig around and to the research and blog the answer, which is that you need the server to serve that file with a Content-Disposition header. Phew.

Ya know how there’s a little thing people call best practices? Some people seek them out. Some people poke fun at them like they know better. I’m more the former, myself. Be like Chesterton, before you tear down a fence, know why it was built in the first place. The best practices are the fence, see.

A classic best practice is that you don’t duplicate IDs on HTML attributes. You’re told to not do it, but less often, why not to do it. I best most of you could think of at least one reason. Right away I think about how getElementById will only find the first one, which may or may not be what any given code is aiming for. I think about hash links and they’ll only scroll to the first find, which again might be a mis-aim. Other elements that point toward an element with the ID (think for or aria-labelledby) might miss their aim too.

Welp, that’s three. Enough for you? Maybe you think… well those don’t apply to this current website I’m working on. And the fact that a #id selector matches multiple elements just fine in CSS is little a little shrine for you to hang your hat and say you just don’t care about this little “best practice”.

Here’s Lee Amador with a couple of more examples. Maybe there are more. But that’s why this is a best practice. Just lock in your brain that you don’t duplicate IDs and you avoid every possible problem with no downside.