You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 named suffix, which is more concise anyway.
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.
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.
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).
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.
The text was updated successfully, but these errors were encountered:
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.
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?
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.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 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-name
andadditional-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-name
andadditional-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 repurposinggiven-name
to be the supertoken for all given names (since the nomenclature makes sense), and an additional token can be created under it calledinitial-name
or something to that effect that will represent what is currently represented bygiven-name
, andadditional-name
can be moved under it as well.The text was updated successfully, but these errors were encountered: