[whatwg] [Web Forms 2.0] Last minute suggestion - The <format> element.

[Olav Junker Kjær]

Jim Ley wrote:
> I understood the idea of form controls was consistency, not native
> control, if it is native control (which I'd much prefer, as I find it
> very hard to learn new UI's) then I think they'll be huge difficulty
> in implementing it, as only Safari has really easy access to native
> controls of IE+script, Opera, Mozilla etc.

I don't expect implementations to actually use the native date picker. 
However, I think implementations should use a date picker that looks and 
feels more or less native by default.

Consistency means different things to users and authors.
Users like consistency across different sites and consistency between 
native apps and websites. Most users only use one browser on one 
platform, though.
Authors and designers on the other hand usually want consistency across 
different browsers and platforms, but often also want to customize the 
UI on their site.
UAs have to cater to both groups.

The sensible compromise is to have good defaults. Controls should look 
and feel native by default, and configured for optimal 
user-friendliness. However authors should be able to override some of 
the look and feel through CSS.

In the case of date pickers, the sensible default is to have users pick 
or enter dates in the format of their own culture, and display the dates 
in an unambiguous format (that is, with named months). It would be very 
confusing if the user have to enter dates in different formats on 
different pages.

So I think its a good thing (for compatibility) if date controls are 
able to parse and submit dates in different formats, but (in most cases) 
a bad thing if the author overrides the default UI date format.

> but "UI Power" isn't always the only important thing - ease of data
> entry, which is I think the main point of Matthew here, is such that
> forcing the format is useful - of course you don't need to use the
> input type="date" in this scenario, (do you in any?) but it is an
> important usecase, I've yet to see a date control on any platform that
> is as fast to enter a date as an <input type="text"> - of course
> that's only relevant if you know the date to input, lots of the time
> you don't, which is why we have the richer controls because they
> provide information.

I think its more important that a date is unambiguous than its easy to 
enter. Its fast to type a date in your native format, however its not as 
fast if you have to parse a format hint and rearrange the day and month 
in your head, because the page author decided that every user should use 
the same date format regardless of their culture. And its dangerously 
error prone, since date typing is second nature.

regards
Olav Junker Kjær