The New Form Controls: Checkbox
Posted by Dave Hyatt on Tuesday, August 2nd, 2005 at 8:28 pmThe first of the new form controls for WebKit has just been turned on in the latest WebKit tree. Because it is the simplest of the controls, I converted checkbox first. This new control can be completely styled via CSS, so you can decide exactly how the checked, hovered, pressed, focused and disabled states of the checkbox look.
The basic idea behind all of the upcoming form controls is that the engine implements the behavior and logic of the control, and if a native (i.e., Aqua) look is desired, then the painting is done by a theme API. The native appearance is controlled via a new experimental CSS property, -khtml-appearance. All you have to do to turn a widget into a blank slate is to set this property’s value to none.
Some controls are going to naturally discard the Aqua look if you “fall off the cliff” by customizing the control to the point where the Aqua look can no longer be maintained, e.g., if you set the border and background of a button. Others, like checkbox, are going to refuse to “fall off the cliff” unless you explicitly turn off the -khtml-appearance property. The choice of when to disable the Aqua look is going to be chosen to match other browsers (and Internet Explorer in particular).
The new checkboxes in Safari are inline blocks by default. Therefore you can set borders, background images, and background colors. Support for the :enabled, :disabled, and :checked pseudo-classes has been added to the engine so that you can easily write CSS rules to change the checkbox’s appearance for the appopriate states.
In order to make the checkbox behave properly with selection and mouse tracking, I also fixed one of the bugs that has been plaguing users of contenteditable divs in Safari, namely that selection was being cleared when you moused down on images, links, buttons and controls. This bug has now been fixed so the the selection will not clear when you mouse down on these types of objects.
August 2nd, 2005 at 11:03 pm
Are there any examples of this new property in use? Like in use in a very ugly way?
August 3rd, 2005 at 12:19 am
Would it be possible, as a user not a designer, to prevent this styling?
Really I want to keep the native look and feel of things like buttons and check boxes at all costs. Nothing is more annoying than trying to figure out what’s a button and what’s not on some over-designed page.
I love that Safari uses native controls as much as it does. I’m desperately looking for a way to make my Windows Firefox installation do the same thing.
August 3rd, 2005 at 1:37 am
I would like to second Gareth’s suggestion (comment #2). It would be nice (good) to have a preference to prevent author styling of form widgets.
Opera 8 (on Mac at least) already has such an option. It is a huge time saver. And I’ve hacked Firefox to prevent most author styling of form widgets as well.
August 3rd, 2005 at 2:14 am
Custom, renderer-specific CSS properties? Is that not the path of evil?
August 3rd, 2005 at 2:54 am
I’m very happy for this, the standard Aqua widgets look so out of place on some pages.
August 3rd, 2005 at 4:54 am
Who is “I”? When coming from an RSS reader, the author name is not visible. Example:
http://webkit.opendarwin.org/blog/?p=17
The name “hyatt” is nowhere on the page. It’d be nice if the “posted by…” line that appears on the main page also appeared on individual posts.
August 3rd, 2005 at 4:56 am
Any progress on making “label” tags activate their associated controls? Firefox does it, and it’s nice. (There’s a bug in RADAR about it somewhere. Mine was marked as a dup, IIRC.)
August 3rd, 2005 at 10:18 am
John, the RSS2 and Atom feeds both have authors for each entry. The RSS 0.92 feed doesn’t.
August 3rd, 2005 at 11:10 am
chucker: I meant on the web page itself. If you go to the URL I posted with your web browser (not RSS reader), the author’s name does not appear on the page. I got to the URL through an RSS reader, but I guess it’s the same URL that you get if you go through a web browser.
August 5th, 2005 at 3:05 am
Another vote for a user preference (which probably should be on by default) to disallow author styling of form controls. I’ve always found Safari’s refusal to let authors use CSS to alter the look of its form controls very good for usability. As for looking out of place, that may be the case on some sites, but at least the user will always (not taking faking it with images into account) know for sure what is a form control and what isn’t.
August 8th, 2005 at 7:31 am
For the users of contenteditable divs and other similar selection-dependent technologies, wouldn’t a more generalised solution be better? Ideally, WebKit/Safari would support similar behaviour to that of IE and Firefox, rather than having special cases in which the selection is not affected.
In IE, you can add unselectable=”on” to almost any HTML element, which makes all clicks within that not affect the current selection. In Firefox, you can use the styles {-moz-user-focus: ignore; -moz-user-input: disabled; -moz-user-select: none} for the same effect. I’ve used some of them to good effect, before.
August 9th, 2005 at 2:23 pm
Grant, the solution is generalized. If you use -khtml-user-select: none, then the object will be unselectable as in Firefox and also won’t clear the selection when you mouse down on it. I added a new value, -khtml-user-select: element, that I’m using for controls, images, and links, that denotes that the object is selectable if the selection doesn’t start inside it, but otherwise it behaves like none.
I’m probably going to change the name of this value to ‘ignore’ instead of ‘element’ though to better reflect what it does.
August 10th, 2005 at 8:10 pm
Is there a reference list that describes all the ‘-khtml-’ properties and the values they accept? I looked on google and this site and Apple’s developer site, but I couldn’t find anything.
July 3rd, 2007 at 7:48 am
[...] (u trenutku dosade naravno) o stilizovanju ovog taga u Safariju 3. Odličan tekst! Imate i ovde par odličnih (idete na tekstove levo i desno, dosta dobrih), iskreno na Safari nikada nisam obracao paznju [...]