Closed Bug 126611 Opened 23 years ago Closed 22 years ago

[RFE] Pref for shrink-to-fit title (rightsized) tabs

Categories

(SeaMonkey :: Tabbed Browser, enhancement)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: david, Assigned: jag+mozilla)

Details

I often browse with several tabs open, but not enough horizontal space for them.
It would be nice if tabs with short captions made themselves smaller, so there
would be more space for other tabs with longer captions. Example with 3 open tabs:

curent:

/--------------------\/--------------------\/--------------------\
| Tab with very l...|| Short              || Short              |
/                    \/                    \/                    \

my suggetion: 

/-------------------------\/-------\/-------\
| Tab with very long text || Short || Short |
/                         \/       \/       \
The equal width of tabs is a feature, see bug 101796
Fine, but I would like to see it at least as an option (in Preferences dialog 
or hidden in prefs.js). I think it souldn't be so difficult to do. 
I would like the possibility of manually resizing tabs.
I don't agree. Muscle memory is very important, and I expect to find the tabs
always in the same place. If I have 3 tabs, I can click left, middle and right,
and I'm sure that it will hit the correct tab without really looking for it. In
your example, I can't know where the middle tab can be found for instance.

I know that the tabs will become smaller when you add more of them, but that's
another matter, because it requires an action on your part.

Like Brant, I would also support the possibility to enlarge or shrink a tab on
demand, so you can see your large title if you want. Or you make it deliberately
smaller, to make room for the others. But this is also a action on your part.
> Like Brant, I would also support the possibility to enlarge or shrink a tab on
> demand, so you can see your large title if you want.

You can see the full title in a tooltip when you hover over the tab, changing
tab widths manually seems terribly superfluous a feature to me, one that would
get in the way more often than be useful.

As for automatic resizing, if you read bug 101796, it was removed because it
makes the tabs move about during page loads as the titles update, which isn't
all that nice.
Hmm, didn't spot a bug for this pref.
Summary: [RFE] Tabs should be smaller when text on them is short → [RFE] Pref for shrink-to-fit title (rightsized) tabs
I don't know how Galeon handles the bug 101796 problem, but he result is good -
see a screenshot of the result at <http://www.robval.com/linux/2002/gal1n.gif>.
Just an observation here - and a possible "fix" if we're only looking at a small
number of tabs.

It's not technically accurate to say, as per the wording of bug 101796, that
tabs have a static width.  As you add more and more tags, their width will
shrink so that all can equally fit horizontally on the tab bar.  Therefore, the
technically correct thing to say about tabs is that they all have the *same* width.

However, I've often thought it a little strange that there is a maximum width
assigned to tabs.  In other words, my natural assumption would be to see a
single tab filling the entire available width of the tab bar.  When I add a
second tab, each fills up half of the available width, etc.  I'm not sure why
this "divide the tab bar by the number of tabs" should *only* start to take
affect once after you have enough tabs whose maximum width totals the available
space.

Looking at the example as described in the description of this bug - if there
were no maximum tab width (other than the tab bar width itself), it might make
the title of the first tab wholely visible.
Confirming as RFE to get it off the UNCONF radar.
Voting for WONTFIX.
Status: UNCONFIRMED → NEW
Ever confirmed: true
WONTFIX. We have too many prefs, and are not adding more. The behaviour is the
intentional behaviour. (You can probably override it using either your own skin
or using userChrome.css, btw. Exactly how is left as an excercise to the reader.)
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
I don't think there should be a preference for this variable tab-width
behaviour, I think it should be the across-the-board default.

I'm actually quite surprised that this behaviour used to exist, but was changed,
it seems a definite step backwards. 

Imagine that you were using some other app, and opened some dialog box with
multiple tabs. Some short tabs labels had all the label text showing with lots
of white space, and others had the first few words and then were truncated with
ellipses so that you couldn't read all of what they said. 

Perhaps imagine that you were trying to get some techo-illiterate relatives to
use this same dialog box. [telling someone like that they can get the full tab
name by hovering over each and every truncated tab is a poor workaround at best] 

Would you really feel that this was a good UI, or a bad UI ? Would you think
this was a polished interface, or not? Would you think this interface was as
clear as it could be? And if you do think it's clear, why isn't every
multi-tabbed dialog box in existence using this paradigm?

How's Mozilla fundamentally dissimilar from this? I don't think it is, and I
don't think it's any clearer or easier to use for it. What's more, as more tabs
are loaded, under the current scheme the tab titles just get shorter and shorter
and the problem of working out that any given tab is actually displaying just
gets worse and worse.

Is there a UI testing group of some kind associated with Mozilla? Something
where they get people off-the-street, and sit them in front of a computer, and
ask they what they think? If so, I'd be very interested to see how a ordinary
people rated these two different interfaces, especially as the number of tabs
scaled up.

Saying that something is the "intentional behaviour" is not an explanation or
justification as to why exactly it should be the intentional behaviour.
Furthermore, the argument that it can be overridden cuts both ways. 

I'm also at a loss as to how this forced-equal-tab-width-approach is compatible
with bug 155325 , which seeks to provide some kind of overflow mechanism when
there are too many tabs. Currently it's using a fixed approach of overflowing
when there are 10 tabs, where 10 is just some magical fixed number that
hopefully works OK for most of the people most of the time. Madness! The correct
approach is to have variable tab widths, and then you actually know (as opposed
to guessing) when you need to overflow - when all the available space is used,
of course!

I'm quite surprised at the chorus of dissent against this interface. The only
real argument that I can see against variable width tabs is that the width can
change when the tab is loading (and the title is being fetched), which was the
reason behind bug 101796. It's a valid problem with this approach (in particular
when loading a group of bookmarks), but it's a temporary problem restricted to
when things are loading, whereas the current behaviour is somewhat annoying
_all_ the time.
> Perhaps imagine that you were trying to get some techo-illiterate relatives to
> use this same dialog box. [telling someone like that they can get the full tab
> name by hovering over each and every truncated tab is a poor workaround at best]
ooh fun. let's try the real world for a moment.  my parents gave me a filing
cabinet and tabbed folders to fill it.
1. i'm really upset, the folder tab size is fixed, it doesn't grow or shrink
when i add letters to the tabs, how can this be?
2. if i actually need to fit more text onto a tab, i have to use tape or
something in which case the text is out of sight until i reach for the tab and
pull the tape lengthwise until i can read it. surprisingly this matches hovering
over a tab to get a tooltip. 

beyond that, your comments and questions belong in a newsgroup. perhaps npm.ui
> my parents gave me a filing cabinet and tabbed folders to fill it.

Rather faulty analogy, surely. The company that manufactures the physical tabs
has no idea what or how much is going to be written on them. They could make a
variety of tab lengths, and let the user pick the appropriate sized one for a
folder, but that would increase costs and price, which people probably aren't
prepared to pay, so they make one standard width tab instead.

That's not true for Mozilla - it knows the length of the title, and can
consequently display the appropriate tab length. The fact that this used to be
the behaviour proves that it can be done (and presumably quite easily, by
reversing the previous patch).

The correct question to ask is whether you'd be happier with:
a) A standard filing cabinet with fixed tab widths where you have to muck around
with tape as you describe
b) A filing cabinet that automatically resized tabs dependent on what you wrote,
and that cost the same as a standard filing cabinet

I know which I'd rather have.
mass-verifying Wontfix bugs.

mail filter string for bugspam: Tursiopstruncatus
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.