Thousands separator creates invalid value for HTML5 Number input

Please provide very detailed instructions to reproduce the problem. If I can reproduce an issue with the thousands separator, I will fix it.

I looked into this. The issue has nothing to do with Save as Draft. The issues is that webform is presenting a formatted number to the HTML5 input type "number". It does not accept thousand separators. I'm not sure what other formatting it doesn't accept.

I'm not sure if we should abandon the html 5 type "number" or strip the formatting.

The input type "number" can only accept a valid floating point number.

The only non-numeric characters that can be parsed are:

• A hyphen "-" indicating a negative value
• A single decimal "."
• The "e" or "E" character for exponents.

I'm willing to take a stab at a patch to strip the formatting if you don't mind providing some guidance if I get off-track. :)

renamed to better reflect the issue

I'm not sure if we should abandon the html 5 type "number" or strip the formatting.

Very similar problems caused by HTML5 number elements in #2202905: Decimal numbers with comma as placeholder fail validation in Chrome. Bottom line is that number elements really can't be used for anything except integers (with no thousands placeholders). This might make it good for things like "number of items" or "port number" but not for things with any kind of formatting: credit cards, phone numbers, currency, etc. After encountering all the issues with an HTM5 number element, I think our only real solution is to go back to textfields.

This might make it good for things like "number of items" or "port number" but not for things with any kind of formatting: credit cards, phone numbers, currency, etc.

I would argue that credit cards and phone numbers should not be number fields. These are identifying strings that contain digits, plus other formatting characters, such as (617) 555-1212 or 1234-123456-12345.

Currency is handled with the prefix and suffix options.

That leaves thousands and decimals. We can just remove the thousands, leaving it as formatting.

That leave the Chrome decimal == comma problem. If that alone is sufficient, then maybe we should ditch the HTML5 number element.

Or we could event use regular fields when the decimal separator is not a period.

Yeah, true about credit card, phone numbers, etc. They can't really be numbers anyway. Currency and float numbers are where the problems persist.

Or we could event use regular fields when the decimal separator is not a period.

The odd thing is that in Chrome, it sets the decimal placeholder based on the browser language/locale, not from the Website. So even if we said the placeholder was a period, Chrome would require it be a comma anyway. However, then it would convert it for us before submitting. So we would always get an expected value, but the experience for end users would vary based on their browser and language. I suppose that's not a big problem as long as users aren't regularly switching between browsers, but behaving differently based on language/browser combination could cause some confusion in the future.

I'm not sure if we should abandon the html 5 type "number" or strip the formatting.

The more I think about this (and read the issue queue), the more abandoning the number type makes sense. It is unlikely that a typical end-user will read "number" as a component type and know it shouldn't be used for credit cards and phone numbers. And if we're being honest, most people don't read documentation even if it were explained in the component settings. :-/

OTOH, a number element makes it easier on a phone because it can default the right keyboard.

Maybe give a per-component option?
(x) Use HTML5 number form element
Recommended only for small numbers, without a thousands separator or decimal point.

And, of course, don't send thousands separators to the browser.

I like this suggestion. I'm disappointed every time I fill out a mobile form and have to toggle to the number screen. If the instructions are short as proposed here, and the data is sanitized, that may be the best approach. I'd love to help whichever way you guys decide is best. Just looking to contribute to the project where I can. :)

Maybe give a per-component option?

I don't know... I don't think most users are aware of the limitations of an HTML5 number field. On an iPhone for example, there's no way to enter a negative number(!) when using HTML5 number fields. If we enabled HTML5 specifically for integer-only, positive-only numbers, then it'd hardly ever be used at all, unless we made both of those options enabled by default.

Let's take #15 as a decision. This is a -4.0 release blocker.

While coding standard do not normally allow commenting out code, I have elected to simply comment out the setting of the elements type to 'number', in the hopes that HTML5 browser support will improve to address the decimal issue. I also left the step, min, and max in the HTML so that a theme or module could implement in-page validation.

Commited to 7.x-4.x and (reluctantly) 8.x. By the time 8.x is out, this issue may have improved.