On Fri, May 29, 2020 at 09:56:44AM -0400, Jason McBrayer wrote: > On the web, they make sense as a way of inlining short content, like > icons, and avoiding a server round-trip. But obviously, they don't make > sense for Gemini, and there's no reason clients should support them. There's no reason they *should*, but they can. And some of them will. And then people will think of this as normal and expect it and design their documents around it, and the snowball will roll... I tried *so* hard to avoid this, but you just can't. This data:// URL thing is a monster. No RFC puts a limit on the allowed length of a URL. And the data:// scheme includes MIME types. So they are a vehicle for arbitrary content of arbitrary size. Turns out this entire time Gemini - and even it's hypothetical deliberately stripped-back cousin Mercury - has allowed embedding of inline images, audio and videos. It's just impossible to avoid this stuff unless you throw out URLs entirely and start with something else, in which case the effort to learn the spec and implement it skyrockets because you can't leverage existing knowledge and code. I was naive to think the internet was made out of little do-one-thing-and-do-it-well components you could compose in novel ways to build things of deliberately limited scope. Turns out it's made of a few massively overpowered blobs and it's impossible to build anything small. Yes, alright, to some extent abuse of this loophole will be limited by the fact that all this content has to be downloaded in a single file in a single transaction before any of it can be displayed, so the user experience will be miserable if there is more than just a little bit of embedded content. We won't quite end up as bad as the web. But still! This is just unspeakably frustrating. Cheers, Solderpunk
---
Previous in thread (16 of 41): 🗣️ Jason McBrayer (jmcbray (a) carcosa.net)
Next in thread (18 of 41): 🗣️ James Tomasino (tomasino (a) lavabit.com)