Closed Bug 583231 Opened 14 years ago Closed 12 years ago

Menu buttons are using the wrong size icon

Categories

(Firefox :: Theme, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mkaply, Unassigned)

References

Details

Attachments

(2 files)

Attaching a screenshot of my toolbar in large and small icon mode.

In small icon mode, the menu-button icons are too big.

In large icon mode, the menu-button icons are too small.

The PNGs for the Amazon and ebay button are the same size in my addon.
Dão, do you have a plan for this problem? Are we going to require add-on authors to size all their icons to 20x20?
(In reply to comment #1)
> Dão, do you have a plan for this problem? Are we going to require add-on
> authors to size all their icons to 20x20?

I sure hope not. This would be a major breaking change for every addon.
(In reply to comment #1)
> Dão, do you have a plan for this problem? Are we going to require add-on
> authors to size all their icons to 20x20?

No, as we want a visual size of 16x16 for built-in icons as well as third-party icons, except that built-in icons have a padding. On Windows I made sure that the padding doesn't exceed 1px so that third-party icons are stretched to 18x18 (still bad, but not as bad as the current pinstripe) and don't touch the button border. Can the size of pinstripe's icons be reduced similarly?
> On Windows I made sure that the padding doesn't exceed 1px so that third-party icons are stretched to 18x18 (still bad, but not as bad as the current pinstripe)

Are you saying that the default icon sizes for addons are not 16x16 for small and 24x24 large anymore?
Please make sure that icons are still 16x16 and 24x24, and not scaled. Getting new icons is expensive and requires involvement of the graphics department of whoever company created the toolbar. Scaling is bad both for performance and visual quality, most companies are really careful about the latter and want to control every pixel, so scaling won't fly.
Is this the same bug as bug 547419 that has a patch that is waiting review?
(In reply to comment #4)
> Are you saying that the default icon sizes for addons are not 16x16 for small
> and 24x24 large anymore?

Yes and no. The icon size depends on the theme you're using. (Which means that scaling is necessarily going to happen.) You shouldn't feel encouraged to reduce the size of your add-on icons.
(In reply to comment #7)
> (In reply to comment #4)
> > Are you saying that the default icon sizes for addons are not 16x16 for small
> > and 24x24 large anymore?
> 
> Yes and no. The icon size depends on the theme you're using. (Which means that
> scaling is necessarily going to happen.) You shouldn't feel encouraged to
> reduce the size of your add-on icons.

And it's different between Windows/Mac/Linux? So addons won't look the same on different platforms?

That's totally unacceptable.
(In reply to comment #6)
> Is this the same bug as bug 547419 that has a patch that is waiting review?

That patch is Windows only. On Mac it would appear that there is no visual distinction visually between small and non small icons in the navigation UI (no changes at all when you check or uncheck the box in customize toolbar)

In an addon, while small and large use two different icons, the small are scaled up to 20x20 and the large are scaled down to 20x20.
(In reply to comment #3)
> (In reply to comment #1)
> > Dão, do you have a plan for this problem? Are we going to require add-on
> > authors to size all their icons to 20x20?
> 
> No, as we want a visual size of 16x16 for built-in icons as well as third-party
> icons, except that built-in icons have a padding. On Windows I made sure that
> the padding doesn't exceed 1px so that third-party icons are stretched to 18x18
> (still bad, but not as bad as the current pinstripe) and don't touch the button
> border. Can the size of pinstripe's icons be reduced similarly?

Maybe it could, but with the patch in bug 547419 it wouldn't matter, right?

(In reply to comment #7)
> (In reply to comment #4)
> > Are you saying that the default icon sizes for addons are not 16x16 for small
> > and 24x24 large anymore?
> 
> Yes and no. The icon size depends on the theme you're using. (Which means that
> scaling is necessarily going to happen.)

Can you be a little more specific? I think at the moment it works like this:

Windows: all icons scaled to 18px
Mac: all icons scaled to 20px
Linux / 3rd party themes: whatever was the case in Firefox 3.6

And with bug 547419 and a similar fix for Mac we can at least make it work like this:

Windows & Mac: small icons at 16px, large icons scaled to 20px
(In reply to comment #10)
> > No, as we want a visual size of 16x16 for built-in icons as well as third-party
> > icons, except that built-in icons have a padding. On Windows I made sure that
> > the padding doesn't exceed 1px so that third-party icons are stretched to 18x18
> > (still bad, but not as bad as the current pinstripe) and don't touch the button
> > border. Can the size of pinstripe's icons be reduced similarly?
> 
> Maybe it could, but with the patch in bug 547419 it wouldn't matter, right?

Yeah, but that patch is pretty ugly, I can see why it's not reviewed yet.

> > > Are you saying that the default icon sizes for addons are not 16x16 for small
> > > and 24x24 large anymore?
> > 
> > Yes and no. The icon size depends on the theme you're using. (Which means that
> > scaling is necessarily going to happen.)
> 
> Can you be a little more specific? I think at the moment it works like this:
> 
> Windows: all icons scaled to 18px
> Mac: all icons scaled to 20px
> Linux / 3rd party themes: whatever was the case in Firefox 3.6
> 
> And with bug 547419 and a similar fix for Mac we can at least make it work like
> this:
> 
> Windows & Mac: small icons at 16px, large icons scaled to 20px

Large icons would be 18px at least on Windows. Anyway, I'm not sure how being more specific like this helps in the given context. I certainly don't want to create the impression that 16 and 18 would be the new standard sizes that everybody should move to just because this happens to be the Windows and Mac default theme choice.
(In reply to comment #11)
> I certainly don't want to
> create the impression that 16 and 18 would be the new standard sizes that
> everybody should move to just because this happens to be the Windows and Mac
> default theme choice.

Huh? How do you define "standard sizes" if not by what's being enforced by the Windows default theme?

The way I see it, we're looking for a solution that can satisfy these goals:
 - maximal consistency across platforms
 - Don't make existing add-ons' icons look hideous.
 - It must be possible (and ideally easy) for an addon to have buttons that look good (and crisp, i.e. no scaling) on all platforms with both icon sizes.
>  - Don't make existing add-ons' icons look hideous.

This is impossible if you introduce ANY scaling. You can't do scaling of very small images and ever expect them to look good.

The only way this is going to work is if you reuse the already existing sizes of 16x16 and 24x24.

You guys are missing the bigger picture here.

The 16x16 and 24x24 icons that people have in their addons are not necessarily things that were just thrown together. Art departments and artists were involved, lots of work was done to get those images looking exactly how they wanted them to look at 16x16 and 24x24.

If you choose to resize them, you're destroying the image. Period.

As far as I'm concerned, this bug is actually a bigger deal than any of the other add-on issues that have come up in the Firefox 4 process. All of the other problems could be solved by an add-on developer.

This one can't. (unless that developer happens to have done their icon.)

Please stop this. Use the existing 16x16 and 24x24 icons for all add-on toolbars.

Worst case, get rid of the concept of large icons entirely and just use 16x16 everywhere.

But please don't scale icons.
(In reply to comment #12)
> > I certainly don't want to
> > create the impression that 16 and 18 would be the new standard sizes that
> > everybody should move to just because this happens to be the Windows and Mac
> > default theme choice.
> 
> Huh? How do you define "standard sizes" if not by what's being enforced by the
> Windows default theme?

There's just no standard size at all. We explicitly want to support themes with an icon size choice different from the Win default theme. Since downscaling is better than upscaling, add-on authors should stick with 16 / 24.

> The way I see it, we're looking for a solution that can satisfy these goals:
>  - maximal consistency across platforms

This isn't a goal.

>  - Don't make existing add-ons' icons look hideous.
>  - It must be possible (and ideally easy) for an addon to have buttons that
> look good (and crisp, i.e. no scaling) on all platforms with both icon sizes.

Once SVG is available, this will be an option for add-on authors. Other than that, you'd have to invest in establishing a new API to make the last point happen.
(In reply to comment #14)
> (In reply to comment #12)
> > > I certainly don't want to
> > > create the impression that 16 and 18 would be the new standard sizes that
> > > everybody should move to just because this happens to be the Windows and Mac
> > > default theme choice.
> > 
> > Huh? How do you define "standard sizes" if not by what's being enforced by the
> > Windows default theme?
> 
> There's just no standard size at all. We explicitly want to support themes with
> an icon size choice different from the Win default theme. Since downscaling is
> better than upscaling, add-on authors should stick with 16 / 24.
> 
> > The way I see it, we're looking for a solution that can satisfy these goals:
> >  - maximal consistency across platforms
> 
> This isn't a goal.

What should Add-on authors do, then? Create a separate icon for every platform?

> 
> >  - Don't make existing add-ons' icons look hideous.
> >  - It must be possible (and ideally easy) for an addon to have buttons that
> > look good (and crisp, i.e. no scaling) on all platforms with both icon sizes.
> 
> Once SVG is available, this will be an option for add-on authors. Other than
> that, you'd have to invest in establishing a new API to make the last point
> happen.

Good, let's do that.
(In reply to comment #15)
> > There's just no standard size at all. We explicitly want to support themes with
> > an icon size choice different from the Win default theme. Since downscaling is
> > better than upscaling, add-on authors should stick with 16 / 24.
> > 
> > > The way I see it, we're looking for a solution that can satisfy these goals:
> > >  - maximal consistency across platforms
> > 
> > This isn't a goal.
> 
> What should Add-on authors do, then? Create a separate icon for every platform?

No, a platform -> theme -> icon size mapping isn't going to be solid. They should stick with 16 / 24 for the time being.

> > Once SVG is available, this will be an option for add-on authors. Other than
> > that, you'd have to invest in establishing a new API to make the last point
> > happen.
> 
> Good, let's do that.

I take it you just signed up for this? :)
(In reply to comment #16)
> > > Once SVG is available, this will be an option for add-on authors. Other than
> > > that, you'd have to invest in establishing a new API to make the last point
> > > happen.
> > 
> > Good, let's do that.
> 
> I take it you just signed up for this? :)

OK, I'll try to make it happen.

(In reply to comment #13)
> >  - Don't make existing add-ons' icons look hideous.
> 
> This is impossible if you introduce ANY scaling. You can't do scaling of very
> small images and ever expect them to look good.
> 
> The only way this is going to work is if you reuse the already existing sizes
> of 16x16 and 24x24.

24px icons just don't fit into the new buttons. Looks like we're not going to hit this goal completely.

> Please stop this. Use the existing 16x16 and 24x24 icons for all add-on
> toolbars.

Wait - are you only talking about icons in an add-on's own toolbar, and not about toolbar buttons in, say, the main navigation toolbar?

> Worst case, get rid of the concept of large icons entirely and just use 16x16
> everywhere.

So... about the small icon / large icon switch: In the new Windows and Mac default theme it only has an effect on the back button, right? Exposing this as "Use small icons" to the user seems rather strange to me, so we might want to do something about it anyway.
(In reply to comment #17)
> So... about the small icon / large icon switch: In the new Windows and Mac
> default theme it only has an effect on the back button, right?

It actually affects all buttons on Windows.
(In reply to comment #18)
> (In reply to comment #17)
> > So... about the small icon / large icon switch: In the new Windows and Mac
> > default theme it only has an effect on the back button, right?
> 
> It actually affects all buttons on Windows.

Oh, I see. That changes things again...

(Man, what a mess.)
>> The only way this is going to work is if you reuse the already existing sizes
>> of 16x16 and 24x24.

>24px icons just don't fit into the new buttons. Looks like we're not going to
>hit this goal completely.

Then change the new buttons!

Why wasn't a goal of the new theming to try to use the existing buttons that addon developers have been using for YEARS?

>> Please stop this. Use the existing 16x16 and 24x24 icons for all add-on
>> toolbars.

>Wait - are you only talking about icons in an add-on's own toolbar, and not
>about toolbar buttons in, say, the main navigation toolbar?

Primarily, but all these icons can be dragged into the Firefox UI as well.

But if you look at the screenshot attached, my biggest complaint is that existing toolbars look bad.


And the small/large icon switch does nothing on Mac at all anymore (at least on Beta 2) so it is a strange thing to have on Mac.
>> It actually affects all buttons on Windows.

>Oh, I see. That changes things again...

It only affects the buttons on Windows. Not the actual icons.

So "use small icons" isn't even the right term. It just changes padding and margins.

So what the new themes have effectively done is removed most of the distinction between small icons and non small icons.

Why not just get rid of the small icons concept completely now and have one set of icons?

The icons on Windows at least are 18x18. So for addons, use their 16x16 icons all the time and ignore 24x24.
Incidentally, another problem that's been introduced here is that you force small icons to be a certain size by scaling them.

In previous versions of Firefox, this wasn't the case. They were used as is. So if an addon developer chose to make his small icon 32x16, that was ok. Now you're forcing all small icons into a scaled square box.

Were any addons at all tested with these theme changes?
Is there any documentation of the changes happening with the toolbars and toolbar buttons? There should be something in this article: https://developer.mozilla.org/en/Firefox_4_for_developers, but there's no mention yet.
Any blog post, wiki page, whatever that explains the recommended icon sizes for the 3 major platforms in Firefox 4?
I'm siding with Michael. I till now was just a spectator, hoping this would be resolved in a sane manner, but since UX seems to insist on their plans I felt the need to give my two cents.

While the other addon related changes so far seem to have merit and can be worked around easy enough, icon sizes are indeed a deal breaker.
Scaling of pixel-based icons never looks good, so no go there.
Using pixel-based icons (i.e. pngs) in different resolutions won't work, as themes should be enabled to use whatever icon size they please. And those different resolution would have to be created first.
SVG isn't there, and you cannot achieve pixel perfect results with it anyway. See Alex' progress reports on the last Firefox icon make-over and what he had to tell about fine-tuning the icon for different resolutions.
So scalable icons are a non-option. Not that this wouldn't create the new problem for all addon developers to actually "port" their icons to SVG...

What leaves us extension developers with... no option at all!

My proposal for a "cure", basically repeating Michael:
* Make "small" the only used size across all default themes.
* Standardize on 16x16 (+ any padding) as all affected extensions should already have such icons.
* If a particular UX needs larger or smaller buttons just fix this by using some more or less padding.
* Always set "small" for backward compatibility. This will tremendously improve the situation as addon developers don't have to jump through loops to have a minVersion < 4.0
* Third-party themes will either stick to this, or they will be using scaled images. But that's their problem then.

(In reply to comment #23)
> Is there any documentation of the changes happening with the toolbars and
> toolbar buttons? There should be something in this article:
> https://developer.mozilla.org/en/Firefox_4_for_developers, but there's no
> mention yet.
> Any blog post, wiki page, whatever that explains the recommended icon sizes for
> the 3 major platforms in Firefox 4?

There is no documentation as there currently is nothing to recommend. As Dão explained, there is in fact currently simply no such thing as recommended sizes, at least if you don't want to have your icons to be scaled.
We might however blog about this, and see if anybody else can come up with a viable solution.
There is however an older blog post by Stephen, focusing on creating new glyphs. But this will neither fix the scaling problem, nor the problem of addon developers having to allocate resources to create new icons.
http://blog.stephenhorlander.com/2010/03/29/make-your-own-toolbar-button-glyphs/
Hmm.  Not bad enough that XPCOM changes completely broke my addon in a "beta", but now I have to hire another designer to redo my icons?

Rush rush rush - feels like Netscape 6 all over again...
> >  - Don't make existing add-ons' icons look hideous.
> This is impossible if you introduce ANY scaling. You can't do scaling of very
> small images and ever expect them to look good.
> The only way this is going to work is if you reuse the already existing sizes
> of 16x16 and 24x24 [without scaling]

ditto
> if an addon developer chose to make his small icon 32x16, that was ok. Now
> you're forcing all small icons into a scaled square box.

FWIW, that breaks us, too. And it's easy trivial for us to add a CSS rule either, given the source structure. (If we even knew the size, but apparently it's platform specific and at the whim of the theme creator, so we can't even do that.)
> it's easy trivial

it's *not* trivial (sorry)
This shows of the scaling artifacts for the Adblock Plus icon, which I guess is the most popular and hence visible extension icon around right now.
The ABP text is all fuzzy for the "small" icon, while the "large" icon looks plain horrible.
Screenshots taken from central nightly on Windows 7 w/ Aero.
Just for your info: The "large" icon is the bottom one ;)

This furthermore outlines the need for designers to create icons targeting different "dimension ranges". The original "large" icon is not just an enlargement of the "small" icon, but actually has more detail. In the wild this is not only limited to details, but also things like shadows, etc. come into play.
Just look at the official Firefox logo in different dimensions.
So it's not just a matter of different dynamic scaling or even different rendered versions for different dimensions based on the same scalable "template". So SVG doesn't really seal the deal.

Even shrinking/enlarging a smallish image by just one or two pixels will create bad scaling/aliasing artifacts.
Even if you could reasonably dynamically detect the required icon size then you'd still have to render pixel-perfect versions of an icon for each and every possible dimension configuration. Or do nasty things like adding "padding" directly to the image which you would dynamically clip() away, like it is done with the built-in Firefox button icons IIRC (see the blogpost by Stephen I mentioned in comment 24)
(In reply to comment #29)
> Created attachment 462661 [details]
> Example: Scaled Adblock Plus icons

Yeah, this shows the more interesting problem. When you scale a 16x16 image up to 18x18 it appears larger than the 24x24 image scaled down to 18x18.

I was seeing that as well, and that's a real problem.
(In reply to comment #24)
> SVG isn't there

Gecko 2.0 is going to support it.

Also, people can opt out of the primary toolbarbutton styling with the enforced size by not using the toolbarbutton-1 class. This doesn't work for type="menu-button" toolbarbuttons, but that's a bug.
(In reply to comment #31)
> Also, people can opt out of the primary toolbarbutton styling with the enforced
> size by not using the toolbarbutton-1 class. This doesn't work for
> type="menu-button" toolbarbuttons, but that's a bug.

You closed my other bug telling me that toolbarbutton-1 was required!
It's required if you want the primary toolbarbutton styling with the enforced size.
Cyclic arguments are classic. You said "it's a bug", but you closed that very bug as INVALID.
(FWIW, bug 583168)
Bug 583168 assumes the complete opposite of what I said.
(In reply to comment #24)
> While the other addon related changes so far seem to have merit and can be
> worked around easy enough, icon sizes are indeed a deal breaker.
> Scaling of pixel-based icons never looks good, so no go there.
> Using pixel-based icons (i.e. pngs) in different resolutions won't work, as
> themes should be enabled to use whatever icon size they please. And those
> different resolution would have to be created first.
> SVG isn't there, and you cannot achieve pixel perfect results with it anyway.
> See Alex' progress reports on the last Firefox icon make-over and what he had
> to tell about fine-tuning the icon for different resolutions.
> So scalable icons are a non-option. Not that this wouldn't create the new
> problem for all addon developers to actually "port" their icons to SVG...

With respect to scaling SVG, depending on how it's done you could get decent results, specifically you could take a page from fonts and do auto-hinting, or have some sort of CSS extension that lets you size things such that you get similar results to having auto-hints, alternatively you could make it possible to include a bit of JS that does hinting (with extra API for doing it, ie define an API for hinting and let SVG icons carry hints with them)

That said currently it's not really possible to get pixel perfect results with SVG, but only because no one is really trying to make it possible.
> The only way this is going to work is if you reuse the already existing sizes
> of 16x16 and 24x24 [without scaling]

The scaling is looking pretty bad for a lot of extensions.  Can we avoid this and only load provided 16x16 images?  Ideally we should make this clear soon as part of add-on compatibility.
Depends on: 585285
Has any research/testing been done with the new Windows theme with any actual users? I'm not be sarcastic. I'm sincerely curious.
When the back button was made larger, it was done so based on usage research. So now is it just assumed that everyone knows where everything is so there's no need for anything uniquely identifiable? How does making all of the buttons tiny and the same colors help with usability or accessibility? 

Colors and whatever glyphs and images that developers squeeze into the 24x24px icons help users to quickly identify an add-on's button (and navigation buttons) and they help to differentiate them from other add-on's buttons. 

Making the toolbar buttons smaller makes people focus harder to identify a button especially if they use a lot of buttons with similar colors. A user should be able to just glance and click, not look for something.

The Toolbar Buttons add-on is very popular (in downloads and usage) and offers 100 toolbar buttons. Of course no one uses all 100 at once, but the smaller something is, the more time it takes the brain to process it. A lot of add-ons would need some new icons, and not all developers are graphical artists, but I guess that point has been covered.


I just don't understand the logic of having to use and create smaller buttons.
Well, the logical is to match the theme, but what about usability, accessibility (for the visually impairment), and the theme and extension developers.
(In reply to comment #39)
> Has any research/testing been done with the new Windows theme with any actual
> users?

I don't think so, and I agree it's not a great move in terms of usability/accessibility, except for dark or noisy backgrounds where many icons would fade away without the button texture.
Will Firefox 4 make a distinction between the unified-back-and-forward "keyhole" button and the separated back and forward look?

I ask because in FF 3, the distinction is implicit, as the css is selected based on the the toolbar attribute "mode": mode == 'icons' selects keyhole, any other mode selects separate.

This becomes interesting, because the default FF theme also selects css based on attribute iconsize to determine the back and forward icon sizes:

                 mode: icons        | anything else
iconsize: large   36x34 keyhole     | 24x24 separate
          small   24x24 keyhole     | 16x16 separate


And third-party themes, especially compact ones, use different icon sizes.

In my extension, I've figured the best of a bad situation is to select css based solely on the size of existing buttons:


#mybutton {
   list-style-image: url("chrome://myext/skin/36.png");
  -moz-image-region: rect(0px 28px 24px 0px);
}

#mybutton[mysize~= 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35] {
   list-style-image: url("chrome://myext/skin/24.png");
  -moz-image-region: rect(0px 28px 24px 0px);
}

#mybutton[mysize~= 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16] {
   list-style-image: url("chrome://myext/skin/16.png");
  -moz-image-region: rect(0px 16px 16px 0px);
}

and then set "mysize" in javascript:

document.getElementById( "mybutton" ).setAttribute( "mysize",
document.getElementById( "back-button").boxObject.width ) );

Of course, one could also just round up the result of document.getElementById( "back-button").boxObject.width.
The original problem indicated here isn't there anymore because menu-buttons on Mac get no styling at all.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: