[whatwg] Forms-related feedback

[Ian Hickson]

On Mon, 14 Jan 2013, Jonas Sicking wrote:
> On Jan 8, 2013 1:47 AM, "Ian Hickson" <ian at hixie.ch> wrote:
> > On Tue, 27 Nov 2012, Mikko Rantalainen wrote:
> > > Ian Hickson, 2012-11-22 07:15 (Europe/Helsinki):
> > > > On Wed, 21 Nov 2012, Mounir Lamouri wrote:
> > > > >
> > > > > Then, maybe a better naming could be "datetime-utc"?
> > > >
> > > > I think that would mislead authors into thinking that the UI that 
> > > > users will see is one that asks for a UTC time. That kind of UI is 
> > > > the worst UI for this kind of feature, so that would be 
> > > > misleading.
> > >
> > > I'd suggest "datetime-absolute" because the other variant is 
> > > "floating" or "relative" (to local politically decided time which 
> > > may vary depending on future political decisions).
> >
> > We could rename "datetime" to "datetime-absolute" and leave 
> > "datetime-local" as named, but I'm not really convinced that's much 
> > better than what we have now.
> 
> I think it more common for people to interact mainly with people in 
> their own timezone. I.e. most time when talking about dates and times 
> people don't mention what timezone is involved and rely on context to 
> provide that information.

I agree that that is accurate for when people talk. But that's somewhat 
misleading, I think, regarding what it implies about form controls.

In Web apps, there's basically three cases:

1. Cases where you mean a specific global time (a time relative to UTC), 
   for coordination amongst people from many locations.

     For example: the time that a broadcast begins
                    e.g. a live Hangout on G+
                  the time that a deliverable is due
                    e.g. the due date for a poetry contest
                  the time that a resource becomes available and the time 
                    it stops being available, if scheduled in advance
                    e.g. the time that a meeting phone bridge code starts 
                         working and the time it ends working

2. Cases where you mean a specific global time (a time relative to UTC), 
   but where the time is really only relevant for local purposes, and so 
   when given is likely to be given relative to an implied time zone.

     For example: the time that a plane takes off or lands
                  the time that a physical meeting (not one involving 
                    video conferencing across multiple sites) begins
                  the time that someone wants to go home from work

3. Cases where you mean a floating time and no time zone actually applies.

     For example: a wake-up alarm on a phone ("wake me up at 8am on 
                    Monday", where the time zone isn't decided until 
                    Monday, by examining where the user is)
                  the time for an event celebrated at different times in 
                    different time zones, e.g. New Year's.

Now, when implementing these, there's often mistakes made. For example, 
authors will often confuse case 1 for case 2, and will often confuse case 
2 for case 3. That is, they will often assume a time zone when one should 
not be assumed, and will often forget about time zones entirely when a 
time zone should be assumed.

For example, they may ask for the time that a broadcast begins, and then 
just assume that the time zone is the time zone of the server. This would 
work fine in a single-time-zone-company where the server is colocated with 
the users. Similarly, they might ask for the time of a plane's departure, 
and then display it in the user's time zone, forgetting that there's an 
implied time zone given by the user's location.

The opposite error is harder to make. It's harder to ignore the time zone 
when all times that the user enters get converted to UTC -- unless you're 
in the UK during the winter, or one of a handful of other countries using 
UTC, you're likely to notice right away (and even in those, in many cases 
you'll likely notice within 6 months).

Because of this likelihood for mistakes, the controls are designed so that 
forgetting a time zone requires more characters than giving one. Authors 
are less likely to initially use datetime-local than datetime, so they're 
more likely to be reminded to use time zones immediately, than they are to 
forget to use time zones until too late.


> So in most contexts when people think about a point in time, they do so 
> for a specific timezone.

I don't know how to evaluate if this is true.


> When that is not the case, this is something that people are aware of. 
> When I interact with friends/family/coworkers where the timezone is not 
> obvious this is quite clear. And in these cases I'm aware that I need to 
> specify timezone.

I don't know that that's the case. I think it's more likely that authors 
will incorrectly forget to use time zones when they should have, than it 
is for them to use time zones when they should not. That, as described 
above, is the principle on which the spec's design was based.


> So I would imagine that when a developer sees "datetime" that does not 
> include a timezone. Likewise, when a developer wants to ask the user for 
> a point in time which does include a timezone, that they would remember 
> to ask for that explicitly.

Those are not the only two situations. I think another major case is the 
case where the author needs to ask for a globally specific time (i.e. a 
time with a time zone), but without making a big fuss over the time zone. 
That's the case for which <input type=datetime> is useful. I don't know if 
it is the most common case, but I would not be surprised if it was. (This 
is case 1 in the list above.)

The two cases you list -- of asking for a time without a time zone, and of 
asking for a time and an explicit time zone - are the cases for which 
type=datetime-local is appropriate.


> Additionally, in many cases even when timezones are involved do UIs not 
> ask for the timezone as part of the date/time picker.

Right. You likely shouldn't (by default) show a time zone in the 
type=datetime UI.


> When looking for airplane tickets the timezone is assumed to be that of 
> the departing location when talking about departing time, and that of 
> the arrival destination when talking about arriving time.
> When renting a car, the same thing applies, even if the car is picked up 
> and returned in different timezones.

Right; for those, you'd want datetime-local. There are definitely use 
cases for both, I don't think anyone is disputing that.

You could name them in a variety of ways: datetime-local could instead be 
named datetime, datetime-floating, datetime-without-timezone, etc. 
Similarly, datetime could have instead been named datetime-global, 
datetime-utc, datetime-with-timezone, normalized-datetime, 
specific-datetime... There's lost of options.

In every case, there's a tradeoff made. If we name the one without time 
zone normalisation "datetime", then authors are likely to forget time 
zones until it's harder to fix (as discussed above). If we name the one 
with normalisation "datetime-utc", author are likely to avoid it even when 
it's appropriate, because it has a scary name. If we give both of them 
long names, then authors never have the convenience of a short name. If we 
give one a short name, then we run the risk of it being ambiguous and 
confusing. These are all the normal tradeoffs we have to make whenever we 
do language design; there's nothing especially unusual about this case.


> Even the calendar app that's on my device (the built-in calendar app for 
> Android 4.2) does not ask for timezone as part of the date/time picker.

It's important not to confuse the UI with the value space. I'm not 100% 
familiar with the Android date pickers (and they have changed over time). 
In the case of HTML's, there's a picker that picks a floating time and 
there's a picker that picks a specific time. They can in fact have the 
same UI. The one with the time-zone normalisation _could_, in advanced 
UAs, allow the user to pick an explicit time zone to give the time in, but 
that time zone isn't then transmitted to the author. The one without 
time-zone normalisation is in fact the one most likely to be used in UIs 
that include explicit time zone pickers.

I think the Android pickers are actually more equivalent to type=date + 
time=time, rather than either form of type=datetime/datetime-local.


> Instead a separate control is used where the user can choose what 
> timezone the separately entered date/time is. This makes a lot of sense 
> since timezones are easy to forget about and so having explicit and 
> separate UI makes things more unlikely that the user will forget to 
> enter the information.

In the cases where the user is expected to explicitly enter the time zone, 
the time zone is likely to need to be sent to the server, and you probably 
want to use type=datetime-local with a <select>.


> This is actually required for repeating events since it's important to 
> know which timezone the user picked. I.e. there are two values entered 
> by the user: the date/time and the timezone.

Right. The high-profile cases -- calendars and airline booking sites -- 
are actually two of the more complicated cases, and neither is likely to 
use type=datetime. Having the more complicated cases use the more 
complicated types is generally a good thing.


> So first off I'm not convinced that the common case for date/time entry 
> will include entering a timezone.

I agree, and type=datetime doesn't involve entering a time zone. The case 
where you enter a time zone is generally going to use type=datetime-local.


> Second, I'm not convinced that even if the common case includes timezone 
> entry, that this means that the intuitive behavior for a "datetime" 
> input type is to include UI for timezone entry.

Agreed.


> Third, I think that even in many cases where timezones are involved, 
> that the better UI is to have timezone entry separate from from the 
> date/time picker.

Agreed.


> I'm not advocating that having a timezone aware date/time picker is a 
> bad idea. But I don't think it should be the "default" behavior. It 
> might not even make it into the 80% set of use cases.

I don't think a time-zone-aware picker is the same as a datetime picker 
that shows time-zone UI.


> So at least we should make "datetime" refer to a timezone-agnostic 
> picker. And then use "datetime-global" or "datetime-absolute" or some 
> such as a timezone aware picker.

There's two axes of time-zone-*ism: the data entry space, and the value 
space. They are not the same, and I think that confusing them is leading 
to a confusion regarding why the controls are named as they are.


On Wed, 16 Jan 2013, Julian Reschke wrote:
> On 2013-01-08 01:47, Ian Hickson wrote:
> > > The next best choice would be to have datetime-with-timezone but 
> > > unfortunately
> > > 
> > > (1) Official database for all timezones does not exist
> > > (2) Official timezone names (or labels) do not exist
> > > (3) Timezones are subject to future political decisions
> > > 
> > > The problems (1) and (2) make transferring the timezone information 
> > > from the end user to the server very problematic and the problem (3) 
> > > makes any work to fix (1) and (2) a bit pointless. This is because 
> > > even if UA could successfully inform the server about the correct 
> > > timezone, the server could be using a week old timezone data that is 
> > > not up to the latest political events. Or the server might be using 
> > > latest timezone data but the UA could be using three year old data. 
> > > In either case, the absolute time in UTC could be different for the 
> > > server and UA.
> > 
> > Indeed.
> 
> Sorry?
> 
> <http://www.iana.org/time-zones> addresses (1) and possibly (2), no?

Yes (and it's already referenced by the spec). I was "indeed"ing the 
problem with servers and clients disagreeing about which version of the 
data to use.


On Wed, 30 Jan 2013, Mounir Lamouri wrote:
> 
> I feel like there is some consensus in the list to move 'datetime' to a 
> TZ-agnostic type.

I don't think this makes sense, as discussed above.


> Regarding the TZ-aware type, I believe we could simply drop it from the 
> specifications for the moment. I do not believe it is a good idea to 
> specify something when we have no idea how that could be implemented and 
> when there is no native UI that could be used.

The UI for type=datetime and type=datetime-local can be the same.


> The advantage of 'datetime-timezone' compared to 'datetime' + a UI to 
> pick a timezone is low.

The type=datetime control in the spec is not equivalent to a datetime 
picker plus UI for a time zone.


On Wed, 30 Jan 2013, Mounir Lamouri wrote:
> 
> In my war against useless input types, I had a look at 'month' and 
> 'week' and I am wondering what was the rationale behind having them in 
> the HTML specifications.
> 
> Regarding 'month', I mostly don't understand the use case.

Credit card expiry dates, amongst others.


> Given that the element is pretty trivial to implement by authors (this 
> is basically two <select> or a select and a <input type='number'>), the 
> only advantage I see to have this element in the specifications is to 
> have a native UI on mobile.

It also makes autofilling the values significantly easier to manage.


> I am wondering if use cases were taken into account when this was added 
> to the specs

Yes, we got rid of a bunch of controls for which use cases couldn't be 
found.


> I can see niche use cases for 'week' but I do not think it is easy to 
> come up with a good UI for this, especially on mobile (there is no 
> native UI on mobile AFAIK). On desktop, Chrome's UI is terrible but the 
> Opera one is decent.

Maybe not coincidentally, type=week is more common in Europe, where many 
companies manage data on a weekly basis using ISO weeks, rather than in 
the way US companies manage data, which is mostly using full dates.


[snip other people giving other use cases - thanks!]


On Wed, 30 Jan 2013, Nicolas Froidure wrote:
> 
> I will go more far. I'd like to have an <input type="day" />. I often 
> have the need to create forms where the user choose an interval of 
> "days". By example, from 1st March to 30 November. Currently i use 
> <input type="date" /> and i ignore the year.

I think adding this would make sense once we have more experience with the 
current types. (February makes "day" a bit more annoying than I'd like.)


On Tue, 12 Feb 2013, Jukka K. Korpela wrote:
> 
> What are the odds that browser vendors will implement <input type=month> 
> in a simple manner that allows fast typing as one input method? Rather 
> small I think.

File a bug, if they don't. At least you only need to get one 
implementation fixed rather than every site...


On Wed, 13 Feb 2013, Glenn Maynard wrote:
> 
> A trickier issue for weeks is which day the week starts on.  To me, 
> calendar weeks start on Sunday and end on Saturday.  I'd find it weird 
> to be shown a Monday-aligned calendar, but this is hard to localize, 
> since the browser can't return anything but Monday-based week numbers.  
> This would probably work better if the result was a date, not a week 
> number, so it could return both Sundays and Mondays, but this might lead 
> to localization bugs.

The main use case intended for type=week is the use of ISO week dates in 
corporate environments in Europe, which are all going to use Monday- 
aligned weeks. But once we have solid implementations of the existing 
types, we can certainly see what other use cases there are and add support 
for those, as appropriate.

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