Skip to content
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

Indicate via @autocomplete whether a password field is for new/current values #275

Merged
merged 1 commit into from
Jun 30, 2020

Conversation

mnoorenberghe
Copy link
Contributor

This helps password managers (once #161 is fixed) along with accessibility tools.

@netlify
Copy link

netlify bot commented Jun 28, 2020

Deploy Success!

Built with commit e6d7482

https://deploy-preview-275--identity.netlify.app

@erezrokah erezrokah added the type: feature code contributing to the implementation of a feature and/or user facing functionality label Jun 29, 2020
@erezrokah erezrokah self-requested a review June 29, 2020 16:14
Copy link
Contributor

@erezrokah erezrokah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @mnoorenberghe,
Can you share some context/links on how password managers/accessibility tools use the string value of autocomplete?
A before/after example would be great (e.g. behaviour before and after the autocomplete change).

Seems like the available values for the field are on|off:
https://www.w3schools.com/tags/att_input_autocomplete.asp

Also, this seems relevant for other fields as well.
Instead of changing the type of password from a boolean to a string should we add new field called autocomplete?

@mnoorenberghe
Copy link
Contributor Author

mnoorenberghe commented Jun 29, 2020

Can you share some context/links on how password managers/accessibility tools use the string value of autocomplete? A before/after example would be great (e.g. behaviour before and after the autocomplete change).

new-password can prevent autofilling of existing saved passwords and potentially provide password generation.
current-password will signal that password generation shouldn't be offered.

https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose explains the benefits for accessibility.

Seems like the available values for the field are on|off:
https://www.w3schools.com/tags/att_input_autocomplete.asp

W3Schools isn't a trusted source and shouldn't be used. See https://www.w3fools.com/. Other values of autocomplete have been in the HTML spec for at least 4 years.

See https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete instead.

Also, this seems relevant for other fields as well.
Instead of changing the type of password from a boolean to a string should we add new field called autocomplete?

The value needs to be set independently for each <input> so I don't think a single new field makes sense. I think changing from a boolean to take the type of password field makes sense since it forces the developer to think about which kind of password field this is.

@erezrokah
Copy link
Contributor

erezrokah commented Jun 29, 2020

W3Schools isn't a trusted source and shouldn't be used. See https://www.w3fools.com/. Other values of autocomplete have been in the HTML spec for at least 4 years.

Very cool thanks.

The value needs to be set independently for each <input> so I don't think a single new field makes sense. I think changing from a boolean to take the type of password field makes sense since it forces the developer to think about which kind of password field this is.

Cool, makes sense. Thanks for clarifying.

I'll do some testing then merge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature code contributing to the implementation of a feature and/or user facing functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants