Buttons
Posted by Dave Hyatt on Friday, October 7th, 2005 at 11:39 amFor 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 push-button, bevel-button and button. 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.
October 7th, 2005 at 1:38 pm
You’re speaking about using the CSS 3 UI appearance property, right? What about using an vendor-specific value for the bevel button, like
-khtml-bevel-button?October 7th, 2005 at 2:11 pm
Allowing padding-left and padding-right on buttons of all sizes would be very much appreciated.
October 7th, 2005 at 4:25 pm
It’s hard for me to judge the buttons without being able to see a few examples of them.
Any way to help me out?
October 7th, 2005 at 5:18 pm
Padding will be ignored for push buttons and honored for bevel buttons.
October 7th, 2005 at 6:15 pm
Some things I’ve noticed about current push buttons:
1. Text size of the buttons seems too small. Let’s say I leave a page at default font-size (16px), buttons will be of the small variant (11px Lucida Grande) even when I set button’s style to “font-size: inherit”. You have to set the font size ridiculusly big to have a 13px font in a push button.
2. This may be an oversight, but it seems the horizontal space between the text and the sides of the button in all version of Safari I’ve seen is shorter than the minimum space imposed by Interface Builder and found in most applications. I’m sure I remember earlier version of the Human Interface Guidelines where specifying that minimum space, but I couldn’t find that value in current document.
3. There may be a reason to not do that, but wouldn’t it make sense to make glow the the default button of a form when the focus is on an element where the return key would simulate a push of that button?
October 8th, 2005 at 4:12 am
Have you thought about how to deal with the -button for the type “file”? This is one of the mostr inconsistent buttons in the HTML-specs I know. Doing WebApplications with WebObjects this button is always the one button that breaks the design-experience. You just cannot change its appearance. To use a graphic instead of the default butoon using some “src”-binding would be perfect.
Is there some development in this direction?
regards,
helge
October 8th, 2005 at 2:12 pm
It is arguably a security risk to allow customization of the file upload control.
October 11th, 2005 at 7:48 pm
I would love to be able to style these things in some capacity, but I realize that to allow access to them at all is to open Pandora’s box in terms of tricking end users. Therefore, I agree with Dave 100% on the security issue (just see the litany of potential exploits such as .click() or styling, etc).
But for the love of all that is css, do we have to continue down this path:
http://www.quirksmode.org/index.html?/dom/inputfile.html
Brilliant solution given the nastiness of the problem.
October 31st, 2005 at 9:39 pm
Oh, and while you’re fixing buttons – is there any chance that clicking a label will select a radiobutton? It works this way in OS X and in all browsers except Safari.
Example:
o Option One
o Option Two
In all other browsers, when clicking the text “Option One”, the radiobutton will be selected. Not so in Safari (tested with recent 10.4.3 OS X update, released today).
November 14th, 2005 at 3:25 pm
Can we get gmail working again? Gmail hasn’t worked with webkit for like 2 months. Open Gmail, and Try to click anything. Nothing.