Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.form_validate_number uses PHP's is_numeric(), which checks if a value is numeric based on its own float notation: digits with a period as a decimal separator. We exclude about half the world's countries, where commas are the standard.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | drupal_1964192_00.patch | 420 bytes | xano |
Comments
Comment #1
Niklas Fiekas commentedThe idea was, that this is according to the HTML5 specification: http://www.w3.org/TR/html-markup/datatypes.html#common.data.float.
Browsers might very well allow input with a comma and then internally convert it. So this should only be a problem for browsers that don't do this. I just verified that Chrome does do it.
So the question is: Do we want to be and should we be more graceful with older browsers?
Comment #2
xanoThanks for the explanation. In your opinion, would it make sense to document this in the code, or should it be ovbious that the validate function is for HTML5 numbers only?
Comment #3
Niklas Fiekas commentedSome points:
Looking at it, the docs explicitly say that it is meant to be used by #type 'number' elements. That is also reflected by the naming form_validate_[...] which is consistently used in such cases.
Comment #4
xanoTrue, but this is a great example of something that can be used in other contexts as well. We just described the function in terms of what we originally wanted to use it form rather than in terms of what is actually does, which is what we're supposed to do.
Here's a patch that fixes this.
Comment #5
dave reidI disagree with this change. The documentation should state that this validation is for #number type elements. If you want to re-use this validation, we can add a note not in the documentation summary about the format expected, but let's not change the summary. This is consistent with our other form_validate_[elementname] callbacks and we shouldn't deviate for this one case.
Comment #6
xanoI believe code should be documented in terms of what it does, rather than in terms if what the author intended it to be used for, which means that the current documentation is wrong. However, I don't care enough to keep trying to convince people of this improvement.
Comment #7
dave reidI think the non-summary line can be improved with the expected format. But the summary line is exactly what this does. This is a validation callback for 'number' form input elements.
To be clear, I think we can improve the docs for what *format* of number is expected (linking to the HTML5 specs), but just not on the first line.
Comment #8
xanoComment #16
norman.lolThis seems to be more of a browser issue than Drupal-related. Nonetheless here comes a quickfix for when you want to allow people to enter numbers with a comma as decimal separator on Firefox.
With a little bit of JS you can convert the value using dots instead of commas. People on Chrome or Safari won't even recognise it, the comma stays in the browser, Chrome and Safari automatically convert it under the hood already. But Firefox doesn't. The following snippet fixes this.
(Cross-posted generalized snippet with a little bit more background info on https://stackoverflow.com/a/60935441/2199525.)
Comment #23
quietone commentedThe first comment and last comment state this is about browsers, not Drupal. In the middle there is discussion of adding a comment but there was no agreement. Looking at the code myself I don't see the need to add a comment or further explanation. Based on that and the lack of interest in this issue in 11 years, I am going to close this.
If that is wrong, reopen the issue, by setting the status to 'Active', and add a comment.
Thanks!