3 ms·

> If HTML5 describes information semantics, labels should reflect the term's common usage rather than jargon for specific heavily caveated use cases— Credit car

> If HTML5 describes information semantics, labels should reflect the term's common usage rather than jargon for specific heavily caveated use cases— Credit card numbers and phone numbers aren't exactly edge cases. Ideally, yes, we'd have better semantics, but I wouldn't really blame HTML5. In all of computing we don't really have a succinct term for a data type that happens to contain mostly or only numerical digits but isn't actually referring to a numerical quantity (or ordinal, etc.). I see this mistake in software all this time. Someone will add a "social security number" field somewhere as a numerical data type, and some frontend somewhere will format it with delimiters like "123,456,789". Incidentally, that's my goto way to explain the distinction: if you would want to format the number with comma delimiters, it's probably actually a number. Credit cards and phone numbers aren't edge cases, but they're very clearly examples of data that should not be modeled as numbers.

chefandy 5y ago
> "Credit cards and phone numbers [...] should not be modeled as numbers." Agreed that they shouldn't be modeled as a numeric data type. The actual field behaviors are also appropriately implemented for their respective data types in the browsers. I wouldn't so quickly absolve HTML5, though. The type field describes the purpose of the data, not its 'data type'. Most people consider the term "number" very general and treating it as a special type of value with specific uses and properties is an artifact of software development. HTML isn't a templating language that processes data, and in my experience, many creators and consumers of HTML are not software developers. The rest of the values are consistent with that intent, maybe except text and to some extent local date and time: Hidden, Text, Telephone, URL, Email, Password, Date, Month, Week, Time, Local Date and Time, Number, Range, Color, Checkbox, Radio Button. What are the really common uses of "numbers?" Product quantities? Currency? I can't think of much else— certainly nothing people would normally label using the word number. What are very common fields that aren't numbers? Credit card numbers, phone numbers, social security numbers, account numbers, ticket numbers, reference numbers, confirmation numbers... The label makes sense to people who write application logic using variables where whether something is or isn't a number is really important. To everyone else, labelling a phone number 'text' makes much less sense than labelling a telephone number a number.
- noizejoy 5y ago
  > To everyone else, labelling a phone number 'text' makes much less sense than labelling a telephone number a number. In some jurisdictions there’s a strong culture of having phone numbers represented as text - so they’re easier to remember. Especially popular for toll free numbers. I presume that this culture has lead to the popularity of overlaying the alphabet over numeric keypads, for banking machines and payment terminals. As a result, I remember some of my associated pass codes as words, not as numbers. So there are some real world scenarios where a human thinks a word, while the data item is a number.
  - chefandy 5y ago
    Good call. Definitely all the more reason to avoid using the word "number" to approximate the limiting, specific way developers use it when that doesn't line up with general usage.
- tshaddox 5y ago
  I don't think anyone is suggesting that a user interface should refer to a phone number field as "type: text" or whatever. Of course that would be confusing.
  - chefandy 5y ago
    It's common enough: https://www.w3.org/TR/WCAG20-TECHS/C17.html#C17-description https://www.w3.org/TR/WCAG20-TECHS/C17.html#C17-description
    - tshaddox 5y ago
      I’m not sure what you mean. That page isn’t suggesting that you display to the user that the phone number is of type text.
      - chefandy 5y ago
        This entire thread is about the type= property of an HTML input field. Nowhere did I or anybody suggest that this be presented on the webpage. The users in question are users of HTML markup, not users of the webpages written in that HTML.
Existenceblinks 5y ago
One category I can think of is called "code". Credit card, SSN, could be the same category as zip code. Anything number that does not in calculable semantic (e.g. index, id)
- chefandy 5y ago
  Sounds good to me
epolanski 5y ago
> Credit cards and phone numbers aren't edge cases, but they're very clearly examples of data that should not be modeled as numbers. "Clearly" is debatable. Regardless of how you input the data itself, nothing is stopping you from parsing and encoding it to a valid number of a certain type in a certain range. Encoding it as something different than numbers seems even more dangerous and I have not seen yet an argument for it that goes beyond the input.
- JimDabell 5y ago
  Some places have phone numbers that are variable length and can start with a zero. If you store these as numbers, this will drop the leading zero and result in an incorrect phone number. Phone numbers aren’t numbers. Numerical values can be written as sequences of digits, but not all sequences of digits are numerical values.
  - epolanski 5y ago
    Makes sense.

chefandy 5y ago

> "Credit cards and phone numbers [...] should not be modeled as numbers." Agreed that they shouldn't be modeled as a numeric data type. The actual field behaviors are also appropriately implemented for their respective data types in the browsers. I wouldn't so quickly absolve HTML5, though. The type field describes the purpose of the data, not its 'data type'. Most people consider the term "number" very general and treating it as a special type of value with specific uses and properties is an artifact of software development. HTML isn't a templating language that processes data, and in my experience, many creators and consumers of HTML are not software developers. The rest of the values are consistent with that intent, maybe except text and to some extent local date and time: Hidden, Text, Telephone, URL, Email, Password, Date, Month, Week, Time, Local Date and Time, Number, Range, Color, Checkbox, Radio Button. What are the really common uses of "numbers?" Product quantities? Currency? I can't think of much else— certainly nothing people would normally label using the word number. What are very common fields that aren't numbers? Credit card numbers, phone numbers, social security numbers, account numbers, ticket numbers, reference numbers, confirmation numbers... The label makes sense to people who write application logic using variables where whether something is or isn't a number is really important. To everyone else, labelling a phone number 'text' makes much less sense than labelling a telephone number a number.

noizejoy 5y ago
> To everyone else, labelling a phone number 'text' makes much less sense than labelling a telephone number a number. In some jurisdictions there’s a strong culture of having phone numbers represented as text - so they’re easier to remember. Especially popular for toll free numbers. I presume that this culture has lead to the popularity of overlaying the alphabet over numeric keypads, for banking machines and payment terminals. As a result, I remember some of my associated pass codes as words, not as numbers. So there are some real world scenarios where a human thinks a word, while the data item is a number.
- chefandy 5y ago
  Good call. Definitely all the more reason to avoid using the word "number" to approximate the limiting, specific way developers use it when that doesn't line up with general usage.
tshaddox 5y ago
I don't think anyone is suggesting that a user interface should refer to a phone number field as "type: text" or whatever. Of course that would be confusing.
- chefandy 5y ago
  It's common enough: https://www.w3.org/TR/WCAG20-TECHS/C17.html#C17-description https://www.w3.org/TR/WCAG20-TECHS/C17.html#C17-description
  - tshaddox 5y ago
    I’m not sure what you mean. That page isn’t suggesting that you display to the user that the phone number is of type text.
    - chefandy 5y ago
      This entire thread is about the type= property of an HTML input field. Nowhere did I or anybody suggest that this be presented on the webpage. The users in question are users of HTML markup, not users of the webpages written in that HTML.

Existenceblinks 5y ago

One category I can think of is called "code". Credit card, SSN, could be the same category as zip code. Anything number that does not in calculable semantic (e.g. index, id)

chefandy 5y ago
Sounds good to me

epolanski 5y ago

> Credit cards and phone numbers aren't edge cases, but they're very clearly examples of data that should not be modeled as numbers. "Clearly" is debatable. Regardless of how you input the data itself, nothing is stopping you from parsing and encoding it to a valid number of a certain type in a certain range. Encoding it as something different than numbers seems even more dangerous and I have not seen yet an argument for it that goes beyond the input.

JimDabell 5y ago
Some places have phone numbers that are variable length and can start with a zero. If you store these as numbers, this will drop the leading zero and result in an incorrect phone number. Phone numbers aren’t numbers. Numerical values can be written as sequences of digits, but not all sequences of digits are numerical values.
- epolanski 5y ago
  Makes sense.