[whatwg] Exposing visible string of an input field
TAMURA, Kent
tkent at chromium.org
Mon Sep 10 23:15:08 PDT 2012
>> 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 "root at xn--qcka1pmc.com" because HTMLInputElement::value
returns a sanitized string.
--
TAMURA Kent
Software Engineer, Google
More information about the whatwg
mailing list