As a user I really don't like sites disabling autofill. In this case, you make me type my address, because you want to use one address field.
A better solution would be to detect safari, and present multiple fields, which will be autofilled. You can then concatenate these fields in the backend to whatever you like.
As a user I hate it even more when my browser pops in an unwanted auto-complete dropdown obscuring a contextually-better and integrated auto-complete provided by the website, where it's obvious the website tried to suppress the native auto-complete but that broke at some point thanks to browser vendors thinking they know better than the wider developer community, and now there's two competing dropdowns both trying to do different things. I wish vendors would respect the HTML standard and stop thinking they can machine learn the website to guess what the user wants.
Case in point: CRM system with address fields for records. Chrome, I don't want to put my freaking address when I'm updating a customer address, nor do I want to save every customer address I add to my browser's address book.
Came here to say this. Bane of my life - typing in an address, then I go to click the site-provided dropdown and, simultaneously, the browser inserts its own dropdown over the top with the wrong address on it. So I end up having to delete the incorrect address and start over.
> In Chrome and Firefox, you can thwart attempts to auto fill by setting the input type equal to “search” and autocomplete to “off”.
No, you can't. Chrome has disregarded this since at least 2014 [1]. They collected use cases for this in 2016 [2] but did nothing about it [3]
Oh, wait. The author actually writes this further down on the page (emphasis mine): "Up until version 7, Safari used to respect the value of the autocomplete attribute, so setting it to “off” would work. Most modern browsers now choose to ignore the value of autocomplete, so this solution no longer works."
Would you please stop posting unsubstantive comments, and comments that break the site guidelines, to Hacker News? You've done it a lot and we've asked you repeatedly to stop. When accounts keep doing this we eventually ban them.
The kind of bias you're complaining about is in the eye of the beholder. People who feel the opposite way about Apple or any $BigCo see exactly the opposite and make identical complaints, just going the other way. It's sample bias.
Oh piss off Daniel. If HN let us delete our own accounts I would have done it a year ago.
I've asked you repeatedly to do something about the downvote abuse but you continue to act like nothing's wrong. I have no respect left for this community or the people who run it, nor do I see value in participation anymore.
HN likes to masquerade as some sort of upscale establishment, high and above the petty squabbles of Eslewhere, but in the end this place too devolves into a predictable echo chamber just like the rest of them, when it comes to any topic on which people have varied opinions.
This did not happen overnight; for more than a year I have been watching perfectly fine comments getting buried almost instantly. Why give a fuck about what you write if you're going to be downvoted anyway?
You are well aware that downvotes can be and are abused to prevent facts from being seen. Like what even was in the GP's comment to make it so gray? (at the time I posted mine)
HN is broken, and one of the major indicators of a broken service is a tone-deaf management who continues to insist that everything is Working As Intended.
Isn't this what `autocomplete="street-address"` is for? Admittedly, it's intended for text areas, but I'd argue that they're more useable in this situation.
> A street address. This can be multiple lines of text, and should fully identify the location of the address within its second administrative level (typically a city or town), but should not include the city name, ZIP or postal code, or country name.
Chrome is also rather aggressive in this regard and I find myself constantly battling this issue when trying to add places autocomplete to an input. A workaround that seems to work reliable though, is to place the autocomplete-input outside of the form element. That is clearly not always a feasible solution, depending on your page / form layout, but for OPs layout it should be straightforward. After the user makes a selection you usually continue by dumping the json result into another hidden input anyway.
I've found this to be a pain, so good to know this crazy hack. To be pedantic however, TLDR is supposed to come at the top of the page - we could all have just read that short part and gone on about our day....
Nit: we don't use HTML like it's 2005 anymore. So instead of
<input type="..." />
with bogus XHTML-like slash at the end, just use
<input type="...">
Sorry, but it's a pet peeve of mine to point out cargo-cult idioms like that. The slash at the end was there to make your HTML parse as XML/XHTML. But unless you have very specific requirements (like serving your page as XHTML, or fruitlessly attempt to produce or parse your HTML using an XML toolchain) we don't do that anymore, even in 2019. The slash and the pretentious-looking space before it is ignored/error-recovered away by browsers and other HTML parsers anyway.
Who are you to tell people they can't live in an idealistic world where the documents we send each other have a standard behind them that isn't special-cased for the laziness of years of web developers?
I'm the one working hard to debunk the misconception that HTML is "sloppy" or XML in any way adds standardization to HTML that wasn't there already with SGML.
Self closing tags are perfectly valid in HTML 5 and there's nothing wrong with using them. Even if the parser ignores them, they're still useful for the reader. HTML 5 does not require you to close your paragraph tags either but most people still do it because tag soups are hard to understand.
Jokes aside, that space before the / exists as a habit because Internet Explorer couldn't handle tags like <br/>, so in order to have valid XML that worked in IE as well you would do <br />.
Completely pointless nowadays of course, although I do like the / for single elements. It's kind of nice to be able to write HTML5 and XML both with roughly the same syntax.
