I'd like to propose adding new IDL attribute to HTMLInputElement.
readonly attribute DOMString rawValue;
If I understand the main use case correctly. This probably should be
called displayValue or something.
Yeah, displayValue sounds better.
What about type=file ?
IMO, the IDL attribute should work only with input types of which value
mode is "value". Value mode of input[type=file] is "filename", so empty
string should be returned.
- We can enable text field selection APIs for email, number, and other
types
So you want to enable select() etc. for these types? Are there real
needs here?
Yes, I'd like to enable selection API for at least type=email and
type=number. All of their existing implementations are text fields. I
haven't seen a request to suport selection API for type=email, etc..
However lack of selection API looks a defect to me.
- JavaScript-based screen readers can read user-visible content of input
fields.
For localized strings (date, datetime, datetime-local, month, time,
week), it doesn't seem to be difficult to hard-code the string
conversion functions into a JavaScript screen reader. For inputs that
are being edited (date, datetime, datetime-local, month, time, week,
number), I wonder if we should instead remove restrictions like this:
# User agents must not allow the user to set the value to a non-empty
# string that is not a valid floating-point number.
and just let .value returns the raw input while a user is editing the
value and let value sanitization algorithm happen afterward.
It doesn't work for type=email.
Suppose an email field has "root@グーグル.com" as a display value. A screen
reader reads it as "[email protected]" because HTMLInputElement::value
returns a sanitized string.
--
TAMURA Kent
Software Engineer, Google
