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

Some autofill tokens incorrectly/inaptly named, while others are inadequate #9910

Closed
getsnoopy opened this issue Nov 3, 2023 · 2 comments
Closed

Comments

@getsnoopy
Copy link

What is the issue with the HTML Standard?

There are some autofill tokens (ones that are used in the autocomplete attribute) defined in the standard that are either incorrect or inapt with their naming:

  1. honorific-suffix – The problem here is that this isn't used just for honorifics, but for regular, necessary cases as well. For example, if someone is the third same-named person in a lineage, their name might be "John Doe III". The "III" is not an "honorific" (which implies that it's an embellishment), but a requirement that disambiguates the name from all of the other ones in that lineage. Therefore, the token should simply be named suffix, which is more concise anyway.
  2. bday and its subtokens – The terminology is that a date consists of a day, month, and year. Naming it "day" is not only incorrect, but strange when it comes to subtokens such as bday-day, which just looks redundant. Therefore, the token should be named bdate, and accordingly for its subtokens.
  3. cc-* tokens & subtokens – The term "cc" clearly refers to a credit card, but the problem is this is too specific when the standard talks about a "payment instrument" in general. The standard should not be "cornering" use cases with such terminology, as even among "cards", there are many types: credit, charge, debit, gift, etc.; the "cc" prefix only works for the first two. Moreover, "cards" aren't the only kind of payment instrument there is, and the standard should similarly not be cornering its use cases with such terminology. As such, it would be much better to use generic terminology of "payment instrument" or "payment method", for which the pi-* or pm-* prefixes can be used.
  4. sex – The token itself seems to be fine, but then the description and allowed values seem to be about gender, which encompasses far more options. I.e., sex ≠ gender, and they should not be conflated in the standard. Universally, it is understood that there are only 2 sexes (barring exceptions such as intersex cases): male and female. If one wants to allow for actual gender to be represented in the field (which is far more varying), then either this token should be renamed to gender, or another token should be created of that name to represent gender, and this one should be kept to only represent sex (preferably the latter to allow for both uses).
  5. given-name and additional-name – The problem here is twofold: (1) an "additional" name is also one that is given to a person at birth, so distinguishing it as such is awkward. And (2), there doesn't seem to be a supertoken that encompasses what is currently given-name and additional-name to represent all given names, which is useful in international cases such as passports and ID cards, where all the given names are (rightly so) referred to as the "given name", and the "inherited" names are referred to as "surname" or "family name". As such, I propose repurposing given-name to be the supertoken for all given names (since the nomenclature makes sense), and an additional token can be created under it called initial-name or something to that effect that will represent what is currently represented by given-name, and additional-name can be moved under it as well.
@annevk
Copy link
Member

annevk commented Nov 3, 2023

Unfortunately we cannot change these tokens. You might be able to find past issues discussing some of this as well, if you're interested in the rationale.

@annevk annevk closed this as not planned Won't fix, can't repro, duplicate, stale Nov 3, 2023
@getsnoopy
Copy link
Author

getsnoopy commented Nov 3, 2023

I see. Then how about creating a new one that encompasses given-name and additional-name? And similarly for gender? And maybe creating new ones for the other ones and deprecating the current ones?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants