datetime input (was: Re: [whatwg] Web Forms 2.0 comments)

[Sander]

Thinking about datetime input values (as they currently exist) while writing
this email, I have realized that the zero-point for step is currently
undefined for all datetime-related input types (well, the spec says it's
"0", but I call that undefined). For time it's reasonable enough to put
this as "00:00:00", but date is harder. (0? 1900? 1981? the current year?
(And if so, the current day? Current time?)) This will need to be specified
in any case. (Alternatively it might be easier to specify a default "min"
value.)

Ian Hickson wrote:
> The problem is that with your solution, UAs have to be able to work out
> how to render the UI of thinks like "d,h,m,15w". I have no idea how that
> would look, let alone how a UA would handle it or how to specify it in
> the spec.

Assuming that the order of the fields specified can be ignored by the
useragent and just treated as largest first (a reasonable enough assumption
I think), plus assuming that you meant w for week of the year, and m for
minute (various languages use different conventions, so here I went for the
easiest one) :), I think it would look roughly the same as <input
type="local-datetime" step="9072000">, except without a year identifier.
Actually, that's not true, as not all days will have the same amount of
seconds within them (are useragents required to be aware of this per one of
the ISO specs?), and so where with d,h,m,15w the useragent can omit showing
a time input part because the "step" is 15 weeks, using step="9072000" the
useragent will (often?) have no choice but to show something really weird.

Ignoring that for the moment however, what I think would be shown is either
a compressed yearly calendar view with just one date every 15 weeks
"clickable", or something akin to a select box listing all possible values
within one year.
W1-01T00:00 (or whatever the correct syntax would be)
W16-01T00:00
W31-01T00:00
W46-01T00:00
Or in general, both for the datetime/local-datetime input types and for this
proposal, what will be shown is likely to be twofold, consisting of
something to pick a date with (a calendar), and something to pick a time
with (a clock), and the level of precision for both will determine the
exact looks. (I think in practice useragents will default to the combined
widget some section 2.1.2 - sample-datetime-ui-1.png - where clicking and
left and right arrow keys will select a datetime part (if changeable per
the step), and up and down arrow keys will move that to the previous and
next allowed values.)

Anyway, that is but to say that I really don't think this proposal is
inherently less specifiable, although several choices will need to be made
before it's usable. For example, if you had meant "w" as weekday and "m" as
month, then there'd have been need of information about a year for the
possible values to be consistently generated. So in the absence of "y",
we'd have to define that the useragent should assume the current year (?)
for calculating those. Which would lead to the following possible values:
Thu01-01T00 (Does that ISO spec specify a way to write down weekday? [Sorry,
not online while writing this, or I'd look it up to do this right.])
Fri01-16T00
Sat01-31T00
Sun02-15T00
Mon03-01T00
...etc

What's more worrysome to me is that it might be confusing for authors that
there's a difference between 1h,m,s and h,m,s (both returning the same
format, but the former with a step of 1 hour) - but as authors will only
consciously include the 1, I see this as acceptable.


I realize I'm not expressing myself as clearly as I'd wish here (I fear I
lack either the vocabulary or the experience putting my thoughts in precise
enough terms), but do you agree that the complexity of this proposal is not
inherently much worse than that of the current multitude of input types?

Are there any other people with feelings about this? Am I the only one who
believes that a lot of situations will be encountered where the six
datetime types currently available will prove to be too limited, and that
I'd really prefer one type="datetime" capable of handling it all?


>> Use case: a nature photography website with a list of national parks: 
>> asking users for each "what is the best month of the year to visit this 
>> park?"
>> input type="month" is 'useless', as it includes a year (this usecase 
>> makes me realize I liked it better when it was called expdate, as that 
>> name at least suggested the existence of the year).
> 
> For a dropdown to pick a month, there is nothing wrong with <select> with
> twelve child <option> elements.

Indeed. And yet, if it's all the same to you, I'd much rather write <input
type="datetime" format="m"> then the 14 lines for the select; particularly
as I can just see the client for that site coming back a few months later
with a request to increase the specificity to week. 52 lines of "jan 01 -
07" don't make me happy, where <input type="datetime" format="w"> does. :)
("Week" might seem too specific to people, and the example thus moot, but
week is exactly how I'd do it; for then you could throw a normal
distribution curve around that time and create a really nifty graph showing
"likelihood of this place being worth a visit" spreading over the year.)

Sander