|
> The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume only that kind of content in only that kind of way. It's impossible to know in advance whether what's on the other side of a https:// URL will be within the subset or outside it. Not that I can't see the appeal for the gemini devs to start from scratch and roll their own protocol rather than start with a browser and subtract the unwanted parts, but that justification is, technically, practically, and also generally very weak. Technically, because you can very well limit HTML to a subset of markup elements (for example, to exclude <script> elements or, likewise, onclick and similar attributes accepting script). The whole point of SGML, on which HTML is based, is to define markup languages, and also derive restricted languages from general ones. The problem here is rather that HTML on its own isn't expressive enough for interactive things we've come to expect (such as idk menus, table-of-content summaries, and other navs or in-page search dialogs and other interactive features that are not quite webapps) yet is also too powerful with js being inserted everywhere to non-heuristically comprehend content for reader mode apps and screen readers in the general case. Practically, because syntax checkers (SGML or otherwise) and NoScript exist and have for a long time. It would also be cool if search engines could finally come around and penalize or at least flag content relying heavily on script and/or invasive tracking for ads. One way to make this happen is to introduce application/html as opposed to text/html media types. Generally, because HTML and other markup vocabularies have been developed using public money for, well, publishing hypertext in academia, and it's odd to marginalize that original use case just because of the desires of ad companies. |