| Issue 2438: | aspectRatio has no notable effect on calendar dimensions | |
| 1 person starred this issue and may be notified of changes. | Back to list |
After update from fullcalendar 2.0.2 to 2.2.6 aspectRatio appears to have no effect.
No change of code other than version number being pulled from cloudflare, however, calendars no longer adhere to aspectRatio request.
Specifically, housing fullcalendar instance in a 200px width by min 200px height div renders with excess height due to additional padding in following:
.fc tbody .fc-row .fc-content-skeleton tbody tr:last-child td {
padding-bottom: 1em;
}
Previously with aspectRatio: 1, would render with approximate square shape, however it no longer respects aspectRatio: 1, input after 'upgrade' to newer version.
Attempts to force contentHeight also fail due to added padding being enforced on content rows.
Attached 2 caps of same calendar before, and after, changing version (again no other change made between two images other than version number of fullcalendar being loaded from cloudflare).
Feb 9, 2015
Can you a post a jsfiddle of the original problem? aspectRatio should work. Maybe it is not playing well with some other settings you have enabled.
Status:
Reproducing
Labels: Type-Bug
Feb 10, 2015
As best I could replicate in jsfiddle here's the difference: http://jsfiddle.net/swetq8w8/ - 2.0.2 http://jsfiddle.net/hze6db69/ - 2.2.6
Feb 10, 2015
It should be noted that in my environment (maybe font size settings) the calendar doesn't extend outside the horizontal like it is doing in my 2.0.2 fiddle and that, for testing sake, I stripped it down to bare minimum requirements to ensure that I wasn't biasing the results with other CSS or JS elsewhere in my code for the fiddle results. You should be able to see a clear difference between the 2.0.2 and 2.2.6 results in one glance and the only difference between the two fiddles is the version of fullcalendar I loaded to produce it.
Feb 19, 2015
Your problem is that you're including the print stylesheet (fullcalendar.print.css) without specifying media="print" in the <link> tag
Status:
Done
|
|
| ► Sign in to add a comment |
From what I can tell the difference comes down to a simple if/else block that would add the padding in the event that no events were present for the current week's row and not add the padding if there were events to display in that week. I've temporarily worked around the issue with my implementation of the calendar by the following CSS, however this also eliminates any space whatsoever in the bottom displayed week beneath the day numbers: .show_group_calendar_div td { padding-bottom: 0 !important; }