773205 - Implement layout (UI) for date/time input types on Desktop

Status: RESOLVED DUPLICATE of bug 888320

(Toolkit :: General, defect)

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is this a duplicate of bug 446510?

Comment 2

[Mounir Lamouri (:mounir)]

No, I think it's actually a blocker of bug 446510. It's just the layout bug given that the idea is to have the content being done for mobile versions of Gecko and implement later a layout for desktop.

Comment 3

[Florian Bender]

… so this bug should be named something like "implement DOM/Layout for <input […]" and whiteboard "see Bug 446510 for UI implementation". More obvious title = win.

Comment 4

[marco]

Please get this done, are web application uses this and we are forced to tell our users to use Chrome. I just hate doing this.

Please implement it!
Thanks

Comment 5

[Florian Bender]

(In reply to marco from comment #4)
> Please get this done, are web application uses this and we are forced to
> tell our users to use Chrome. I just hate doing this.

Since this is not universally supported in browsers (and of course less so in even slightly older browsers), you should probably implement a widget yourself instead of forcing anyone to use a specific browser. Either way, the input certainly works in every browser, but not every browser provides a picker. 

Either way, this will hopefully be fixed some time soon. 

:Boriss, can you please check if this needs a spec and escalate if necessary? I don't know who to ping on this.

Comment 6

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: Date and Timepicker UI in Lightning

Regarding the UI, maybe it makes sense to look into the date/timepickers of the Mozilla Calendar Project. I have attached a screenshot of the datepicker and timepicker UI we currently use in product. In the date picker, the < o > buttons are for previous month, go to today, next month. There is a yellow selection box for the currently selected day, and a blue box for "today". In the screenshot, "today" is selected so you will only see one box.

Aside from the UI used in the product, there are some unimplemented mockups containing a month picker from one of our former designer here: <https://wiki.mozilla.org/Calendar:Calendar_View>. There are also some alternative timepicker suggestions on bug 275253.

Then of course there is the XUL date/timepicker which is rather simplistic, but keeps it simple.

Comment 7

[marco]

Sorry to stress, but I see this ticket is assigned to no one.  Considering the ticket started on 2012-07-12 , should I just accept the idea that Firefox will not support this for an important-future time? I'm asking because we (as a company) need to get some important decisions on how we are implementing our software and eventually do all the needed considerations (like system requirements ecc)
Thanks

Comment 8

[Florian Bender]

Philipp, should a separate bug be filed for UX/UI spec work?

Comment 9

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Are you sure you got the right philipp in that needinfo request? If you meant me, I can't comment on how the bugs should be filed for this as I don't work on any Firefox features. I am working on the Mozilla Calendar Project (the Lightning extension).

Comment 10

[Florian Bender]

Last I checked, :phlsa works at UI/UX, so yeah, he's the one I wanted to ni?.

Comment 11

[Florian Bender]

Sorry for bugspam, didn't mean to clear the flag …

Comment 12

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

(In reply to Florian Bender from comment #8)
> Philipp, should a separate bug be filed for UX/UI spec work?

Yes please :)

Comment 13

[Florian Bender]

Thanks for the feedback, putting on todo list …

Comment 14

[pdiprogrammers]

Is there any progress with this bug? Is it safe to assume this bug will not be looked at for a while as it appeared in 2012?

Comment 15

[Sebastian Zartner [:sebo]]

(In reply to Philipp Sackl [:phlsa] from comment #12)
> (In reply to Florian Bender from comment #8)
> > Philipp, should a separate bug be filed for UX/UI spec work?
> 
> Yes please :)

So Florian, could you please file that bug?

Also to finally make progress on this issue I suggest to split the work into smaller parts. E.g. one issue for each input type, that is 'date', 'month', 'week', 'time', 'datetime' and 'datetime-local'.

Sebastian

Comment 16

[Tim Nguyen :ntim]

(In reply to Florian Bender from comment #13)
> Thanks for the feedback, putting on todo list …

Filed bug 1069609

Comment 17

[Florian Bender]

(In reply to Tim Nguyen [:ntim] from comment #16)
> (In reply to Florian Bender from comment #13)
> > Thanks for the feedback, putting on todo list …
> 
> Filed bug 1069609

Sorry, this slipped of my radar … thanks for filing!

Comment 18

[Sebastian Zartner [:sebo]]

As this potentially affects a majority of users, I believe this may be viable for the backlog.

Sebastian

Comment 19

[Florian Bender]

Though this is blocked on Bug 1069609, the bug can already be worked on (with a dummy UI – or none at all) and (partially) landed (pref-ed off). 

Jonathan, since you implemented input[type=number], would you be able to mentor this bug, or know someone who can?

Comment 20

[Jonathan Watt [:jwatt]]

That would require a time commitment that I don't feel I can make right now. Before we can even start on this I think we should answer the question of how we're going to allow author styling of controls such as range/number in a cross-browser, and I don't think we're remotely close on that.