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

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 added a subscriber: hashar.

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,

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.

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 removed a subscriber: gh87.

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.