Opened 13 years ago

Closed 13 years ago

#1528 closed defect (invalid)

dynamic sizing of datepicker based on translations

Reported by: Adam Peller Owned by: Adam Peller
Priority: low Milestone: 0.9
Component: Widgets Version: 0.3
Keywords: datepicker i18n Cc: tk
Blocked By: Blocking:

Description

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

Attachments (1)

datepicker-layout.patch (5.1 KB) - added by Adam Peller 13 years ago.
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

Download all attachments as: .zip

Change History (6)

Changed 13 years ago by Adam Peller

Attachment: datepicker-layout.patch added

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

comment:1 Changed 13 years ago by tk

Cc: tk added

Which browser still needs a hack for this?

comment:2 Changed 13 years ago by 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.

comment:3 Changed 13 years ago by 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.

comment:4 Changed 13 years ago by 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?

comment:5 Changed 13 years ago by bill

Resolution: invalid
Status: newclosed

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.

Note: See TracTickets for help on using tickets.