Re: [whatwg] Exposing visible string of an input field



>> 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@xn--qcka1pmc.com" because HTMLInputElement::value
returns a sanitized string.


-- 
TAMURA Kent
Software Engineer, Google

Received on Tuesday, 11 September 2012 06:15:58 UTC