[whatwg] [Web Forms 2.0] Last minute suggestion - The <format> element.
Olav Junker Kjær
olav at olav.dk
Sun Jan 23 10:32:01 PST 2005
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
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
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.
Olav Junker Kjær
More information about the whatwg