560590 - "Continue to download -> for BSD" button overlaps search-results page border

Status: VERIFIED FIXED

(addons.mozilla.org Graveyard :: Public Pages, defect)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

STR:

1.  Using Firefox 3.6.3 on Windows 7, load https://preview.addons.mozilla.org/z/en-US/firefox/search/?q=stephend&cat=all&appid=1&lver=any&atype=0&sort=&pid=1&pp=20&lup=&advanced=
2.  Look at the button for "stephen3000!!!!"

Actual Results:

The button overlaps its border

Comment 1

[Craig Cook (:craigcook)]

This happens when button labels are unusually long. The .item-info block has a fixed width as designed, so they all line up neatly in a stack of items. That width is adequate for the majority of buttons, but some long ones like this will run wider. There are possible fixes, but they all have undesirable consequences:

1. We can make the width of .item-info much wider, as wide as the widest possible button. But the majority of cases where buttons are more normal sized will be lost in a sea of whitespace.

2. We can hide the overflow of .item-info. But that will cut off the end of the button. This one would read "Continue to download -> fo"

3. We can rebuild addon-listings so the .item-info block has a liquid width that adjusts to its contents. That will ruin any vertical alignment and make stacks of add-ons look rather untidy.

4. We could completely redesign add-on listings in some totally new layout that avoids all of these problems. But that's a significant undertaking and might be overkill if wide buttons are an edge case.

I'll keep this bug open for now so other folks can weigh in, but I'm recommending "wontfix" and the occasional wide button can overflow as-is. If wide buttons are more common than I think they are, I'll eat my words and we should widen the .addon-info block to accommodate the most common cases.

Unrelated: I'm adding a max-width for images in add-on descriptions, to prevent huge glamorshots of luxury cars from breaking the layout.

Comment 2

[Fred Wenzel [:wenzel]]

Is there a way for us to have the button label line-break? If I use firebug to add a <br> after the arrow, that fixes the problem. (white-space: normal; perhaps?)

There's another reason why I am asking this: L10n. German is wordy (though in the case of our button labels it's not that horrible), and other languages might be even worse. So while long labels are an edge case in English, they might not be elsewhere.

Comment 3

[Jeff Balogh (:jbalogh)]

This button should actually just read "Continue to download ->".  The OS-specific part shouldn't be there.

Comment 4

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #3)
> This button should actually just read "Continue to download ->".  The
> OS-specific part shouldn't be there.

Jeff, you mentioned this yesterday; shall I spin that off as a separate bug?

Comment 5

[Jeff Balogh (:jbalogh)]

(In reply to comment #4)
> (In reply to comment #3)
> > This button should actually just read "Continue to download ->".  The
> > OS-specific part shouldn't be there.
> 
> Jeff, you mentioned this yesterday; shall I spin that off as a separate bug?

Yes please!

Comment 6

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Screenshot, for posterity

Comment 7

[Stephen Donner [:stephend] Not actively reading bugmail]

I spun off comment 4 as bug 561281.

Comment 8

[Craig Cook (:craigcook)]

(In reply to comment #2)
> Is there a way for us to have the button label line-break? If I use firebug to
> add a <br> after the arrow, that fixes the problem. (white-space: normal;
> perhaps?)
> 
> There's another reason why I am asking this: L10n. German is wordy (though in
> the case of our button labels it's not that horrible), and other languages
> might be even worse. So while long labels are an edge case in English, they
> might not be elsewhere.

Allowing (or forcing) the labels to wrap does solve the overflow issue but it has other consequences on presentation and structure. These buttons were designed specifically for a short label on a single line (the rounded ends, the shading, the icon, etc). They've also been constructed and styled with the assumption of non-wrapping labels. So if wrapping button text is a new requirement we'll need to rework the way they're built and styled, hopefully preserving the general appearance.

Wordy localizations is a legitimate concern, of course. If there is a way to see all the localized button variants to know how often they tend to run wide, we can adjust the layout to accommodate the most common scenarios. It may also be more efficient to adjust translations in the name of shorter labels, if necessary. Labels needn't be literal translations of the English, they just need to communicate the same idea. Like using "Go" instead of "Continue." Localizers should be aware of the limited space for buttons and try to find sensible labels that will fit without changing the meaning.

So I still recommend keeping the buttons as designed, with visible overflow on their container, and doing our best to write short labels in all languages. If I'm outvoted I can begin working on making the buttons accommodate wrapping text. We just need to come to a decision.

Comment 9

[Jeff Balogh (:jbalogh)]

Looks like there's a bit of overflow in https://preview.addons.mozilla.org/z/de/firefox/addons/smorgasbord

I turned js off since some of the german strings get replaced with english (they're not localized).

I vote for wontfix to teach these germans a lesson.  Redoing the design to accommodate huge buttons is going to be a lot of work.

Comment 10

[Wil Clouser [:clouserw]]

The only button I see that goes over is "Herunterladen  für Mac OS X" - wenzel, is there different wording we can use here?

Comment 11

[Fred Wenzel [:wenzel]]

Didn't we say that button isn't supposed to have an OS name in it anyway? Without that, does it fit?

Comment 12

[Wil Clouser [:clouserw]]

(In reply to comment #11)
> Didn't we say that button isn't supposed to have an OS name in it anyway?
> Without that, does it fit?

Yes, and that's bug 561281.  Comment 10 was about the link in comment 9.  The French version of this bug is bug 561212, but it looks like that might be fixed with some rewording.

Comment 13

[Fred Wenzel [:wenzel]]

I don't think I can make the text shorter. We could use the somewhat ugly neologism "downloaden" instead of "herunterladen" but that's only 3 characters shorter so I'd rather not do that.

I am fine with wontfixing this bug and fixing bug 561281 instead.

Comment 14

[Wil Clouser [:clouserw]]

Attachment: screenshot for further posterity

Alright, so, this bug as it was originally filed is a dupe of bug 561281.  However, the link in comment 9 shows some additional overlapping trouble which is what this bug should focus on now.

I was all ready to blame this on the Germans and figure out how to change their text, but looking at the English version of the same button, we're still touching the border (see screenshot).  I haven't looked at the other locales, but when languages like Polish start in on their consonants you're usually looking at a double digit word count.

I think we need a button that allows the text to wrap.  Craig, is that something that can be done?

Comment 15

[Craig Cook (:craigcook)]

As of r66522 buttons should now be allowed to wrap when they're too wide for their container. Wrapped buttons look a bit odd and it's still best to avoid it, but at least they're not broken or cut off or spilling over borders or invading their neighbors.

Preview at http://mozilla.focalcurve.com/zamboni/buttons.php

This update does require a span around the button text (only when paired with an icon), which I believe Jeff has already built in so hopefully it won't require any markup changes. We'll want to retest a bunch of pages and locales and button types to see how they look under different conditions. There may be some places where the buttons still go wonky even if they wrap, and we'll tackle those bugs as they're found, but with any luck this will "just work."

Comment 16

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Post-fix screenshot

Comment 17

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED (the screenshot was for comment 10 and comment 15); I've already verified my original comment 0.