[whatwg] Forms-related feedback

[Ian Hickson]

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.


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

I disagree. HTML is built on top of native APIs, even in Firefox OS and 
Chrome OS. It doesn't make sense to make HTML have all the APIs needed to 
talk to the OS.


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


>  - 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 just don't see how this is workable.

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