For the past couple of weeks, I have been thinking about the new buttons for WebKit. There are basically two types of buttons that I am working on replacing. The first is
input and the second is
button. Below is the heuristic I’ve decided to follow.
There will be three new appearance constants for buttons. They are
input will be using
push-button by default. This constant maps to the Aqua system button. When this appearance constant is specified, the only way to disable the Aqua look will be by setting the appearance constant to
none (which will give you a completely blank slate on which to build your own button look) or by specifying your own background and border properties. Specifying the background/border will result in the Aqua appearance being disabled and a more platform-neutral look being used.
As long as the Aqua appearance is enabled for push buttons, certain CSS properties will be ignored. Because Aqua buttons do not scale, the
height property will not be honored. Similarly font and color customizations will also not be honored. The overriding principle for push buttons is that you will never see a button that is some “half-Aqua” mix. Either the button will look perfectly native, or it will not be Aqua at all. When the appearance is disabled, all CSS will be honored on the button (including fonts, height and colors). As with existing Safari releases, the font size specified on the element will be used to determine whether the mini, small or regular version of the control should be used.
The bevel-button constant represents a button that can scale vertically. Beveled buttons will allow custom fonts and colors and honor height by default, all without disabling the appearance. Background/border setting will result in the beveled button appearance being disabled.
The final constant is
button and represents a mixture of the above constants. This constant is the one that will be used by
button by default. The
button appearance constant will allow fonts/colors to be set and will lay out the button. Once the size of the button has been determined, then an appropriate rendering choice will be made dynamically based off the size of the control. If the control size fits within the mini/small/regular Aqua ranges, then these will be chosen and centered within the available space. Once the height of the button goes beyond the size of the regular Aqua button, then a beveled button rendering will be used instead.
This does mean that the HTML4 button can give you some funny-looking “half-Aqua” renderings under certain circumstances, but I figured that was better than doing the beveled button look all the time. Because Web sites commonly just use single-line text in button elements without customizing the CSS at all, these buttons should be indistinguishable from Aqua buttons in most cases.