Closed Bug 773205 Opened 9 years ago Closed 5 years ago
Implement layout (UI) for date/time input types on Desktop
No description provided.
OS: Linux → All
Hardware: x86_64 → All
Summary: Implement Minput type = date, and other date/time type layouts → Implement <input type = date>, and other date/time type layouts
Is this a duplicate of bug 446510?
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.
… 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.
Summary: Implement <input type = date>, and other date/time type layouts → Implement layout (UI) for date/time input types on Desktop
(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.
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.
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
Philipp, should a separate bug be filed for UX/UI spec work?
Flags: needinfo?(jboriss) → needinfo?(philipp)
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).
Last I checked, :phlsa works at UI/UX, so yeah, he's the one I wanted to ni?.
Sorry for bugspam, didn't mean to clear the flag …
(In reply to Florian Bender from comment #8) > Philipp, should a separate bug be filed for UX/UI spec work? Yes please :)
Thanks for the feedback, putting on todo list …
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?
(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
(In reply to Florian Bender from comment #13) > Thanks for the feedback, putting on todo list … Filed bug 1069609
(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!
As this potentially affects a majority of users, I believe this may be viable for the backlog. Sebastian
Component: Layout → General
Flags: firefox-backlog? → firefox-backlog+
Product: Core → Toolkit
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?
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.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: datetime
You need to log in before you can comment on or make changes to this bug.