On Wed, Nov 21, 2012 at 7:51 AM, Ian Hickson <i...@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
