Tempus-dominus: Question regarding move away from 3.x fixed positioning

Created on 1 Oct 2015 · 4Comments · Source: Eonasdan/tempus-dominus

Would it be possible to add a documentation note about the motivation from moving away from the fixed positioning option in 3.x? There is a use case where the picker is within an overflow hidden or overflow scrollable parent where the 4.x popup become occluded. This was handled in 3.x using fixed positioning. When the popup would appear using fixed position it wouldn't remain in the correct popup location if the parent was scrolled but it would still remain accessible for the user.

https://jsfiddle.net/cmccabe113/tLc9sdcy/

Does 4.x handle the situations shown in the example in a different way?

Source

illudens

Most helpful comment

@Sachin4dotnet, try this:
https://jsfiddle.net/tLc9sdcy/3/
But you need to do something with positioning. Also you can use body as parent (just add position: relative to it).

RomeroMsk on 10 Oct 2015

👍2

All 4 comments

how to resolve this? any solution or trick? My form have overflow : hidden which I can not remove and the calendar is not showing completely..

https://jsfiddle.net/sachin4dotnet/tLc9sdcy/2/

Sachin4dotnet on 10 Oct 2015

❤1

@Sachin4dotnet, try this:
https://jsfiddle.net/tLc9sdcy/3/
But you need to do something with positioning. Also you can use body as parent (just add position: relative to it).

RomeroMsk on 10 Oct 2015

👍2

I have this problem also.

It seems this datetimepicker isn't well suited to any situation where by you might want to place it inside a modal, table, accordion, etc and have one of the parent elements have overflow: hidden. Using widgetParent doesn't really helps as the positioning can be completely off.

jammy-git on 24 May 2016

Hello. Thanks for using my project. We’re closing all tickets/prs for v4 as it is no longer supported. We’re making way for a new version. Please read this blog post