<h1>Ugh, Cross-Browser <code>number</code> Validation</h1>

<form>
  <label>Try some non-numeric characters here: <input id="number" type="number" step="0.01"></label>
  
  <dl>
    <dt><code>input.value</code>:</dt>
    <dd id="value"></dd>
    <dt><code>validity.valid</code>:</dt>
    <dd id="validity"></dd>
  </dl>
</form>

<p>Browsers differ subtly on what they allow as <em>valid</em> values for HTML5 <code>&lt;input type="number"&gt;</code> fields. Not a big deal because you always validate and sanitize your incoming data on the backend too, right? (hopefully you do)</p>

<p>Unfortunately it’s also hard to add custom fallback JavaScript validation because the spec requires that browsers <a href="https://html.spec.whatwg.org/multipage/input.html#number-state-(type%3Dnumber)"><em>empty</em> the number input’s <code>value</code></a> if the input contains a string that can't be converted to a floating point number! This is a problem because some browsers treat commas as <em>numeric</em> while others don’t, and there’s no way to fix up the <code>value</code> with JS before it’s cleared out internally (as far as I can tell)…</p>

<p>If someone knows how to handle these cases more consistently, or has different test results, I’d love to hear it.</p>

<h2>Cross-Browser Test Results (April 2020)</h2>

<p>Update for 2020: there is more consistency now, with Firefox behaving in line with the decisions made by Safari and pre-Chromium Edge. The new Chromium-powered Edge understandably matches Chrome’s <code>number</code> handling. Assuming you no longer support IE11, that leaves only the two divergent paths to test (Chromium vs Non-Chromium), which at least is better than the state of things in 2018.</p>

<table>
  <tr>
    <th><span hidden>Browser</span></th>
    <th>Allows Non-Numeric Input</th>
    <th>Empties <code>value</code> when Invalid</th>
    <th>Commas are Valid*</th>
    <th>Allows trailing . point</th>
    <th>Validation Styling</th>
    <th>Validation Tooltips</th>
    <th><code>validity.valid</code> Set</th>
  </tr>
  <tr>
    <th scope="row">Chrome / Edge (Chromium)</th>
    <td>No</td>
    <td>Yes</td>
    <td>No, can’t be entered</td>
    <td>Yes (removes from value)</td>
    <td>None</td>
    <td>On submit</td>
    <td>Yes</td>
  </tr>
  <tr>
    <th scope="row">Firefox</th>
    <td>Yes</td>
    <td>If any non-numeric characters (including commas)</td>
    <td>Not valid, but can be entered</td>
    <td>Valid in <code>value</code> but only if 1st .</td>
    <td>Red border</td>
    <td>On submit</td>
    <td>Yes</td>
  </tr>
  <tr>
    <th scope="row">Safari (Desktop / iOS)</th>
    <td>Yes</td>
    <td>If any non-numeric characters (including commas)</td>
    <td>Not valid, but can be entered on desktop</td>
    <td>Valid in <code>value</code> but only if 1st .</td>
    <td>None</td>
    <td>On submit</td>
    <td>Yes</td>
  </tr>
  <tr>
    <th scope="row">Edge (Pre-Chromium)</th>
    <td>Yes</td>
    <td>If any non-numeric characters (including commas)</td>
    <td>Not valid, but can be entered</td>
    <td>Valid in <code>value</code> but only if 1st .</td>
    <td>Red border on submit</td>
    <td>On submit</td>
    <td>Yes</td>
  </tr>
  <tr>
    <th scope="row">IE11</th>
    <td>Yes</td>
    <td>No</td>
    <td>Yes</td>
    <td>Sure, use as many . as you like, <em>almost</em> everything seems to be considered <code>valid</code> input in IE11</td>
    <td>Red border on submit</td>
    <td>On submit, but only for certain cases</td>
    <td>Only <code>false</code> when <code>step</code> is invalidated? Really broken.</td>
  </tr>
</table>

<p><strong>* Note:</strong> commas <em>are</em> numeric in certain regions of the world, as they are often used as “thousands” delimiters and sometimes as the decimal separator symbol — here I’m mostly concerned with the lack of consistency in what can be entered between browsers. I haven’t tested for what happens when your page is specified as being in a language where commas are more significant (e.g. do browsers like Chrome allow them to be entered, then?)</p>