Gemini also has some issues with inline language changes if I remember correctly, which has some accessibility implications.<p>----<p><i>TLDR I think that Gemini has a lot more in common with platforms like PICO-8 than with other HTML replacements. It's a niche community, and that makes me a lot more charitable towards "nothing should change and we don't care enough to address X technical concern" takes than I used to be.</i><p>----<p>The thing that makes Gemini popular is also the thing that makes it easy to criticize: the spec doesn't evolve and it's not really seeing a ton of development, on purpose.<p>In other contexts, small concerns are something that would just get addressed later, but with Gemini they will never get addressed, so you kind of have to decide upfront whether or not you care about those concerns, because they're never going away. On one hand, this makes Gemini great for some things (getting into client development, not needing to worry about the platform changing underneath you) and really bad for other things (being a general-purpose format for more than just hobby/niche communities).<p>But to be fair (and despite how it gets characterized), I don't actually believe that Gemini is <i>trying</i> to be anything other than a stable platform for niche communication, and I don't mean that as an insult. It's pretty obviously not trying to be the future of the web for normal people or a universal way that people write text online, or even a universal "light" format for communication, and while I do have criticisms of the protocol, I also don't think that it has any real obligation to be the future of the web.<p>When weighed against some of the other proposals people have made to "simplify" the modern web (Amp, PDFs, Canvas, etc...), Gemini is noticeably better and noticeably more accessible, and actually has a real community of people using it. So it wins on all of those fronts. It's just if you want it to be anything more than that, you're going to be disappointed, because Gemini is deliberately designed not to be reactive to any needs that its authors didn't already think about, which is pretty much game-over for wide adoption or longevity as a useful spec in the mainstream.<p>When people don't understand that, it leads to fighting over "is this feature actually important for a text-only web, do people <i>really</i> need this?" But in my mind that's the wrong way to think about Gemini's downsides. There are many features that are important for a text-only web that Gemini doesn't support because Gemini is not a foundation to replace HTML, and it's less about whether Gemini supports every feature that would be good or even necessary for it to support if it was used in the mainstream, and more about whether it supports <i>just enough</i> features to be usable for a generally nice, semi-closed community. Most proposals beyond that turn out to be just bikeshedding.<p>It's a little weird, but if you think of Gemini as more of a Tumblr/Twitter alternative and less as an Amp competitor, then a lot of the refusal to evolve or address new concerns start to make a lot more sense. If you're building a general-purpose text-based document format, then you have to care about things that Gemini doesn't care about, and you can't take an attitude of "people's needs matter less than keeping the spec small." But despite what the official website says, I don't think that's what Gemini actually is, and understanding that has made me feel a lot more charitable about the protocol than I used to be.<p>----<p>I will completely hypocritically say though that I do still think they should fix the `lang` problem since that's just a general accessibility feature and is arguably the same or even less complexity than specifying languages in the header. But, hey, that's just me proposing another spec change. :)