> Not only are you in a tiny minority of users who wish to do things like this, but most web applications out there go out of their way to stop you from doing those things and creators would almost certainly rather have a UI platform that did not allow you to do those things.
I am also one who wants to do things like this. Web browsers must be designed for advanced users who are assumed to know what they are doing better than the web page author.
It is worse. Even if I am a author I cannot easily use a format to allow end users better customization if they provide their own software to do so; they want to insist you to do it by yourself, regardless of what the end user wants.
However, it is possible to use mainly the existing HTML standard, to make something that would allow more user control.
Some possibilities include:
- ARIA mode. Use HTML and ARIA to display the document, using user-specified styles and behaviours, instead of using the CSS included in the document (with some exceptions, e.g. if it specifies a fix pitch font, then it can use a fix pitch font).
- Interpreter header. If it were implemented even in common web browsers (without requiring TLS), then it can allow to serve any file format and if the client software does not understand it, it can polyfill the implementation.
- Use of new HTML attributes, e.g. feature="usercss", feature="uploadname", rel="data", , etc. Existing implementations would ignore them, so it does not break compatibility.
- Use of existing HTML features, e.g. (to make available alternative file formats), etc. Clients that do not implement them can ignore them.
- Design web browsers for advanced users. Many Web APIs will be implemented differently (or not at all), e.g: when asking for a file to upload, also allow the user to override the remote file name, and may allow a system command line pipe (like popen) specified; when requesting microphone or camera access, the user specifies the source (again using popen, which may be used even if the user does not have a microphone/camera); etc.
- Other features in an improved web browser, e.g. key/mouse quoting mode, manual/auto recalculate mode (manual mode also prevents spying from unsubmitted forms and stops autocomplete from working), save/recall form data on local files (as a user command), HTTP basic/digest auth management (also as a user command), script overriding (also mentioned in a article written by FSF), etc.
- Request/response header overriding option for user setting. This makes many other options unnecessary, because you can use this option instead, e.g. language setting (Accept-Language), tracking (DNT), JavaScripts and other features (Content-Security-Policy), cookies (Cookie, Set-Cookie), HTTPS-Everywhere (Strict-Transport-Security), etc.
- Meta-CSS, only available to the end user, which can make CSS selectors that select CSS selectors and properties and modify their behaviour.
- Improved error messages. Display all details of the error; do not hide things.
- Some properties may work differently, e.g. if you try to access the height of the view, to return Infinity instead of the correct number (or define a getter on that property which throws an exception instead of returning a number).
- The structure of the design of the web browser in the backward way from usual: I think that a better way will be, that the components (HTML, individual commands within HTML, CSS, HTTP, TLS, JavaScript, etc) are separate .so files (extensions) that are then tied together using a C code, that a user may modify and recompile, or rewrite (and changing the components too if wanted) to make the web browser in the way that you want to do.
- External services which provide information and APIs for accessing APIs of other services including using command-line programs, that users may access to use them.