40268 - Platform-consistent look and feel for <button/>

Status: RESOLVED WORKSFORME

(Core :: XUL, defect, P3)

Description

[Matthew T (active 1999-2002)]

This bug covers platform-consistent look and feel for the <button/> element. For 
more info, please see bug 39375.

On a global level, we need two classes of button. (Skins may define their own 
additional classes which inherit from these classes.)

* class="bevel"

  The ordinary rectangular bevelled button. This needs styles for these states:
  - enabled
  - with focus (on Windows, a dotted line around the button contents inside the
    button; on Mac OS, a highlight-color border around the button)
  - depressed (on Windows, reversal of the button bevels; on Mac OS, reversal of
    bevels and the color of button text, and filling of button background with
    dark gray)
  - disabled (on Windows, embossing of the button text; on Mac OS, hiding of the
    button bevels, and graying out of the button outline and text).

* class="dialog"

  The type of button which is normally used in a dialog to close it (or to open a
  further dialog). On Windows and GTK, the appearance of this button is much the
  same as "normal" class, but (on all platforms) it has a minimum width set
  (probably in ems, so as to look appropriate at different font sizes). On Mac
  OS, dialog-class buttons also have rounded corners, unlike normal-class
  buttons. Also on Mac OS, the default font for dialog buttons is the large
  system UI font (e.g. Charcoal/Chicago 12), rather than the small system UI font
  (e.g. Geneva 10).

  In addition to the states for normal-class buttons, dialog-class buttons need
  appearance for `default button' state -- where a button is the button that will
  be activated when Enter is pressed (as opposed to ordinary focus, which
  determines that a control is the one that will be activated when Space is
  pressed). On Windows, this is shown by an inset black border for the button. On
  Mac OS, this is shown by an outset bevelled gray ring around the button.

Comment 1

[Matthew T (active 1999-2002)]

Forgot to assign to [e-mail] ...

Comment 2

[Nikhil Bhatla (gone)]

While fixing the Mac Classic Skin buttons, I re-did the button class scheme so 
that there are now 2 classes: a regular button class and an "exit-dialog" button 
class.  Exit-dialogs are used for the OK/Cancel buttons that close dialog boxes. 
 I modified the classes of each of these buttons in platformDialogOverlay.xul.  
If you check out the new mac skin (finished checkin of buttons today, so should 
be in tomorrow's build), you will see that there are now 2 types of buttons.

I did not modify the windows or unix skin to take advantage of the new class, 
but free to send me updates to those skins as well and i'll submit them.  Let me 
know what you think of the mac skin and the button classes.  I've marked this 
bug as fixed.

Comment 3

[Matthew T (active 1999-2002)]

`exit-dialog' is a misleading name, because such buttons are used for many other 
purposes -- `Search' in the location bar, `Next' and `Back' in wizards, `View 
Stored Cookies' in prefs, etc etc.

The Mac Classic skin should have global CSS rules which look roughly like this 
(the names may be different):

button.block, toolbar button {
  -- properties which define square button appearance and margins
  -- buttons inside toolbars should be square by default,
  -- hence the `toolbar button' selector
}

button.dialog, button {
  -- properties which define rounded appearance, large UI font, and
  -- horizontal/vertical margins
  -- Mac buttons should look like this by default, hence the `button' selector
}

Do the Mac buttons have the correct (grayed out) appearance when disabled? And if 
the disabled appearance is not used for all widgets when the window is not 
frontmost, you probably need to file a separate bug.

Please note that this is a tracker bug, and is not completely fixed until all 
three platforms are actually using native widgets.

Comment 4

[[e-mail]]

Personally I don't think there should be a default button style so that every
button must be classed and styled, but avoiding having to override the default
style.

Also, the skin that I'm writing which styles button.dialog broke when the OK and
Cancel button classes where changed. Although "dialog" is possibly a bad class
for a button because it's not unique I think that substyles should be
implemented using dual classes e.g. <button class="dialog exit">.

Comment 5

[Matthew T (active 1999-2002)]

The whole idea of having a default button style (where the default is different 
within toolbars from how it is everywhere else) is so that you *don't* have to 
class every button. You only need to class the button if you intend one class 
where the other usually applies.

Anyway, isn't it illegal for class names to include spaces?

Comment 6

[Nikhil Bhatla (gone)]

I understand your design suggestions, and we ([e-mail] and I) are 
pursuing a slightly different design.  Their are essentially three button 
classes:

	- button, which in the mac classic skin is a curved button with regular 
geneva 8pt font.  In windows and unix it is still a box button.
	- button.plain, which in the mac classic skin is the bare-bones box button.
	- button.exit-dialog, which in mac classic has the larger charcoal 9pt font 
and has the ability to have a default look.  On windows and unix this ability 
also exists, but is currently not being directly styled in the classic skins for 
those platforms.

The mac buttons have the correct grayed out appearance when disabled.  The 
toolbar buttons actually point to different XBL, so they are almost a new class 
entirely (.button-toolbar-x).  Currently, even if mozilla is not the foremost 
window, its window does not acquire the grayed-out look.  This is a separate bug 
that won't be addressed in the 6.0 netscape release.

As of now, the dialog class should never be used in reference to buttons.  The 
modified platformDialogOverlay.css removed that class and replaced it with the 
new exit-dialog class.

When class names include spaces, that means that you are applying multiple 
classes to the same element.

Comment 7

[Matthew T (active 1999-2002)]

* The `button' class should not use `font: 8pt Geneva'. It should use
  `font: caption' (which is usually equivalent to `font: 12px Charcoal'). 4.x
  (and Microsoft software for Mac) uses 10px Geneva for buttons in various
  places, and the UI suffers as a result. Apple, Adobe, etc always use the large
  system font for buttons, except where the button text might be very long (e.g.
  category buttons in the Launcher, and application names in the Internet control
  panel).

  `font: caption' should be used for:
  - buttons, pulldown menus, popup menus, and short text entry fields (except
    where any of these are inside a toolbar)
  - any checkbox groups, radio button groups, or captions which are adjacent to
    (or which enclose) buttons, pulldown menus, popup menus, or short text entry
    fields (except where any of these are inside a toolbar).
  All of this can be specified using CSS2 selectors (with the possible exception
  of specifying what `short' means for a text entry field).

* The `button.plain' class should use `font: small-caption' (which is usually
  equivalent to `font: 10px Geneva').

* I can't think of any useful difference between the `button.exit-dialog' class
  and the `button' class, except perhaps in the number of pixels used for
  padding.

Comment 8

[Nikhil Bhatla (gone)]

First off, it cannot use 'font:caption' because currently the fonts showing up by 
CSS font selectors are not the correct font from the system.  This feature has 
not yet been implemented.  Also, there is a difference between CSS font sizes and 
system font sizes, for some reason.  8pt Geneva in CSS is equivalent to 10pt 
Geneva in the system, and the same is true for charcoal.  

Please check out the Mac classic skin if you get a chance and you'll see that all 
the sizes are right.  It is not true that Apple never uses the smaller geneva 
font in buttons: Check out TCP/IP ->Connect via: AppleTalk and you will see a 
button that uses geneva. I don't think the UI suffers because of this.  

The distinction you made between 'button' and '.exit-dialog' is exactly right, 
plus the font size differences and the fact that you never get a default button 
that is not an '.exit-dialog'.

Comment 9

[Henri Sivonen (:hsivonen)]

To get matching sizes, use px (as Matthew wrote) and not pt.

Comment 10

[[e-mail]]

The reason that I don't like unclassed buttons is that dialog buttons and
toolbar buttons have completely different styles. This means that every class of
toolbar button has to undo the styles applied by default to buttons :-(

Comment 11

[Matthew T (active 1999-2002)]

Nikhil:
>
> there is a difference between CSS font sizes and system font sizes, for some
> reason.

Maybe that's because the default setting for Mozilla is 96 ppi, not 72 ppi, even 
in the chrome? (That's why I used `px' and not `pt' above.)

Neil:
>
> This means that every class of toolbar button has to undo the styles applied by
> default to buttons

No it doesn't, because the `toolbar button' selector I wrote above would apply 
the square style to any button inside a toolbar by default.

Comment 12

[[e-mail]]

What I mean is, suppose you have defined the button by default as having a round
groove border, then when you wanted a toolbar button you would have to define it
as not round and no border.

Comment 13

[Matthew T (active 1999-2002)]

No, you'd either (a) put it inside a toolbar, or (b) say button class="block". No 
extra CSS required.

Comment 14

[[e-mail]]

While I don't understand about button class="block", I have figured out a
workaround. I created a completely new button behaviour using new class names
and only style those class names, not the actual button. Ordinary buttons then
use this behaviour. However toolbar buttons override the behaviour and therefore
my styles are completely ignored!