5 ms·
It's called "user agent", not "developer's agent". We'd be in a terrible situation if the browsers just followed developer's whims. Cf. popup blocking.
by Nitramp 7y ago
It's called "user agent", not "developer's agent". We'd be in a terrible situation if the browsers just followed developer's whims. Cf. popup blocking.
- sky_rw 7y agoDismissing the above use cases as "developer's whims" is the fundamental issue most people here are taking with these decisions. I think we can all agree that browser behavior should not be left solely up to the developer and is not a black and white issue. Nobody here is arguing that. We are arguing for following a guideline that makes sense. This is why we have the w3c, an organization that attempts to weigh the needs of user, developers, and browser maintainers.
- deleted 7y ago[deleted]
- TeMPOraL 7y agoThe issue is that the browser is supposed to be the meeting place for negotiating between developer and user preferences. Its job is to take into account preferences of both sides, and render the site accordingly. Not to be a third party at the negotiating table. Breaking agreed standard in a way that can't be overridden by the user? Browsers should never do that.
- muro 7y agoIn this case, it can be overridden by the user, just not the developer :)
- xg15 7y agoNot really if the user is non-technical and doesn't even know they'd have to override it.
- basch 7y ago"this website has asked us to NOT autofill your saved info. if you would like to autofill the form anyway click" i made it a little terse, but there has to be a way to make it succinct and human readable.
- xg15 7y agoI think this could still be confusing as enough users will likely have no idea who "us" is in that message - if they understand the difference between browser and website at all. It could also be confusing if the website already provided its own autocompletion via JS: The user would get a message that autocomplete is turned off while they see that it seems to be right there. But I think in general, some kind of prompt or override would work. I absolutely agree that if a user wants to use the browser autocomplete functionality, they should have an option to do so. I have no understanding for websites that just want to disable autocomplete without replacement. However the concerns seemed to be about autocomplete being incorrect or conflicting with application-provided lists. I can see how that leads to frustration and confusion with users. The Chrome team seems to trust its algorithm to an amount where they don't seem to find it necessary to deal with incorrect results - a view which doesn't match reality apparently.
- CathedralBorrow 7y agoWho is addressing the user here?
- bayindirh 7y ago> Breaking agreed standard in a way that can't be overridden by the user? This was done by Microsoft by the old days, now it's Google. How ironic.
- rictic 7y agoCorrect behavior is debated and decided in public, resulting in a specification. In this case the HTML spec says "should", not "must". HTML Spec: > When an element's autofill field name is "off", the user agent should not remember the control's data, and should not offer past values to the user. RFC2119: > SHOULD: This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. As I read it, this behavior may or may not be a good idea, but it is not a violation of the standard. Disclosure: I used to work on the Chrome team at Google, but I have no particular knowledge of autocomplete.
- Vinnl 7y agoGP is explicitly not dismissing the above use cases, but merely the supposed justification of "the developer wants it" being enough. > I think we can all agree that browser behavior should not be left solely up to the developer and is not a black and white issue. Nobody here is arguing that. GGP was literally arguing that: https://news.ycombinator.com/item?id=21239172 https://news.ycombinator.com/item?id=21239172
- watwut 7y agoShould developer be able to make it impossible to close browser or open 100 new tabs? No. Should developer decide that fields are autocomplete off or green or show javascript warnings? Absolutely yes. If user wish to change that, users thing. The browser/google has no business to be mediator here, second guess application they know nothing about and manipulate it. The browser should be predictable, well specified and harmless. It should not force me to convert all ids into random strings just so that random data do not get prefilled in.
- michaelt 7y agoI've heard plenty of people on HN say password managers should ignore autocomplete=off and I agree with them. Because that setting is mostly applied by organisations like banks who incorrectly think they're making things more secure by doing so. IMHO there are cases where autocomplete=off should be respected, and other times when it shouldn't be - it's certainly not as simple as saying always do or always don't respect it.
- kalleboo 7y agoPassword managers should ignore autocomplete=off in login screens, but not in administration screens where you’re editing other people’s credentials. IMO the distinction could be made to not automatically fill when the autocomplete=off but instead add a button to let the user initiate it
- rhizome 7y ago
- Nitramp 7y ago> Nobody here is arguing that. Well, OP that I responded to literally argued that. I agree the platform needs to expose useful features in a predictable manner for application developers. But I'd much rather have browsers decide what's reasonable control over the user experience.
- watwut 7y agoIf the user installs extension to auto fill everything, it is on him. When the browser decided to ignore spec, it is not user agency at all. The need for auto fill is extremely application specific and the action is quite often destructive. And it is developer who gets to be blamed for lost data.
- sneak 7y agoHow do I install extensions into my most commonly used browser (my phone)?
- andrewshadura 7y agoStart using Firefox on your phone.
- Lammy 7y ago(on Android)
- Hamuko 7y agoBut I'm developing the application for the users. It's pretty annoying that we have to make hacks for a client card page not to automatically assume you want to fill in your own details.
- codedokode 7y agoThen ask the user before filling anything.
- chaboud 7y agoThat's a bit of an appeal to extremes. Visually rendering static HTML per the spec is a situation where a browser "just followed developer's whims", and it's why protocols and standards exist. That a browser could reliably infer from context what the right information to insert into a field could be is one of those things that gives great demo and may even work more often than not, but it's a virtually impossible problem to solve comprehensively. Developers have plenty of valid reasons to disable autocomplete and autofill functionality. Taking that away from them and requiring an obfuscating workaround is tantamount to creating an invisible pseudo-standard. Imagine what would happen if we decided to solve the scourge of signed-unsigned pointer value bugs in C++ by having the compiler virally assume unsigned variable typing for memory related operations based on variable name. It might feel like a quick fix to a widespread problem, but it would break down all over the place and would break the code of developers who A) followed the spec B) knew what they were doing and C), at least some of the time, were doing it for a specific purpose. These sorts of changes remove the incentive to write standards compliant code, leading to a mangled universe of hacks, quirks, and, in the end, bugs.
- dreamcompiler 7y agoAnd e.g. disabling Paste. But it seems clear that autocomplete gets it wrong often enough that developers should have some say in the matter.
- ckrailo 7y agoBrowsers already follow developer whims, see: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Fe... YouTubeTV uses feature policy to disable the browser's picture-in-picture feature.