-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Key and value tagging autocomplete woes #2376
Comments
I've seen this before, but I think it may be because of Safari's overagressive autofill/autocomplete. Some discussions here: I did try to fix this a few months ago, but nothing was working. |
Good point made, and having said so, I wanted to try this possibility out. So I tried Firefox, with all information cleared out and autofill fills cleared...here's the result I got with my first attempt at 'ref' once iD populated its autocomplete. As you can see, it's completing out, and it can't have got this information from autofill on my browser, because it was empty. Hope this helps! |
I don't think I agree with your suggestion of requiring a positive action to accept autocomplete. You've highlighted a couple cases where autocompletion generates non-ideal behavior, but in many cases it works well, and requiring a positive action would penalize those cases. One change I think would be helpful is to suppress autocompletion on paste. |
For me it always autocomplete do |
Any progress on this issue? I don't want to just rant - and I know that patches are welcome - but since I'm mapping a lot of points with Sometimes even if I press backspace to remove the Thanks a lot. |
Although in an ideal world people would clean up bad data, I'm closing this issue simply by sorting namespaced keys (i.e. keys containing |
Autocompletion in iD has a tendency at times to create tags and values a user probably didn't intend. Here's how to reproduce the issue:
The problem with this is, that it's very easy to, if in a hurry, type 'ref' to manually add a tag, and tab to the next field, and not to realize that the tool has autocompleted to ref:bag. This is a tag that has no meaning outside the Netherlands, and yet, if you consult http://taginfo.openstreetmap.org/keys/ref%3Abag#map , you can see that it accidentally gets populated in this way. There are probably other tags, values, and variations for which this also happens.
(1) If the current behavior for autocomplete is going to be kept, then when autocompleting a potential tag's key or value, the first hit - that is, the one forcefully autocompleted to - should always be 'the shortest logical tag the user may be trying to use in the autocomplete list'. IMHO 're' or obviously 'ref' really ought to produce the autocomplete 'ref' first, not 'ref:bag'.
(2) Having said this, it would be better still if autocomplete required a positive action on the part of the user, like a 'down arrow' to select the first or other entry in the list, to autocomplete it to the first suggested item.
This feature can really be difficult to work with if I'm trying to put in, say 'hov:lanes' values by pasting them from my clipboard (because I know exactly what I want it to be, like 'designated|' or 'designated|yes', and the tool autocompletes to a much longer string that is not intended, meaning the paste is a two step process (paste then delete extra).
Thanks for reading!
The text was updated successfully, but these errors were encountered: