Closed
Bug 773205
Opened 12 years ago
Closed 8 years ago
Implement layout (UI) for date/time input types on Desktop
Categories
(Toolkit :: General, defect)
Toolkit
General
Tracking
()
RESOLVED
DUPLICATE
of bug 888320
People
(Reporter: raphc, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: uiwanted)
Attachments
(1 file)
28.33 KB,
image/png
|
Details |
No description provided.
Reporter | ||
Updated•12 years ago
|
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
Blocks: html5test
Is this a duplicate of bug 446510?
No longer blocks: html5test
Comment 2•12 years ago
|
||
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.
Blocks: 446510
Comment 3•12 years ago
|
||
… 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.
Updated•12 years ago
|
Updated•12 years ago
|
Summary: Implement <input type = date>, and other date/time type layouts → Implement layout (UI) for date/time input types on Desktop
Comment hidden (me-too) |
Comment 5•10 years ago
|
||
(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.
Flags: needinfo?(jboriss)
Keywords: uiwanted
Comment 6•10 years ago
|
||
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
Comment 8•10 years ago
|
||
Philipp, should a separate bug be filed for UX/UI spec work?
Flags: needinfo?(jboriss) → needinfo?(philipp)
Comment 9•10 years ago
|
||
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•10 years ago
|
||
Last I checked, :phlsa works at UI/UX, so yeah, he's the one I wanted to ni?.
Flags: needinfo?(philipp)
Comment 11•10 years ago
|
||
Sorry for bugspam, didn't mean to clear the flag …
Flags: needinfo?(philipp)
Comment 12•10 years ago
|
||
(In reply to Florian Bender from comment #8)
> Philipp, should a separate bug be filed for UX/UI spec work?
Yes please :)
Flags: needinfo?(philipp)
Comment 13•10 years ago
|
||
Thanks for the feedback, putting on todo list …
Flags: needinfo?(fb+mozdev)
Comment 14•10 years ago
|
||
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•10 years ago
|
||
(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•10 years ago
|
||
(In reply to Florian Bender from comment #13)
> Thanks for the feedback, putting on todo list …
Filed bug 1069609
No longer depends on: 1069609
Flags: needinfo?(fb+mozdev)
Comment 17•10 years ago
|
||
(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•10 years ago
|
||
As this potentially affects a majority of users, I believe this may be viable for the backlog.
Sebastian
Flags: firefox-backlog?
Updated•10 years ago
|
Component: Layout → General
Flags: firefox-backlog? → firefox-backlog+
Product: Core → Toolkit
Updated•10 years ago
|
Flags: qe-verify?
Comment 19•10 years ago
|
||
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?
Flags: needinfo?(jwatt)
Comment 20•10 years ago
|
||
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.
Flags: needinfo?(jwatt)
Updated•8 years ago
|
Updated•8 years ago
|
Blocks: platform-ui-team
Updated•8 years ago
|
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•