Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A website is owned by someone. If they decide that in their shop they want to have a carpet floor it is up to users not to visit that shop (if they don't like that), but not up to adidas to turn the floor into tarmac, because that works better for their shoes...


If the website says to display ads, my browser will properly ignore that. If the website says to prevent the user from switching away from the tab, my browser will properly ignore hat. If the website tries to take over my system and install malware, my browser will properly ignore that. And if the browser tries to break the ability to remember passwords, my browser will properly ignore that too.

Websites consist of code to be interpreted by browsers as they see fit, for the benefit of their users. Those users do not necessarily want exactly the experience the site authors want them to have.


The difference between autocomplete=off and the rest of your examples is that there are actually positive UX use cases for disabling autocomplete on certain inputs (e.g. when you are an admin editing existing users)


Ad blockers have false positives as well. And there's a use case for blocking the user from closing the tab (onbeforeunload), such as prompting them to save/submit what they're working on. But for all of those, the browser is still in control and the question is what provides the most benefit for the user.

So, along the same lines, it may make sense to improve the UI for autocompleting users, or for hinting about the use of the field, to make it easier for sysadmins. But that shouldn't break the more common case of handling sites that just think they're Too Special or Too Important to allow saving login information.


Ad blockers are extensions to browsers.

And I would actually argue that blocking before closing the tab should be a decision up to the developer, not the browser.


My computer is owned by me. If I download your HTML, I get to do whatever I want with it, using any software I please. I am under no obligation to render it or process it in the particular way you would most prefer. You can suggest that I might want to render your website with carpet on the floor, but if I object to carpet and choose to render all websites with tile floors instead, that's my choice - because it's my computer, and I get to decide what I'm going to do with it. If you don't like that, don't let me download your HTML.


The browser vendor CAN'T install tarmac in shops floor.

The shop controls the server the user rightly controls the experience on their machine. The browser vendor provides an application that runs on the users machine. If the shop doesn't like it they can pound sand or suggest the user would be better off with a different browser.

They can perhaps rightly say that the deviation from standard is unfriendly or sub optimal but one would hope they wouldn't appeal to imaginary authority derived from a bad analogy.

A raven isn't like a writing desk and a client server interaction isn't like a user visiting a physical store.

Analogies can serve to communicate but when you use them to prove a point the only thing you prove is your lack of understanding of the matter.


The browser is owned by the user. If the user wants it to autocomplete a field, then it should autocomplete the field.


Users don't even know. And if you offer a professional site, with support, you will field calls where chrome autocomplete confused the user and doesn't behave like the spec. The answer is buried in a chrome bug report. Stupid


autocomplete is completely behavior inside the user's browser. You do not own the user's browser. Would you also like to block zooming or other accessibility features because you don't like the way it looks?




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: