Re: [whatwg] Forms-related feedback

On Sat, Jul 13, 2013 at 6:39 AM, Ian Hickson <ian@hixie.ch> wrote:
> On Wed, 9 Jan 2013, TAMURA, Kent wrote:
>> On Wed, Nov 21, 2012 at 7:51 AM, Ian Hickson <ian@hixie.ch> wrote:
>> > On Fri, 7 Sep 2012, TAMURA, Kent wrote:
>> > >
>> > > * 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].

> I still don't understand how this would work. You suggest that it should
> work for type=date, but how? What happens when it's mutated by script,
> for instance? I really don't understand the purpose here or how it would
> work to achieve that purpose.

As for type=date, rawValue should return what a user see. Value set by
script
or not doesn't matter.
In Google Chrome, rawValue should return a localized date value such
as "21/08/2013".

I saw some questions/requests of a way to get a localized date string in
crbug.com and stackoverflow.com.  One of reasons one wanted to get it was
that there are no ways for script to get localized date format used in
type=date.
One wanted to get the format to use consistent date format in a web page,
another
wanted to get the format to focus on specific field in type=date (Note that
a type=date
instance in Google Chrome contains multiple focus targets.)

As for type=number, I heard a web author wanted to get invalid value typed
by
a user in order to show friendly error message without HTML interactive
form validation.


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

> Why is that a valid thing for a page to be doing? The browser should take
> care of doing that, not the page. If the page does it, it'll be different
> on each page and the user will get confused.

We can't force it.  Web authors do what they want.

https://code.google.com/p/chromium/issues/detail?id=263910#c3
This is an actual case.  I talked with him, and he said <datalist> didn't
work
in his case because he wanted to show images on choices.


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

> How is that possible in the case of a custom e-mail widget where the
> e-mail address isn't shown, but a user picture and name is shown instead?

I think rawValue isn't necessary in such UI. However all of existing
type=email
implementation is a text field.



-- 
TAMURA Kent
Software Engineer, Google

Received on Wednesday, 21 August 2013 01:27:50 UTC