Page MenuHomePhabricator

Consolidate MediaWiki core's date and time input widgets; consider moving (one of?) them upstream
Open, LowPublic


Note this task was originally about creating a date and time input widget. Then two were created, mw.widgets.DateInputWidget and mw.widgets.datetime.DateTimeInputWidget, and this task was repurposed as "combine those two widgets". See T91148#1932034 for the most recent summary of the state of the two widgets.

We would need OOUI widgets similar to:

  • <input type="date">
  • <input type="time">
  • <input type="datetime-local">

While these can be made with code like:

new OO.ui.TextInputWidget( { type: 'datetime-local' } )

Browser support is somewhat lacking:

Browser Support?
 IE No
Edge Yes
Firefox Yes (v57)
Chrome Yes (v31)
Safari No
Opera Yes

See Also:

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Jdforrester-WMF triaged this task as High priority.May 4 2015, 6:09 PM
Jdforrester-WMF moved this task from Backlog to Next-up on the OOUI board.
Ltrlg added a subscriber: Ltrlg.May 25 2015, 3:30 PM

Change 216909 had a related patch set uploaded (by Anomie):
Date and time picker widget

Jdforrester-WMF moved this task from Next-up to Doing on the OOUI board.
Jdforrester-WMF set Security to None.
bd808 changed the task status from Open to Stalled.Aug 18 2015, 5:10 PM
bd808 added a subscriber: bd808.

@matmarex objects to @Anomie's implementation. We need to figure out how to resolve this. Just having a data picker is not sufficient for the needs of ApiSandbox.

hashar updated the task description. (Show Details)Sep 17 2015, 3:33 PM
hashar added a subscriber: hashar.
Ltrlg updated the task description. (Show Details)Sep 18 2015, 8:06 AM
Nemo_bis added a subscriber: Nemo_bis.
hashar removed a subscriber: hashar.Oct 1 2015, 11:18 AM
dr0ptp4kt moved this task from Backlog to Next Up on the Reading-Admin board.

Change 216909 abandoned by Anomie:
Date and time picker widget

Since OOJS-UI isn't currently in a position to accept this, Ia3942c76804c865c1039904d170ee6eafcdc6793.

Sooo... we now have the two in MediaWiki core.

Unfortunately they have almost no common code :/

Wondering who should weigh in on this to move this forward?

Wondering who should weigh in on this to move this forward?

Not sure about "who", but I can look at what needs to be weighed in on.

Regarding two similar-but-different widgets, someone would have to analyze the differences between the two and decide which approaches to use. Then someone would have to write code to implement the decisions in one widget. Off the top of my head,

  • DateInputWidget doesn't handle times, while DateTimeInputWidget does. Time input is required for T92893.
  • DateInputWidget takes input as a single textbox, changes the format displayed when focused/unfocused, and only accepts input in YYYY-MM-DD style. DateTimeInputWidget takes input as individual date components and does not change format when focused.
  • DateInputWidget uses its own i18n mechanism (from moment.js), while DateTimeInputWidget uses MediaWiki's standard i18n.
  • DateInputWidget looks like it can only handle the Gregorian calendar. DateTimeInputWidget is designed to easily support other calendars if someone writes the code for converting a JavaScript Date into that calendar's components.
  • DateInputWidget's calendar has the cool "up arrow" feature, and supports selecting a year+month with no day more sensibly.

Regarding the fact that neither of these are in oojs-ui,

Anomie removed Anomie as the assignee of this task.Jan 13 2016, 7:14 PM

Thanks @Anomie, I was going to write pretty much the same thing. We need an experienced frontend developer to make decisions on the parts that Anomie and I disagree on, and preferably also implement them (although I guess one of us could do it in the end). Both versions implement a very similar design, close to M53, with some small differences (primarily the input field behavior). I'm not sure who we could escalate this to :/

From the library users' perspective, the issue is pretty much resolved, and both DateTimeInputWidget and DateInputWidget (with the differences described by Anomie) are available to be used. The public interface shouldn't change (I think at the very least, you can rely on #getValue/#setValue methods continuing to behave in the same way they do now).

Design feedback wouldn't hurt (never does ;) ), but I think we're fairly solid here, and at the moment any changes would have to be implemented in both versions (which would be a pain). Gotta set up a demo/comparison of the two again…

integrate moment.js and use its i18n

That would be blocked on their adopting a standard shared with MediaWiki core, see .

Got it. It will be good to frame the use cases around date and time input widget to make sure we're making some informed decisions, otherwise it'll be hard to decide what should stay and what shouldn't based on your implementations. I don't mind doing this.

Jdforrester-WMF renamed this task from Date and time input widgets to Consolidate MediaWiki core's date and time input widgets; consider moving (one of?) them upstream.Mar 2 2016, 1:58 AM
Jdforrester-WMF changed the task status from Stalled to Open.
Jdforrester-WMF lowered the priority of this task from High to Low.
Jdforrester-WMF moved this task from Doing to Backlog on the OOUI board.
dr0ptp4kt moved this task from Next Up to Waiting on the Reading-Admin board.Mar 14 2016, 9:44 PM
Danny_B moved this task from Unsorted to OOUI on the UI-Standardization board.May 20 2016, 9:01 PM
Aklapper updated the task description. (Show Details)Feb 1 2017, 12:35 PM
Anomie updated the task description. (Show Details)Jun 5 2017, 1:54 PM

The English Wikipedia community is complaining about having to use 2 different date selection widgets and agrees that we should consolidate on one.

FWIW, I think the DateInputWidget is better for just choosing dates (mainly due to T170607). How hard would it be to add an optional time input interface to it?

gh87 added a subscriber: gh87.Aug 15 2017, 11:19 PM
gh87 removed a subscriber: gh87.
He7d3r added a subscriber: He7d3r.Oct 28 2017, 3:11 PM
dbarratt updated the task description. (Show Details)Nov 14 2017, 5:49 PM
Aklapper updated the task description. (Show Details)Dec 15 2017, 9:59 AM
Volker_E updated the task description. (Show Details)Feb 8 2018, 10:07 PM
dr0ptp4kt moved this task from Waiting to Tracking on the Reading-Admin board.Mar 13 2018, 10:48 PM
Volker_E updated the task description. (Show Details)May 29 2019, 10:04 PM
Volker_E removed subscribers: werdna, TrevorParscal.

After revisiting the two widgets in several contexts, I think the DateTimeInputWidget is only usefully crafted for one special use case, APISandbox. It fulfills the needs there, but is generally too complex on a user experience and component level.
It seems more performant, less complex and also general better approach to have two different components, a DateInputWidget and a TimeInputWidget for those two tasks. No other web framework is providing a combination for the complexity of mixed inputs, Boostrap has none, Material Design only Date picker.

The only implementations are by developers on top of other libraries, that show the unnecessary complexity of those time pickers:

This goes alongside the most recent comments above.

D3r1ck01 added a subscriber: D3r1ck01.