[whatwg] Forms-related feedback

[TAMURA, Kent]

I know I'm proposing a strange thing. Some use-cases are just workarounds
and there are ideal solutions.


On Tue, Sep 24, 2013 at 5:35 AM, Ian Hickson <ian at hixie.ch> wrote:
> 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?

I have no good idea for them.  However I don't think UA provides some of
such UIs.  The specification allows to implement any UI for form controls,
but web authors won't accept UIs which are drastically different from
existing implementations.
For example, existing implementations of input[type=date] have about 1-line
height by default. If a UA provided an inline-calendar-style implementation
and it requires 300px height, web authors would have a hard time to design
their pages.

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

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

It's implementation-specific even now, and unrelated to this proposal.

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

Yeah, this usecase is for a workaround. We don't need rawValue if we have a
formal way to set/get date formats.

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

I don't think Web Components becomes widely available in 10 years. Web
authors want to replace UA-builtin form validation UI now.
Do you think web authors should not use new input types if they don't like
builtin form validation UI?



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

I understand such stance. However it's hard to know whether a request is
weird or not.



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

It's too optimistic. We are already constrained.

-- 
TAMURA Kent
Software Engineer, Google