Opened 13 years ago
Closed 12 years ago
#3078 closed defect (fixed)
tab labels cutoff text when browser's font size big
| Reported by: | bill | Owned by: | bill |
|---|---|---|---|
| Priority: | high | Milestone: | 0.9beta |
| Component: | Dijit | Version: | 0.9 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: |
Description
If you do Ctrl-+ (Command-+ on the mac), the text for the tab labels starts to get cutoff. Even after refreshing the page, same problem.
Change History (3)
comment:1 Changed 12 years ago by
| Owner: | changed from owen to bill |
|---|
comment:2 Changed 12 years ago by
comment:3 Changed 12 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Yeah, it's unfortunate that the browser doesn't notify us on Ctrl-+/Ctrl--. As for using a table, the problem is that we need to know when sizing changes so that we can resize the TabContainer?'s content (it might be a SplitContainer? or something that needs to size in javascript).
So I'm gonna close this bug as fixed.
Note: See
TracTickets for help on using
tickets.
I've fixed the problem with the button not expanding to fit the tab label. However, there is still a problem with the tab button *area* overlapping the tab container area. This is due to the absolute positioning code in the TabContainer? (or super) class which is determining absolute tops/lefts/whatever for the TabBar? and TabPaneWrapper? pieces. In other words, if you resize the fonts while looking at the page, they're messed up -- but if you reload they get fixed because the layout algorithm runs again. This is not a tundra thing, but rather a conceptual problem with the TabContaner? class. Suggestion: use tables to size the pieces appropriately rather than doing absolute positioning. This may render the widget(s) faster, too, because we won't have to do size calculations. Punting back to Bill.