Some autofill tokens incorrectly/inaptly named, while others are inadequate #9910
Closed as not planned
Description
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:
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 namedsuffix, which is more concise anyway.bdayand 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 asbday-day, which just looks redundant. Therefore, the token should be namedbdate, and accordingly for its subtokens.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 thepi-*orpm-*prefixes can be used.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 togender, 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).given-nameandadditional-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 currentlygiven-nameandadditional-nameto 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 repurposinggiven-nameto be the supertoken for all given names (since the nomenclature makes sense), and an additional token can be created under it calledinitial-nameor something to that effect that will represent what is currently represented bygiven-name, andadditional-namecan be moved under it as well.