[whatwg] Forms-related feedback

[TAMURA, Kent]

On Wed, Nov 21, 2012 at 7:51 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 7 Sep 2012, TAMURA, Kent wrote:

>> Proposal:

>> I'd like to propose adding new IDL attribute to HTMLInputElement.
>>      readonly attribute DOMString rawValue;

>> It returns text content which a user actually see in an input field.
>> [...]
>> * 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.

> This only makes sense if the control is a text control, which is not
> necessarily the ideal UI. For example, consider the GMail UI for typing
> e-mail addresses. What would you expose as the rawValue when the control
> contains two user chips, one word that is not yet converted to an e-mail
> address, and the user is dragging one of the chips to the end?

>> * For number type, it returns user-editing string. If a user
>> typed '123+++'
>> into a number field, rawValue would be '123+++' as is.

> What if the number control is a spin dial and the user has the dial
> between numbers "1" and "2"?




>> * 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.
>> [...]
>> - We can enable text field selection APIs for email, number, and other
>> types

> How would this work when the control isn't a text control? I don't
> understand. For example, consider a date control that is actually three
> separate text fields (year month day); how do you envisage the selection
> API working and how would rawValue help with this?

I think it's ok that rawValue doesn't work with form controls without any
text.
One of use cases of rawValue would be to handle user input errors.  I think
non-text
form controls should be clever enough to avoid bad user input.
For example, users can't set bad values to input[type=range].

>> - JavaScript-based screen readers can read user-visible content of input
>> fields.

> Screen readers don't have to be limited to the HTML APIs. I'd expect a
> screen reader to have a much more intimate API to talk to the UA.

There are some platforms of which native API is HTML. e.g. Chrome OS,
Firefox OS, etc.
Though Chrome OS can provide such API as chrome extension API, we had better
have a standard API.



> On Tue, 11 Sep 2012, TAMURA, Kent wrote:

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

> Why does the page need to touch the selection?

It must be same as input[type=text].
e.g.
   - A page author wants to select the whole value or nothing of an email
     form control when it gets focus.
   - A user entered an email address with unacceptable domain name.
     A page author wants to move the caret to the beginning of the domain
name.



> On Thu, 13 Sep 2012, TAMURA, Kent wrote:

>> Making an input element invalid state if the input has an invalid string
>> specified by a user with browser UI. "An invalid string" means a string
>> which doesn't match to a required format defined by a type.

>>     e.g. If a user typed "-" to input[type=number], input.validity.valid
>> would be false and form submission would be prevented.

>> A. In such case, make input.validity.typeMismatch true, or
>> B. Introduce new IDL attribute to ValidityState.
>> input.validity.invalidUserInput?

>> This behavior should be applied to the following types:
>>     number, color, date, datetime, datettime-local, month, time, and week

>> Background:
>>     If an input type is implemented as a text field, it is very hard for  
>> UA
>> to reject invalid strings for the type. For example, "-" is not a valid
>> floating-point number, but UA can't prevent users from typing "-".  So
>> the
>> field can contain invalid strings though its value IDL attribute is
>> empty.
>> If a user tries to submit the form in such situation, the field is valid
>> unless the required attribute is specified.
>>     WebKit clears the invalid string when the field loses focus or the  
>> form
>> is submitted.  A sanitized value (empty string) is submitted.
>>     Opera doesn't clear the invalid string. It silently submits a  
>> sanitized
>> value (empty string).
>>     IE10 has a behavior similar to WebKit.  However if a user
>> type "-1abc", "-1abc" is submitted.

>> I don't like clearing user input.  It's not a good user experience.
>> Users
>> don't expect their input strings are cleared by UA.
>> Also, I don't like submitting empty value silently. Users expect their
>> input strings are submitted.
>> I think the best UI is to notify users about a field has an invalid
>> string,
>> and give a chance to correct it.  Applying the standard form validation
>> mechanism must be reasonable.

> Done ("badInput").

Thank you!  I already implemented it in WebKit.


--
TAMURA Kent
Software Engineer, Google