[whatwg] Forms-related feedback

[Ian Hickson]

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

What if the user sees a calendar with a date circled? Or the string "your 
birthday"? (Exposing that would be a privacy violation.) Or what if the 
user doesn't see anything (because it's not a visual UA), but every time 
the user focuses it, the user agent plays a tune from one of Vivaldi's 
four seasons, followed by a trill to indicate how far into the season the 
date is?


> Value set by script or not doesn't matter.

I mean, how would the user agent parse the script's new value.


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

Providing localisation is definitely something we should do, but rawValue 
isn't a sane way to do it. You don't want to have the "format a date" API 
be "create an <input> element, sets its value, and read it back".


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

The point of type=number is that the browser can do this, no need to 
reimplement it. (If an author does want to reimplement it, Web Components 
are presumably the long-term solution: reimplement the widget.)


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

We can force it. If we don't provide the API, the author can't do it.


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

The demo he gives is:

https://chromium.googlecode.com/issues/attachment?aid=2639100003000&name=caret.html&token=tDkJ1CbBJ1hhXbsgb9Y0MRMzlks%3A1379968341420

If people want to reimplement widgets, then we should make sure Web 
Components can support their particular widget desires. I don't think it 
makes sense for us to make the default widgets be able to support every 
weird thing people want to do.


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

On Wed, 21 Aug 2013, Anne van Kesteren wrote:
> 
> If we start doing this (and other things you proposed) we'll constrain 
> future implementation strategies for this control. And other 
> implementations might be forced to follow particular conventions in 
> order to not break sites. That doesn't seem exactly ideal.

Exactly.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'