dynamic sizing of datepicker based on translations

[Adam Peller]

resize the datepicker widget according to two width constraints: the year strings and the widest month also, set the width of the month label according to the widest month

[Adam Peller]

remove static sizes in CSS and size the month label according to the widest month. Not complete: needs a browser-specific hack, and the month name is not centered

[tk]

Which browser still needs a hack for this?

[Adam Peller]

All browsers. The issue is that the month name could be any length, and we don't even know what fonts or styling will be used.

The measuring hack needs to be used sparingly. It's extremely expensive. Perhaps this is appropriate, though, and it's only for layout of an inner div, not the whole widget. One alternative is to include pixel measurements for the localized strings or try to guess, but that's really a kludge and won't always work. I suppose the other alternative is to redesign the widget so we don't require the up/down month buttons to stay in the same place.

#1644 is related, as we need to avoid fixed measurements for the enclosing widget if we are to be flexible at all for localized strings.

[bill]

Adam and I talked about this after he wrote the previous comment; I asked him (or actually tk) to give up javascript sizing, and instead try to have the datepicker size dynamically by just using a table. The fear is that the datepicker's width will change as you move from month to month, but that shouldn't happen much or at all, since month names in most/all languages are shorter than the width of the a 7 column table w/two digit numbers.

[tk]

Then this should be closed "Not Valid" or "Wont Fix"... I'm sorry, I dont remember having that conversation otherwise I Would have closed this back then... Should we call it invalid or wont fix?

[bill]

Sorry, I should have said that I talked with Adam but he was going to ask Karl to make the change. I'll close this bug and write more comments in #1644.