EWS run on previous version of this PR (hash c9d4536)

This does not seem correct to me. I don't think we should convert whatever is assigned to the value setter. Instead we should convert what the end user types in before changing the underlying value.

We probably also want web-platform-tests to ensure other browsers do it in the same way.

Thanks for the clarification — you're absolutely right from the HTML spec perspective.

This patch currently applies normalization even when assigning full-width characters via .value, which is technically out of scope per the spec. Chromium, for that reason, limits normalization strictly to native keyboard input, avoiding changes to setter behavior. That behavior aligns with the spec as written.

Interestingly, Firefox does accept .value = '１２３' and normalizes it internally, even though that's not defined by the spec either.

As I understand it, Web Platform Tests (WPT) are meant to test only behavior that is explicitly specified in the HTML standard. So if we restrict normalization in WebKit to occur only during native keyboard input, that behavior would fall outside the spec — and therefore outside the scope of WPT. Similarly, the current LayoutTests covering this would no longer be valid unless the behavior is spec-defined.

With that in mind, I'd like to ask:
Is there interest in proposing a change to the HTML specification to define this normalization behavior more formally?
This would clarify expectations across engines, and would allow WPT coverage to be added consistently.

I'm happy to help draft a spec proposal or open an issue on WHATWG if that's of interest.

That makes sense to me, here's what I'd suggest:

1. We test that the value setter and value attribute don't support this in WPT.
2. I think proposing a change to the HTML standard whereby at least a set of non-ASCII numbers are a "should" is perfectly reasonable.
3. That would then allow writing WPT .optional tests. Arguably the existing note in the type=number section would already allow for that, but it's probably worth strengthening it with a normative paragraph.

Thanks so much for the quick and helpful reply — really appreciate it.

I've never proposed a change to the HTML spec before, so it might take me a bit of time to navigate the process, but I'm happy to take a shot at it.

In the meantime, I'll keep this pull request on hold until we see how the spec discussion evolves.

Thank you for improving this part of the web! If you fill out "New issue" at https://github.com/whatwg/html/issues/new/choose with the basic information I'm happy to copy the relevant people. I suspect people will agree though it might take a while to get everyone to comment, so you could do some of the other work in parallel.

I've opened a WHATWG HTML issue to propose this behavior formally:
whatwg/html#11395

Thank you again for your feedback and support!

Proposal: Improve number input sanitization to match Chromium behavior

While reviewing and updating the <input type="number"> sanitization behavior, I noticed that Chromium applies more strict filtering and normalization of user input than WebKit currently does.

Specifically, Chromium's HandleBeforeTextInsertedEvent implementation performs:

• Normalization of full-width numerals, minus signs, and full-width full stops to ASCII equivalents
• Removal of any characters not in the allowed set [0-9 . e E - +]
• Additional validation of placement rules (e.g., no duplicate decimal points, only one exponent character, correct placement of signs)

In contrast, WebKit currently only normalizes some characters and allows others to remain in the field, which can result in invalid floating-point representations.

Given that the HTML specification states that:

User agents must not allow the user to insert a string that is not a valid floating-point number.

... it seems appropriate to consider aligning WebKit's sanitization more closely with Chromium's stricter approach.

Current progress

So far, I have implemented an initial version of normalization that:

• Only applies to user input (keyboard or paste), not to .value assignments via script
• Converts full-width numerals, minus signs, and full-width full stops to ASCII equivalents
• Leaves other characters unchanged for now

This approach is working well in early testing and ensures that scripted .value assignments are not unexpectedly transformed, while user input is consistently normalized.

Proposed next steps

• Evaluate implementing stricter character filtering similar to Chromium:
  • Removing any characters outside [0-9 . e E - +]
  • Enforcing placement constraints (single decimal point, single exponent, correct sign placement)
• Maintain the distinction between script assignments and user input (i.e., script .value remains unaltered)

Since building and testing these changes locally is time-consuming, I'm leaving this note here to track the proposal and current progress before proceeding with a full patch.

Reference: Chromium's HandleBeforeTextInsertedEvent implementation

Please let me know if there are any objections, suggestions, or related efforts before moving forward.

EWS run on current version of this PR (hash e782662)

I’ve implemented the behavior for now. I’ll write tests and additional improvements afterwards.