Sanitize the value of an input in :placeholder-shown - #363

I'm being a bit more strict about a lot of these spec fixes to try and make sure I'm not just getting another one in the same area a few days later, tweaking something that previous fixes missed. This is a review of the current changes.

I checked the 12 cases in this PR's test, plus 41 more, against :placeholder-shown in Chrome 157, Firefox 159 and Safari 27.2. The approach is right, and the sanitization for text-like types, url, email and invalid number values matches all three browsers. One case doesn't, and the docstring needs to record the decisions, so this needs changes before it can be merged.

For context, the convention for these form-state pseudo-classes is in CSSMatch.match_range(). We follow the HTML spec, except where all browsers agree on something else. Then we follow the browsers and document the difference in the code. Where browsers disagree with each other, we follow the spec.

1. A number value that overflows a double must show the placeholder

<input type="number" placeholder="p" value="1e9999">
<input type="number" placeholder="p" value="-1e9999">

Chrome, Firefox and Safari all match both with :placeholder-shown, and this PR doesn't. 1e9999 is a valid floating-point number by syntax, so the spec's sanitization keeps it. But every browser drops a value that doesn't fit in a double, so per the convention above we do too.

Required change: in match_placeholder_shown(), replace not RE_NUM.match(value) with Inputs.parse_value('number', value) is None. parse_value() already rejects non-finite numbers and accepts the same syntax as RE_NUM otherwise. It is also what :in-range and :out-of-range use for the same value, so the two pseudo-classes will agree. Please add both inputs above to test_placeholder_shown_sanitized_value as matching.

2. Document where this departs from the spec or from a browser

The docstring says the value is sanitized "as browsers do", but it doesn't record the two places where the spec and the browsers part ways. Without that, the next audit will report them as bugs. Please add:

• A number value that overflows a double (1e9999) is emptied, as in all browsers, although the spec's sanitization would keep it.
• Firefox keeps value="1." for a number input, so it hides the placeholder. Chrome, Safari and the spec empty it, and so do we. You note this in the PR description; it needs to be in the code.

Everything else checks out. That includes CR and form feed, non-breaking spaces (correctly not stripped), email multiple, upper-case and unknown types, textareas, and empty or whitespace-only placeholders. Moving input and textarea into one :is() is fine, and the changelog entry is accurate. Please update the changelog entry to mention the overflow case once it's fixed.

Thanks for checking it against all three browsers. Both points are done:

1. match_placeholder_shown() now uses Inputs.parse_value('number', value) is None, so a number that overflows a double is emptied, as :in-range reads it. value="1e9999" and value="-1e9999" are in test_placeholder_shown_sanitized_value as matching. I checked them, with 1e308 and -.5e2 as non-matching controls, in Chromium, Firefox and WebKit, and all three agree.
2. The docstring now follows the convention of match_range() and records both deliberate cases: the overflow, where we follow the browsers over the spec, and Firefox keeping value="1.", where we follow Chrome, Safari and the spec.

The changelog entry mentions the overflow case.

You mention you checked 1e308 and -.5e2 as controls that still hide the placeholder. -.5e2 is already in the test, but 1e308 isn’t. Adding it would test the edge of the overflow cut-off. Can you add that?

Done: value="1e308" and value="-1e308" are now in test_placeholder_shown_sanitized_value as non-matching, next to the 1e9999 cases, so the test covers both sides of the overflow cut-off.

Please add sanitization to en-custom.txt to fix the spell check error.

@gir-bot lgtm