Last Call feedback on Date/Time controls

As part of our Last Call review, we want to highlight concerns about the
following date/time related input types:

  * Datetime
  * Date
  * Month
  * Week
  * Time
  * Datetime-local

While we believe these controls are ultimately useful, the feedback we have
heard from discussing them with web developers suggests that there are gaps
in the platform that will make them less likely to be broadly adopted.

There are three major gaps which we believe will hurt adoption: 

1. Control styling

a. Designers and developers of major web sites care very deeply about the
   experience users get on their sites. The major frameworks that provide
   datetime controls today all allow the developer to choose how the controls
   appear, specifying how many months to show at a time and styling properties
   of the calendar so that the experience fits the context of the site.
   Without the ability to style these controls developers will be wary of
   replacing their current implementations.

2. Date formatting

a. Date formatting is another challenging issue due to both web site needs and
   localisation challenges. For some web sites it may be very important to show
   the day of the week, for others it isn't. Web developers will want to choose
   from the various options to determine how dates are displayed on their site.

b. Localisation is also challenging for date formatting since the way dates are
   formatted can change their meanings to different people. Because web sites
   might want to echo back the selected dates in a query result it may produce
   a more consistent experience for the end users if the site could choose the
   date formatting.

3. String localisation

a. There are numerous examples on the web today of web developers searching
   for a way to localise the 'browse' button that is used on file upload
   controls [1],[2],[3],[4],[5]. There is already at least one public example
   of web developers asking how they can localise the date control [6]. A rich
   datetime control requires strings and it should be expected that string
   localisation will become an issue in these controls if developers do not
   have a way to specify their requirements.

We are interested in feedback from more web developers on these concerns. We
are not proposing any specific changes to HTML5 at this point. The styling and
formatting issues are probably best handled with CSS. If the working group
agrees, it might be prudent for the chairs to reach out to the CSS WG through
the usual liaison channels. The CSS WG might consider this area as they
recharter the next period of their work. String localization is probably
something that can wait until the next version of HTML and I have added a
note about this to the HTML Next Wiki page [7].

Cheers,

Adrian.

[1] http://doctype.com/localize-browser-chromeui-input-typefile-elements
[2] http://stackoverflow.com/questions/1460731/html-upload-localize-browse-button
[3] http://forums.asp.net/t/1426223.aspx
[4] http://forums.asp.net/t/1121953.aspx
[5] http://cdnclovr.blogspot.com/2009/06/how-to-localize-browse-button.html
[6] http://stackoverflow.com/questions/2968817/is-there-a-way-to-localize-input-type-date-in-html5
[7] http://www.w3.org/wiki/HTML/next#Localising_Form_Controls

Received on Wednesday, 29 June 2011 01:02:10 UTC