v5: Move from widget to modal

[Eonasdan]

Currently, the picker is an a Bootstrap drowndown menu widget. While this works in most cases, it does strange things with positioning and is restrictive in that the element the picker is attached to must have position: relative.

A v5 change could move away from this method to the much more flexible modal style popup. Since the BS modal's are responsive, the picker would take up the right amount of space and would likely be more mobile friendly.

The cost might be that the UX will be different from how other inputs work.

There are three paths here:

1. Leave it
2. Use a BS modal window for the popup. By this, I mean that the picker will place the html inside of the modal-body
3. A custom modal window. This would be the similar to option 2 except that the picker won't be in the bootstrap modal with the header, footer and white box.

Example of the modal window

Please leave a comment with your opinion and a reason why.

[PaitoAnderson]

1. Leave it.

We currently use this datetime picker in a good sized enterprise application, and haven't had any positioning issues reported, I think moving to a BS modal window could disrupt/slow down traditional mouse and keyboard user input if loaded on top of the page.

[jeremyVignelles]

Not decided yet, maybe an option like "keep both and make options", because each use case is different.

Just a question : If I have a field without button, and I want to click on it to edit the text directly, what would be the behaviour? Opening a window can be frustrating in that case, and may break tab navigation : the picker should be a way to help the user to write the content, but should not be mandatory.

[Eonasdan]

@jeremyVignelles without the button might be an issue. One of the goals of v5 is to remove the input dependency. It will still work with an input and without a button.

I'm not talking about opening a browser window/tab or a popup. I'm talking about a modal window. No navigation.

[RomeroMsk]

With 2 variant you will need to solve a problem of "modal over modal" when datepicker is called from modal. There is a hack to solve this, but you need to know about this ;)

[bertoost]

I like the modal idea, but not yet any need for this. Internet users are so used to datepickers to appear below or near the field. And together with a Bootstrap input-group with a calendar icon, it's even better :-)

[jeremyVignelles]

@Eonasdan I don't think removing the input dependency is a good idea, semantically speaking. The input should be there to store the form data, even if it is an <input type="hidden" />. But I'm okay to have the ability to have a picker without any input visible, that's what inline is for, right? One could wrap this inline into a dropdown on a button.

I know it isn't a browser tab, I was talking about the tab key that is used to navigate between form inputs. Sorry for the misunderstanding.

[hackel]

I like the modal window concept, but I find that there's too much mouse movement required after clicking to the centre of the window. Is there a way we can make the modal pop up right under where it was clicked? I'm thinking the window could be opened such that it's centre is wherever the user clicked, or shifted as needed if near to a window edge.

(I also would love it if it could have a Material Design look to it as that example seemed to, but I don't think that's what you were getting at!)

[chrylis]

I would prefer (1), largely because of the modal-on-modal issue.

[DePalmo]

I vote for option 4. Implement modal window and offer it as an option. Right now I'm dealing with integration of datetime picker into modal window and if having this as an option, that would be superb! Also others have pointed out, modal-on-modal does not work so it would be up to developer to decide if widget should appear in modal window or not.

[KienLP]

1. Leave it.
   I agree with @PaitoAnderson, moreover, the modal isn't friendly in enterprise application, it can't change the date & time values manually.

[gabn88]

1. Leave it for the same reason as @KienLP. I choose for this datetimepicker because it works ánd on mobile, ánd on desktops (quickly insert date by typing, or viewing the monthly overview for selecting a date by clicking).