[whatwg] Exposing visible string of an input field

[Kang-Hao (Kenny) Lu]

(12/09/07 17:49), TAMURA, Kent wrote:
> Proposal:
> 
> 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.

> It returns text content which a user actually see in an input field.
> * For text, search, url, tel, password types, it's equivalent to 'value'
> IDL attribute.
> * For email type, it returns a string which a user is editing.  It means it
> returns a string without Unicode -> Punycode conversion and without
> normalization of whitespace and commas.
> * For number type, it returns user-editing string. If a user typed '123+++'
> into a number field, rawValue would be '123+++' as is.
> * For date, datetime, datetime-local, month, time, week, the attribute
> returns a string in a field. If a field is text-editable, it should return
> user-editing string like email and number.  If a field has a fixed
> localized date/time string chosen by a date/time picker, the attribute
> should return the localized string.
> * For submit, reset, button types, the attribute returns a label which the
> field shows.  e.g. 'Submit' for <input type=submit> without value
> attribute.
> * For other types, should it return an empty string?

What about type=file ?

> Use case:
> 
> - 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?

> - 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.

> Strings returned by rawValue attribute may be browser-dependent and
> locale-dependent. However it would be useful.

The proposed feature sounds a bit messy to me...


Cheers,
Kenny
-- 
Web Specialist, Oupeng Browser, Beijing
Try Oupeng: http://www.oupeng.com/