4 ms·

However, after reading it several times, I don't like it. The heuristic "consist of numbers but isn't strictly speaking a number" isn't useful. If HTML5 descri

However, after reading it several times, I don't like it. The heuristic "consist of numbers but isn't strictly speaking a number" isn't useful. 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. I guess that means text is wrong, too? It seems like the current definition of text is "the type of input you'd put in a text input even if it's only numerals" and the definition of "number" is "incrementable or decrementable." Seems like it should be "general" and "quantitative" or something. Weird slightly counterintuitive instances such as "date fields are the quantity of days, months, or years since X" make more sense than "social security, credit card numbers, phone numbers, id numbers, etc. aren't numbers" to my eye.

miohtama 5y ago
<input type=“strictly-speaking-not-a-number”>
- chefandy 5y ago
  <input type=“numerals-that-feel-more-qualitative-tbh”>
madeofpalk 5y ago
A phone number is not a number though. It's not an integer. Phone numbers can contain leading zeroes.
- chefandy 5y ago
  I'm not saying they are. I proposed using different labels for fields containing data types we treat as numbers and another for fields containing other strings, even if they only contain numerals and aren't really 'text.' People writing HTML shouldn't need to know about data types— they're describing the semantics of data and not instructions for handling it. That the label number does not apply to the vast majority of input fields with number in their name— cc number, phone number, account number, etc.— is a naming failure. It's an implementation detail that opposes common usage and it should be changed.
tshaddox 5y ago
> 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.
uncomputation 5y ago
Maybe a better, clearer heuristic is if leading zeroes change the meaning. For a credit card number, 0002 != 2 therefore a credit card “number” is really a string. For a linear regression calculator, 0002 = 2, meaning you can use the number field here.
- chefandy 5y ago
  I think the real problem is that the heuristic needs to exist. The label "number" makes sense to developers because we have a mental model for the type of data that goes in those fields. However, it excludes many things most non-developers would call numbers, and they are far more common uses for HTML inputs. I don't think it makes sense for that to be a facet of HTML5 when a more appropriate label would do the job.

miohtama 5y ago

chefandy 5y ago
<input type=“numerals-that-feel-more-qualitative-tbh”>

madeofpalk 5y ago

A phone number is not a number though. It's not an integer. Phone numbers can contain leading zeroes.

chefandy 5y ago
I'm not saying they are. I proposed using different labels for fields containing data types we treat as numbers and another for fields containing other strings, even if they only contain numerals and aren't really 'text.' People writing HTML shouldn't need to know about data types— they're describing the semantics of data and not instructions for handling it. That the label number does not apply to the vast majority of input fields with number in their name— cc number, phone number, account number, etc.— is a naming failure. It's an implementation detail that opposes common usage and it should be changed.

tshaddox 5y ago

> 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.

uncomputation 5y ago

Maybe a better, clearer heuristic is if leading zeroes change the meaning. For a credit card number, 0002 != 2 therefore a credit card “number” is really a string. For a linear regression calculator, 0002 = 2, meaning you can use the number field here.

chefandy 5y ago
I think the real problem is that the heuristic needs to exist. The label "number" makes sense to developers because we have a mental model for the type of data that goes in those fields. However, it excludes many things most non-developers would call numbers, and they are far more common uses for HTML inputs. I don't think it makes sense for that to be a facet of HTML5 when a more appropriate label would do the job.