One idea I have is <link rel="data"> (or <a rel="data">), if your web page is a data-oriented web app. You can include it in your own web pages if it is appropr

One idea I have is <link rel="data"> (or <a rel="data">), if your web page is a data-oriented web app. You can include it in your own web pages if it is appropriate to do so. (This way, you can have a default view but allow the user to choose their own instead if they wish to do so. Comment 31228726 mentions they have to have empathy to ordinary users; <link rel="data"> will allow it to work both ways, I think.) (It could use any format, whether JSON, CSV, SQLite, etc; you can indicate this as the type attribute. And, you can have more than one, as different types.) For API documentation (or data format documentation), you can have <link rel="documentation"> (or <a rel="documentation">) too; if you limit it to a simpler subset of HTML or to plain text, then it can be easily read (or printed out, if wanted) in simpler viewer programs too. I have other ideas too, such as <html application="...">; you can use this to identify instances of a web app that may be on multiple servers; this can be used for user CSS and for other purposes (e.g. substituting native code if the client has it in order to improve efficiency of computation, or using software that the end user has installed (or has written and/or customized) specifically for this use). And then there is the "feature" attribute, to indicate that it implements a feature that the end user might already have in which case it can be ignored (I had written a list of some of these, e.g. feature="usercss" and feature="uploadname"). Another idea I have is a Interpreter header, but that will require that web browsers implement it (unlike the other three things above, which are backward compatible). This can allow to serve any file format and it can be displayed in the modern kind of web browsers while simpler ones could also display them in their own way; it can also reduce the number of requests required for some things, improve caching in some ways, allow polyfilling video/audio codecs in a cleaner way, etc. (It could also allow a user to install command-line programs to convert a file if you are using WebAssembly with only a small subset of the Interpreter API.) There does need better web browsers written, too. Half of the things will need to be changed (often, implemented differently than the specification says; e.g. do not allow enumerating devices but if it is requested, the browser might say request audio input enter a system command to produce the audio (which might be one that converts a audio file to stdout, or that converts audio from a microphone to stdout, etc)); better way is a way that is meant for only advanced users, assuming that you know what you are doing and better interoperability that user can specify UNIX pipes, etc, without trying to stop you from doing things; another thing that would be helpful is the ARIA view mode. Some things were also mentioned by FSF, such as that the end user should be allowed to substitute their own JavaScript codes in a web page; I think that it is also a good and necessary idea. The web developer console is already a good end-user-oriented feature, but by itself it is not good enough. Having other web browsers of course does not mean that all users will have to use it; we will need to have the choices and controls!!! (The ability for the end user to write native extensions in C (and run them as native code) would also be helpful; WebExtensions are too limited, and might not be as efficient as a C program.) It would seem needing to write a new browser in C, but it might be possible to modify existing ones (Netsurf seems the best idea at this time but it might not be good enough), but that would require changing half of the program, and might need to maintain and pay attention to changes to decide if you will include those changes, and to get them to work. Furthermore, other people can make providing the API endpoints for many things even if they do not have, and to be not too complicated, that then you can use your own. When there will be a lot of them, then you may be able to access using SQLite virtual table extensions (even accessing two sources at once in a joined query, if wanted), Gemini, Telnet, Gopher, JSON, CSV, NNTP, IRC, etc. Even could be made the program that supports such feature too.