HTML 5 date/time input field UI on Desktop
gijskruitbosch at gmail.com
Fri Jun 12 16:41:18 UTC 2015
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
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).
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.
> 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.
> firefox-dev mailing list
> firefox-dev at mozilla.org <mailto:firefox-dev at mozilla.org>
> firefox-dev mailing list
> firefox-dev at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the firefox-dev