Disabling Safari AutoFill for a single line address input (2019) | Hacker News Reader

Disabling Safari AutoFill for a single line address input (2019)

bytes.grubhub.com

26 pointstosh23 comments

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."

But yeah. Safari's the bad guy.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=370363

[2] https://bugs.chromium.org/p/chromium/issues/detail?id=587466

[3] https://bugs.chromium.org/p/chromium/issues/detail?id=914451

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....

It's insane, and thanks for the tip.

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.

Getting off topic now, but I like those, and still practise it. It lets the reader know not to expect a seperate closing tag.

I’ll do what the linter says thanks.

That’s backwards

Yea but the “computer said so” excuse will always be there.

IMHO the most important thing is to be consistent with the rest of the organisation's codebase. After a while people get used to reading it that way.

So doing what the linter says is exactly the right answer.

This is probably jsx, and the slash is required.

How can a space be pretentious-looking?!

Takes up space without adding any substance.

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.

Oh it's older than that, even. IE was always fine without the space. It was for Netscape.

So, sure, maybe there's a good reason to want XML-compatible syntax. But Netscape 4 users? Let's hope not!

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.

[1]: http://sgmljs.net/docs/sgml-html-tutorial.html

[2]: http://sgmljs.net/blog/blog1701.html

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.

This has to be one of the most absurdly elitist (or patronising?) comments about HTML I've had the pleasure of reading.

Who is this 'we' you speak of?

Reply on news.ycombinator.com