Re: Last Call feedback on Date/Time controls

On Tue, Jun 28, 2011 at 6:01 PM, Adrian Bateman <adrianba@microsoft.com> wrote:
> 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.

As has already been mentioned, this is up to CSS. I suspect what needs
to happen here is for UAs to experiment with adding various pseudo
elements which can then be styled or hidden by the page. Which
elements make sense is hard to tell until we actually have UI to
style, which is why I think UAs experimenting is the way to go.

> 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.

I'm not quite understanding how this is different from 1. Is this for
when the full datepicker is not displayed and instead a text-field
sized control is displayed which shows the controls current value?

> 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.

Again, I'm not quite understanding how this is different from 3.
Unless it's for the display-only-current-value state described above.

If this indeed is for the display-current-value state. I kind'a like
some old microsoft Visual Basic APIs that I used in a previous life
which let you describe a format using a string like "yyyy MM dd".
Though obviously this had quite a few limitations, but somehow always
seemed to work out for me (but swedish date formatting rules aren't
particularly complicated).

However I wouldn't be surprised if it has severe limitations that
makes it not work well for many locales. I would suspect microsoft has
a lot of experience with this type of solution. If that experience
simply is "it doesn't work well enough in practice" then we'd of
course have to find another solution.

> 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.

Yes, this does indeed seem like a problem. I don't agree with Tab that
you generally want to simply use the locale of the browser. It always
looks pretty terrible to me when I'm browsing on a swedish website
that suddenly has a few random elements with english in them, or the
other way around. So I think that more often than not websites will
want to use the locale of the website.

One solution to this would be to use the lang attribute on the <input>
(or an ancestor of it) to allow the website to choose which language
to use for the strings. This would of course require UAs to have the
names of the months and weekdays localized into terribly many
languages. I don't know if this is realistic or not, but given the
small number of strings that needs to be localized, it might work. Or
at least it might work well enough to cover 80% of the use cases.

A pretty terrible fallback would be to introduce attributes which let
the site define the strings to use for the month and weekday names.

/ Jonas

Received on Wednesday, 29 June 2011 03:21:43 UTC