[whatwg] Forms-related feedbackiuuuiiija

[Renoir B.]

Am I IIT in in a I'll j
I amiuin in the uKai it
quid
Renoir Boulanger
Software & Frontend developer
https://renoirboulanger.com/#is
~
~
On Jul 29, 2013 7:21 PM, "Ian Hickson" <ian at hixie.ch> wrote:

> 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.   `._.-(,_..'--(,_..'`-.;.'
>