Microsoft Office 2007+ and Windows 7 have a new type of button similar to our XUL <button type="menu-button"> with a button to take a default action along with a submenu for related actions. The buttons should glow when hovering over them. We should either have the default style of our menu-button be like that of Windows 7 or else make a new button type="split-button" that uses this style. Split buttons can be used with horizontal or vertical menus. See the URL or attachment for screenshots.

The great thing about this design pattern is that it allows you to provide the user with a very clear default option, while still allowing for fine grained control. The Windows HIG documents the split button saying: "Use a split button to consolidate a set of variations of a command, especially when one of the commands is used most of the time." http://msdn.microsoft.com/en-us/library/aa511453.aspx These buttons are now found throughout Windows and Office, to simply a variety of interfaces that users commonly interact with. For Firefox we are interested in introducing split buttons and split menu commands as part of our notification redesign.

This is actually what <button type="menu-button"> is for. It's desperate for some appearance fixes.

A totally forgot about the existence of menu-button, adjusting summary.

How should these buttons look on Mac and Linux?

On Linux probably nothing special to keep it native, there was no such revolution in UI like on Windows (no ribbons, no menu buttons).

>On Linux probably nothing special to keep it native, there was no such >revolution in UI like on Windows A lot of the aspects of our new notification design aren't really being used by any of the platforms. This is because applications usually don't have inside of themselves other (in our case Web) applications that need to speak to the user. For instance, notification bars didn't exist on Linux and we brought those over. So I think there are some advantages to keeping the Firefox UI consistent across all platforms here. We need to visually style the buttons so that they look native though.

(In reply to comment #4) > How should these buttons look on Mac and Linux? I don't think there is a standard look/feel on Mac and Linux for these types of buttons. Currently, the menu-buttons look one button inside another. We should at least make it look like a single button with perhaps some form of separator.

> Currently, the menu-buttons look one button inside another. I think you're wrong. Pure only-menu buttons look like button with dropdown arrow. Buttons which can perform an action and have some options, look like double icon + arrow button or button inside button (outer contains full-sized dropdown arrow and another button which performs main action). I also guess menu-buttons in Firefox are meant to open Firefox's main, page and tools menus, without performing of any action. So they just have to open popup menu and they do not require to be button inside another button. Dropdown button like inside bookmarks fodlers buttons (on bookmarks bar) is enough.

I'm referring to <button type="menu-button"> which currently renders like the image in http://www.gavinsharp.com/blog/2010/04/09/notification-notifications/ However, it should render as a single button with a separator of some sort.

Oh. Awful.

(In reply to comment #4) > How should these buttons look on Mac and Linux? The closest I can find for Linux is what was mentioned in bug 409655, but that's for toolbars. (The menu-button in Evolution behaves the way described in that bug.)

(In reply to comment #4) > How should these buttons look on Mac and Linux? - Windows - There are a few examples of split buttons in Windows Vista/7. The glassy one on the Start Menu and the toolbar buttons. The glassy style will work really well for panels. States from top to bottom: * Default * Hover * Main Button Pressed (It depresses the whole button including the menu side) * Menu Button Pressed On XP it should be similar but probably not glassy. - Mac - There is only one native example for split buttons on OS X that appear in Mail style toolbars. States from top to bottom: * Default * Menu Button Pressed * Main Button Pressed - Linux - This is a little trickier since all of the Linux examples of split buttons have them physically separated. Which feels strange and isn't quite right. Like it is two buttons instead of one button that does two things. Probably want to keep them consistent with the other platforms. It would be nice if we could somehow get the native button texture and shape and then apply some panel styling to it. Otherwise we could create a button that adapts to various backgrounds. States from top to bottom: * Default * Hover * Main Button Pressed * Menu Button Pressed

This improves the appearance of menu buttons on win/lin/mac by removing the styling on the inner anonymous button. menu-buttons still have some problems, though: 1) clicking on the edges of the "main button" section (i.e. not on the inner anonymous button directly) triggers the popup. I tried fixing this by removing the inner button's padding/margin, but even with that there's a single pixel that's still clickable on the container that I can't seem to get rid of. 2) the native button styling on the container means that the :active styling is triggered when you click the dropdown. I don't think this is desired, and I don't know that it can easily be worked around. An alternative is to natively style the sub-elements individually, but then I think making them look good together would be tricky (would need to cut off the right edge of the inner button somehow, for example, so that it sticks right up against the dropmarker) 3) focusing/activating the button with the keyboard doesn't really work as expected. I'm not sure why and haven't really investigated much.

(In reply to comment #13) > (would need to cut off the right edge of the inner button somehow, for > example, so that it sticks right up against the dropmarker) This only applies to Mac, I guess. I'll try this approach for Linux/Windows.

Is there a reason the menu-button is made up of one button inside another?

What's the alternative? I have no idea what the best way to implement this kind of button is.

This looks OK on linux (two natively-styled buttons squished together), but wouldn't work on Mac, and still doesn't really behave right wrt focus/keyboard access and such. I guess trying to work in native button styling on Mac for this is a fool's errand... I would love nothing more than for someone else to take this bug! :)

(In reply to comment #17) > This looks OK on linux (two natively-styled buttons squished together), but > wouldn't work on Mac, and still doesn't really behave right wrt focus/keyboard > access and such. I guess trying to work in native button styling on Mac for > this is a fool's errand... I don't know much about XUL but maybe you could crop two button and add a separator? Seems super hacky and really I am not sure native styling is necessary here. Where would these be used outside of the toolbar or panel case?

This bug is more about menu-buttons in general - for the notification case specifically, it's easier to get away with just avoiding native styling entirely. I'm reluctant to manually fake native styling, though, since that can cause trouble when different native themes come into play (i.e., better to go with something that doesn't attempt to look "native" if we're doing fully-custom styling). Though maybe that isn't a valid concern on Mac...

Comment on attachment 440596 [details] [diff] [review] patch I'd like to take this as an interim fix, to unblock bug 398776.

Going to call this FIXED: http://hg.mozilla.org/mozilla-central/rev/1a15dd47da63 I'll file a followup on actually making them nice.

I plan on backing this out because of bug 581193. In a nutshell, this made the type="menu-button" default style less ugly on first glance but basically unusable since it looks just like type="menu", which isn't a sensible step forward.

I don't think that's acceptable. This bug is worse than bug 581193.

(In reply to comment #24) > I don't think that's acceptable. This bug is worse than bug 581193. It's not, functionality over looks. We need visual improvements that don't regress basic usability. The widget can't really be used out of the box either way. All this bug did was a) to churn the code, potentially requiring custom stylings to be updated, and b) make it less obvious that the default styling is broken, tricking consumers into thinking that they're good when they aren't.

I don't really understand why you keeping saying that the buttons "aren't functional". As I said in bug 581193, it's confusing that there's no clear delineation of the dropdown vs. button, but I don't agree with you that this equates to "not functional". I think the widget can be used out of the box in its current state, despite that bug. I think that's less true if we back this out.

(In reply to comment #26) > I don't really understand why you keeping saying that the buttons "aren't > functional". As I said in bug 581193, it's confusing that there's no clear > delineation of the dropdown vs. button, but I don't agree with you that this > equates to "not functional". I think the widget can be used out of the box in > its current state, despite that bug. I think that's less true if we back this > out. See bug 581193 comment 11, we don't need to rehash all this.

backed out: http://hg.mozilla.org/mozilla-central/rev/44382cb1ecc6

Dao, I'm not sure why you are backing out code from a module that you're not listed as a reviewer or peer for, when Gavin who is reviewer, objects.

We sorted it out via email. I misunderstood the confusion-severity of bug 581193 somewhat, and this bug isn't a regression (except insofar as menu-buttons are more prevalent due to popupnotifications, which was mitigated at least for Firefox with specific styling).

Neil, I'm also listed as the sub module owner, whatever that means exactly...

5 years after the fact, any progress on this? Consumers like TB are suffering from this bug.

Can this be closed ?