HTML 5 date/time input field UI on Desktop

Gijs Kruitbosch gijskruitbosch at gmail.com
Fri Jun 12 16:41:18 UTC 2015


FWIW,

https://bugzilla.mozilla.org/show_bug.cgi?id=773205 Implement layout 
(UI) for date/time input types on Desktop
https://bugzilla.mozilla.org/show_bug.cgi?id=1069609 [UX] Provide specs 
for desktop layout of date/time inputs

are in the dep tree for that bug, both backlog+, but not being worked on.

Regarding implementation, it seems that the dom/content bits are 
restricted to providing the requisite DOM interfaces so web content can 
ask such an input for the value as a date, set min/max/step attributes 
and have them work, etc. They are preffed off on desktop behind 
dom.experimental_forms, and turned on for b2g and android.

It seems android just implemented a kind of click handler that fired off 
the android date/time picker. It still shows the original plaintext 
input. That shows the date in yyyy-mm-dd format. For desktop, I expect 
we can either do something like for input type="number" and add anon 
content to implement the actual guts of the thing, or do what mobile did 
and "just" add more toolkit-side handling when elements like these are 
focused/clicked on. I don't know how hacky that would be.

It looks like UI-wise, both Edge and Chrome have some kind of UI 
internal to the inputbox (displaying the parts of the date with 
separators in a locale-aware order, and in Chrome's case spinner UI and 
a dropdown arrow) which wouldn't be possible if we went for the android 
approach.

We do also already have a XUL datepicker... I don't know how much UX 
love that would need in order to be usable here (for the picker popup 
which everybody has).

Gijs

On 11/06/2015 20:46, Justin Dolske wrote:
> Is there a description somewhere of how a front-end should implement 
> this? That is, do we need to implement some API or respond to some 
> Gecko notification?
>
> That would probably be a fine first step to helping the bug move 
> along, as it's really unclear from the bug what needs to be done. 
> [Aside: this illustrates a pet peeve of mine -- bugs filed without any 
> context or description.]
>
> I suspect we don't want to write our own datepicker UI from scratch, 
> so the next step would be to figure out if we can use some UI provided 
> by the host OS, or if there are some 3rd party JS libraries that would 
> be a good fit.
>
> This might also be a good opportunity for someone in the community 
> interested in the feature to help implement it, especially if we can 
> help describe the Mozilla-specific scaffolding to get it going.
>
> Justin
>
> On Thu, Jun 11, 2015 at 11:48 AM, Boris Zbarsky <bzbarsky at mit.edu 
> <mailto:bzbarsky at mit.edu>> wrote:
>
>     On 6/11/15 2:38 PM, Kevin Brosnan wrote:
>
>         Firefox backlog is used for frontend (UI work) tracking.
>
>
>     This is a UI bug.  What's needed is for the Firefox frontend to
>     provide UI for these controls, unless you think Gecko should be
>     putting up date pickers itself.
>
>         As a Gecko feature the Firefox team is not the group to fix it.
>
>
>     The Gecko part of this is done.  It works on b2g and Android. 
>     What's needed here is UI on desktop.
>
>     -Boris
>
>     _______________________________________________
>     firefox-dev mailing list
>     firefox-dev at mozilla.org <mailto:firefox-dev at mozilla.org>
>     https://mail.mozilla.org/listinfo/firefox-dev
>
>
>
>
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20150612/5060f84d/attachment.html>


More information about the firefox-dev mailing list