Note that having a unique fingerprint becomes actually great if it's so unique that even after a page refresh you get a different one.

Most browsers with fingerprint protections will for example introduce random noise in graphics and audio APIs.

Just like you wouldn't use PNG for photography, I don't think you'd use a lossless video codec for real-world footage.

Lossless video would make much more sense for digital content like screen recordings, where the assumption that few pixels change between consecutive frames makes much more sense.

Lossless formats (specifically DPX & EXR sequences, usually with ZIP compression) are used frequently for real world footage in post-production workflows! Granted, most consumers don't run into this stuff. Photographers don't use PNG because it doesn't offer anything for them that camera raw or EXR files don't already cover.

As far as video types go maybe it would work well for animation since that tends to compress well for the same reason a screen recording does.

Sure you do. E.g. ffv1 and huffyuv are used for archiving video losslessly.

HEVC/H.265 and VP9 can both also operate in lossless mode. In my testing they achieve compression ratios that ffv1 and huffyuv cannot come close to touching (not all that surprising given how old ffv1 and huffyuv are).

Ffv1 is much easier to work with compared to HEVC and VP9 though, probably thanks to it's deep integration with ffmpeg. By comparison, working with HEVC was hell on earth!

I spent like a week figuring out how to stuff JPEG sequences into HEVC files without losing colorspace and color profile information. Even JPEGs alone were horrible to work with, my understanding is they encode image data in the YUV444P colorspace, but every program works with them in the RGB colorspace. The conversion between YUV444P <-> RGB is lossy and every program does the conversion slightly differently. So if I ever accidentally triggered this conversion at any point, my archival was no longer bit-perfect.

And then to check your results, you obviously can't convert back to JPEGs, I think I ended up encoding to TIFF after having failed with JXL.

Code here if anybody else wants to try replicating it (good luck, you'll need it): https://gist.github.com/null-dev/ebd2f8b23c3e5066a48976c7308...

Converting lossy JPEGs to lossless HEVC might seem wasteful, but the space saved by intra-frame compression dwarfs the space saved by lossy encoding.

Losssy compression is standard on high end cinema cameras.

In most cases the compression ratio will be low enough that the video will be perceptually lossless.

You might be interested in tangled.sh, a Git forge that recently added support for stacked PRs with jj[1] (or anything that supports the Change-Id header i suppose)!

[1]: https://bsky.app/profile/tangled.sh/post/3lptwcb47kc2u

Nice - I have no choice but to use GitHub at work, but I'm always glad to see competitors.

thanks for the mention! I was just composing a reply haha.

What I do is I git clone --recursive and then init a colocated repository. JJ will find the submodules and ignore anything in them, it works decently well.

iirc WASM bytecode closely resembles V8 IR. If you're writing a JS engine, might as well provide a more direct frontend to it... I don't think it adds much.

For those who have Rust, I like miniserve[1]:

    cargo install --locked miniserve
    miniserve path/to/directory

[1]: https://github.com/svenstaro/miniserve

Thanks for posting miniserve <3

> Gur fvmr bs gur pbyyrpgvba jbhyq punatr!

Ubj vf guvf n ceboyrz gubhtu? Vg qbrfa'g frrz gb ivbyngr nal bs gur shapgbe ynjf!

> It doesn't trigger built-in mobile operating system components.

I worry about this. The built-in mobile operating system components are reliable, accessible, and responsive. I really like it when an input element opens the Android UI because I know how it works and that it is reliable. This applies to <select>, but also date/time inputs for example.

This is only if you opt in to base-select, so if you don't use that, everything should continue to work the same, as far as I can tell.

"You" in this case is the website author. From a user perspective, that doesn't solve the problem.

> Chrome already uses plenty of non-native components. Firefox is similar.

This is then won't be consistent with native OS apps, but still be consistent across websites. Better than everybody doing different div+JavaScript magic which behaves slightly different across different websites.

you're misunderstanding, this will leave the appearance of the select on mobile up to the web developer

How about Scaleway?

I like them a lot but they only have EU DCs, if you are looking for Global (or at least Asia) you're out of luck for now. Perhaps this disconnect from US services might give them the impulse to spread out though! I'm really happy with them as a customer and I don't have needs beyond Europe anyway.

I've found Scaleway for AWS-style managed backend services fronted by Bunny (https://bunny.net/ - also EU-based & owned, but with global CDN DCs) works well! Bunny have nearly 30 DCs in Asia alone.