A webpage is not always broken because of a large mistake. Small details can produce exactly this problem: debugging: number input rejects a decimal. This guide shows you what to look for, a concrete fix, and how to check that it worked.
The Idea in Plain English
With type="number", step defaults to 1, so some decimal values can cause stepMismatch when no suitable step is provided.
You can test this using a small local HTML file. Change one part at a time and check the result in the browser before adding more code.
A Working Example
The first part shows a problem. The second part shows a safer or more accurate version. Compare them before reading the explanation.
<!-- Problem -->
<input type="number" name="rating" min="0" max="5">
<!-- Corrected example -->
<label for="rating">Rating</label>
<input id="rating" type="number" name="rating" min="0" max="5" step="0.1">What Each Part Does
- The input creates a field; its type changes the editing controls and the name identifies submitted data.
- The label tells visitors and assistive tools what a control is for.
- type chooses the relevant kind of script, input, media or embedded object.
- name identifies a field in submitted form data or a named metadata entry.
- for connects a visible label to the control with the same ID.
Before the fix, the browser can behave incorrectly or report a warning. After the change, test the exact failure rather than assuming the page is fixed.
Try It Yourself
Enter 3.5 and check whether browser validation accepts it.
Common Beginner Mistakes
- Check the underlying cause before changing unrelated tags.
- Changing several parts of the example at once, making it difficult to see which part caused a different result.
- Choosing a tag only because its default appearance looks right, without checking whether it describes the content correctly.
Key Takeaways
- With type="number", step defaults to 1, so some decimal values can cause stepMismatch when no suitable step is provided.
- Before the fix, the browser can behave incorrectly or report a warning. After the change, test the exact failure rather than assuming the page is fixed.
- Test the markup in a browser, and check accessibility and real-world behavior where relevant.