4 ms·
"... web developers are going to go by the behavior of [what] the browsers do." I have pointed this out before. It is an important point that I think perhaps
by feelin_googley 9y ago
"... web developers are going to go by the behavior of [what] the browsers do."
I have pointed this out before.
It is an important point that I think perhaps is overlooked when users ponder how to change the web.
Want to change how the web is presented, fix annoyances, scratch an itch?
Try to achieve through web development? Good luck.
Try to achieve through browser development? Far more interesting. Alternative, open source, non-commercial browser. For example, implements limited set of features.
Web development follows browser development.
For example, a browser that does not automatically follow URLs so that ads and other crud can be loaded into pages.
Giving users access to a browser like this may be a far more effective means of influencing web development away from annoying "user experiences".
If such annoyances rely on a certain modern web browser feature, then use a browser that lacks the feature.
Non-commercial means developers do not care about "market share". They are not trying to "compete" with the major browsers on features. They care about creating a superior alternative to major browsers that shifts the focus from advertisers and media companies to users.
If the annoyances users have while using major browsers are bad enough, then they will try alternatives and the "market share" may shift. Or maybe not. But who cares? Because with an alternative browser "market share" is not the goal.
In another thread, a Chrome developer perhaps a former Firefox developer tells of how they dropped some feature because it was too "power-user" and that is not "what [they] were going for". Maybe you are within the market they "are going for". And maybe you are not. If you are not, then waiting for developers at a large corporation, whose customers are advertisers, to cater to your needs is futile.
- antoinevg 9y agoThe original vision for hypertext absolutely had multiple "browsers/clients" and feature parity between them was not even remotely an issue. The idea was that you tell the server what capabilities you have, it then tells you what it wants to offer you and a negotiation ensues. I have no idea where this concept of a "standardized hypertext client" came from! ;-)