Fwd: datepicker with multiple monht rows and columns has wrong layout

[Richard D. Worth]

Would be great if someone could take a look into this. Thanks.

- Richard

---------- Forwarded message ----------
From: Jcob <Jaa...@seznam.cz>
Date: Mon, Jan 19, 2009 at 8:05 PM
Subject: jQuery UI bug, google groups down
To: rdw...@gmail.com


Hi.
I wanted to add an issue into UI group discussion on google groups (http://groups.google.com/group/jquery-ui), but i couldnt post my message. So i found out youre the main poster and UI developer, so I'm resending my message to you, maybe somebody will use it, hope you'll know what to do with it.

My original message:
subject: datepicker with multiple monht rows and columns has wrong layout
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
I tried to create a multi-month datepicker for 12 months on the screen (4 columns, 3 rows). But because every month may spread into 4-6 weeks, individual month groups has different height for different months. Therefore when every month group is positioned only by float:left the output could be very messy (there are holes for moths that didnt fit in). You'll get best idea by looking on this screenshot: http://img103.imageshack.us/img103/2041/iedatepickerbugxl5.jpg

I tried to fix it just by adding this line of style into ui.datepicker.css near other group formatting:
.ui-datepicker-multi .ui-datepicker-group-first { clear:both; }

I thought, that this fix should manage to arange the first month of a new line properly and it partly did. But i still got that messy result in IE (used IE 7.0). Other browsers formatting was just fine since this. I didnt find any other solution only by modifying the stylesheets (althought i think there must be some), so i made a bit more radical change in a source code of ui.datepicker.js (used version of jQuery UI: 1.6rc4). I found the part where the last month (datepicker-group) of a line is being closed and added a clearance div. So this is the source code of ui.datepicker.js after update:

ln1400:                         if (drawMonth > 11) {
ln1401:                                 drawMonth = 0;
ln1402:                                 drawYear++;
ln1403:                         }
ln1404:                         var clearer = ((col==numMonths[1]-1)?'<div style="clear:both"></div>' : '');
ln1405:                         calender += '</tbody></table>' + (isMultiMonth ? '</div>' + clearer : '');
ln1406:                         group += calender;
ln1407:                 }

line 1404 is brand new and in line 1405 i added the 'clearer' string right after closing tag of a month group.

This helped and my 12-moths calendar looks just fine in IE7.0, FF3.0 and also in Opera9.23
Maybe you'll find better way to fix this issue, maybe it's solved already in some new beta version, maybe I'll inspire you to clean up this mess made by IE.. Just wanted to let know...

Jaacob

[Ca-Phun Ung]

Wow, looks nasty. I wonder if we could avoid adding that extra clearer div? A more semantic approach to this problem would be to use display:inline-block... in ui.datepicker.css line 28 we have:

.ui-datepicker-multi .ui-datepicker-group { float: left; }

If we change to:

.ui-datepicker-multi .ui-datepicker-group { display: inline-block; }

Our problem is solved for those browsers that support inline-block.

What do you think Filament?

--
Ca-Phun Ung
+ http://yelotofu.com
+ hongkong, zce, jquery, php, css, html

[Maggie Wachs]

We missed this one in our earlier tests, so I'm glad we caught it
now. ;)

It seems the challenge here is making this work in browsers that don't
fully support inline-block, like IE. Ca-Phun, I tried your suggestion
to be sure, but IE just stacks the calendars into a single column. I
also tried clearing the first calendar in each row -- works perfectly
everywhere except IE, which only clears the first calendar, not the
entire row.

I actually like Jaacob's workaround for it's simplicity. Though it
adds a little markup, adding a clearing div bypasses the need to set
equal heights on the calendars or wrap each row in a new div, and it
works across all major browsers. We'd suggest inserting the following
div just before each additional row (not before the first):

<div class="ui-datepicker-row-break"></div>

and we'll take care of adding this class to the framework. Does
anyone have any other ideas before we do this?

-- Maggie

On Jan 28, 2:32 am, Ca-Phun Ung <cap...@yelotofu.com> wrote:
> Wow, looks nasty. I wonder if we could avoid adding that extra clearer div?
> A more semantic approach to this problem would be to use
> display:inline-block... in ui.datepicker.css line 28 we have:
>
> .ui-datepicker-multi .ui-datepicker-group { float: left; }
>
> If we change to:
>
> .ui-datepicker-multi .ui-datepicker-group { display: inline-block; }
>
> Our problem is solved for those browsers that support inline-block.
>
> What do you think Filament?
>

> +http://yelotofu.com

[Ca-Phun Ung]

Actually there is a simple workaround for IE:

.ui-datepicker-multi .ui-datepicker-group { display: inline-block; }
.ui-datepicker-multi .ui-datepicker-group { display: inline; }

IE has some buggy support for inline-block but duplicating the call with display:inline seems to fix the problem. We need to somehow target IE7 and below with this second call without affecting other browsers.

--
Ca-Phun Ung
+ http://yelotofu.com

[ScottJehl]

I think I'd much rather see us insert the div for this situation.
For one thing, it's not an IE problem, it's just that the proposed CSS
Fix would introduce an IE issue and require a hack to work properly.

In general, we've tried hard to keep hacks out of the widget and theme
CSS. I think this is one case where we could easily control the
presentation in generated content by appending this clearing div where
needed.

After all, we're really trying to make up for the fact that we don't
have a proper clearfix wrapper on the row anyway, so the markup weight
is the same.

[Ca-Phun Ung]

On Sat, Jan 31, 2009 at 4:46 AM, ScottJehl <sc...@scottjehl.com> wrote:

I think I'd much rather see us insert the div for this situation.
For one thing, it's not an IE problem, it's just that the proposed CSS
Fix would introduce an IE issue and require a hack to work properly.

I think it is an IE problem. IE does support inline-block but only for elements that are naturally inline. inline-block is ideal for the exact situation we're putting it in here - to present a set of block elements inline creating a tiling effect. Float's on the other hand are the real hacks. inline-block even works when we switch to RTL meaning we can drop the float:right clauses. That said, I understand the clearing div at this moment in time is the most supported cross-browser option so I won't object if we do eventually go that way.
 

In general, we've tried hard to keep hacks out of the widget and theme
CSS. I think this is one case where we could easily control the
presentation in generated content by appending this clearing div where
needed.

Don't get me wrong. I think Filament group have done a superb job. But the clearing div has no semantic meaning. So avoiding it would be good. Again, if it's unavoidable then I have no objections.
 

After all, we're really trying to make up for the fact that we don't
have a proper clearfix wrapper on the row anyway, so the markup weight
is the same.

The markup weight "will" be different. If we add a clearing div we have to add one for each row. We also need to add a CSS class for clearing. If we go the other way it's only a single additional line of CSS + some method of targetting this additional line to IE7 and below.

[Ca-Phun Ung]

Created a ticket for this:

http://dev.jqueryui.com/ticket/4032

I know we're not done with the discussion but as the next release is eminent I didn't want to leave it hanging so have resorted to the clearing div fix for now so at least our users get a working layout, see:

http://dev.jqueryui.com/changeset/1947

I'll be keeping a tab on this one. :)

Thanks!