Accessible, Custom Designed Checkbox and Radio Button Inputs Styled with CSS (and a dash of jQuery)
Posted by Maggie on 07/01/2009
Styling checkbox and radio button inputs to match a custom design is nearly impossible because neither reliably supports basic CSS, like background colors or images; it's even a challenge to get the margins to appear consistently across browsers. To remedy this we developed a concise jQuery plugin based on progressive enhancement that leverages an input element's built-in functionality and accessibility features and works in all modern browsers without added markup or mandatory CSS classes.
In the past few years web application interface designs have evolved from flat metal gray to having rich color palettes and dimensional background images thanks to the adoption of web standards and advanced CSS techniques. Form checkboxes and radio buttons have lagged behind, though, because only a few browser vendors have built in support for styling these elements with CSS, and inconsistently at that. A quick search turned up several workaround scripts that cleverly use a combination of JavaScript and CSS to apply a custom skin to these form elements, however they sometimes do more work than we need them to by inserting replacement markup, or requiring that specific classes be assigned to every applicable form element.
When considering how to build our own customized input script, we set out to do as little as possible — on their own, checkboxes and radio buttons capture data and display feedback, and we wanted to use that native functionality and not reinvent it using JavaScript. If we let the user interact with the inputs as expected, we'd only have to apply a lightweight script to layer on visual enhancements for richer feedback. And by keeping our hands off the inputs' native functionality, we were able to preserve their inherent keyboard accessibility and avoid the need to use ARIA attributes since a screen reader is still interacting with the native form element.
Update: We've received a lot of thoughtful comments on this technique, one of which stood out: what happens when images aren't available? In our first pass at this widget, we hid the input element by positioning it off the page, and then styled the label element with background images that mapped to click states (unchecked, hover, checked) -- so it became an unusable input without images. We've since re-factored the markup and script to ensure that the widget works even when images don't load. Instead of positioning the input off the page, we've positioned it directly behind the styled label, so if the label's background image fails, the input remains visible. And because the label and input share a click event, when the user clicks the transparent label over the input, the input updates accordingly.
Demo
When JavaScript is enabled, users see custom input checkboxes and radio buttons as shown below; when users are browsing with JavaScript disabled or with a screen reader, they interact with standard, unstyled input elements.
jQuery CustomInput plugin demo by Filament Group
Markup
We start with basic HTML for each input that follows web standards conventions:
- assigned a unique id and value to each input
- paired the input with a label element
- included a "for" attribute on each label that references the preceding input's id
Each radio button input also needs a common name attribute to group it with a set.
<form>
<fieldset>
<legend>Which genres do you like?</legend>
<input type="checkbox" name="genre" id="check-1" value="action" />
<label for="check-1">Action / Adventure</label>
. . .
</fieldset>
<fieldset>
<legend>Caddyshack is the greatest movie of all time, right?</legend>
<input type="radio" name="opinions" id="radio-1" value="1" />
<label for="radio-1">Totally</label>
. . .
</fieldset>
</form>
Pairing the inputs and labels correctly is essential to how this plugin works. As stated in the HTML spec, "When a LABEL element receives focus, it passes the focus on to its associated control." Browsers have standardized this behavior so that when you click a label, the click is passed on to the input — in other words, the label and input act as a single element when marked up this way. Because we don't have to interact with the input directly, we can hide it from view with CSS and apply styles to the label to make it look like a customized checkbox or radio button.
When the page loads, the plugin script finds each input/label pair and wraps it in a div. Each wrapper div is assigned a class to it based on the type of input it contains:
<div class="custom-checkbox">
<input id="check-3" type="checkbox" value="epic" name="genre"/>
<label class="" for="check-3">Epic / Historical</label>
</div>
Styles
First, we absolutely positioned the input and label pair so that we could layer the label over the input, like a mask. For this to work, we relatively positioned the wrapper div to contain the input and label:
/* wrapper divs */
.custom-checkbox, .custom-radio { position: relative; }
/* input, label positioning */
.custom-checkbox input,
.custom-radio input {
position: absolute;
left: 2px;
top: 3px;
margin: 0;
z-index: 0;
}
.custom-checkbox label,
.custom-radio label {
display: block;
position: relative;
z-index: 1;
font-size: 1.3em;
padding-right: 1em;
line-height: 1;
padding: .5em 0 .5em 30px;
margin: 0 0 .3em;
cursor: pointer;
}
Next, we styled each type of label (checkbox and radio button) with a background image — we used an image sprite for all states: default, hover, and checked:
.custom-checkbox label {
background: url(images/checkbox.gif) no-repeat;
}
.custom-radio label {
background: url(images/radiobutton.gif) no-repeat;
}
And added classes for hover and checked states that repositioned the background sprite accordingly. We also included a class for the "focus" state for keyboard users.
.custom-checkbox label, .custom-radio label {
background-position: -10px -14px;
}
.custom-checkbox label.hover,
.custom-checkbox label.focus,
.custom-radio label.hover,
.custom-radio label.focus {
background-position: -10px -114px;
}
.custom-checkbox label.checked,
.custom-radio label.checked {
background-position: -10px -214px;
}
.custom-checkbox label.checkedHover,
.custom-checkbox label.checkedFocus {
background-position: -10px -314px;
}
.custom-checkbox label.focus,
.custom-radio label.focus {
outline: 1px dotted #ccc;
}
Script
Because the label-input association takes care of clicking the hidden input for us, we only had to write a really simple jQuery plugin that appends a class to each input on hover, on focus, and on click:
jQuery.fn.customInput = function(){
$(this).each(function(i){
if($(this).is('[type=checkbox],[type=radio]')){
var input = $(this);
// get the associated label using the input's id
var label = $('label[for='+input.attr('id')+']');
//get type, for classname suffix
var inputType = (input.is('[type=checkbox]')) ? 'checkbox' : 'radio';
// wrap the input + label in a div
$('').insertBefore(input).append(input, label);
// find all inputs in this set using the shared name attribute
var allInputs = $('input[name='+input.attr('name')+']');
// necessary for browsers that don't support the :hover pseudo class on labels
label.hover(
function(){
$(this).addClass('hover');
if(inputType == 'checkbox' && input.is(':checked')){
$(this).addClass('checkedHover');
}
},
function(){ $(this).removeClass('hover checkedHover'); }
);
//bind custom event, trigger it, bind click,focus,blur events
input.bind('updateState', function(){
if (input.is(':checked')) {
if (input.is(':radio')) {
allInputs.each(function(){
$('label[for='+$(this).attr('id')+']').removeClass('checked');
});
};
label.addClass('checked');
}
else { label.removeClass('checked checkedHover checkedFocus'); }
})
.trigger('updateState')
.click(function(){
$(this).trigger('updateState');
})
.focus(function(){
label.addClass('focus');
if(inputType == 'checkbox' && input.is(':checked')){
$(this).addClass('checkedFocus');
}
})
.blur(function(){ label.removeClass('focus checkedFocus'); });
}
});
};
Usage
Simply call the customInput() method on any input element or group of elements (more on using jQuery):
$('input').customInput();
Download the code
This plugin script requires jQuery's core library, available for download at jquery.com or link directly from Google's code repository. Download the plugin script, customInput.jquery.js, and feel free to use it in your projects (it's dual licensed under the MIT and GPL open source licenses; refer to author's notes).
Enjoy our blog? You'll love our book.
For info and pre-order: Visit the book site
Comments
I like this approach for radios & checkboxes customization, it seems to be very lightweight, however i noticed that the checkboxes need a different visual state whenever they’re focused, which is necessary when you want to control them with the keyboard.
Comment by Jonathan Vitela on 07/02 at 06:16 AM
Nice rendering (should i say as always
), hope to see something like that integrated in jquery-ui in a near future to get this consistent with ui-themes.
As a side note it would be nice to also add a different background for checked input when they’re hovered.
Comment by malko on 07/02 at 06:23 AM
Filament Group has done it again! Nice work.
Comment by Marc Grabanski on 07/02 at 07:49 AM
These custom inputs are pretty. I agree with Jonathan Vitela to add a different visual state to checkboxes and radio buttons when focused via the keyboard. Good job!
Comment by Rubens Mariuzzo on 07/02 at 08:00 AM
@Jonathan @Rubens Good feedback. The keyboard focus feedback is now updated to be lot clearer now—we added a dotted outline and flip the form element to the hover state.
Comment by Todd (Filament) on 07/02 at 09:18 AM
Very nice, simple. Good effort.
Comment by redsquare on 07/02 at 09:34 AM
I opened up Firebug and changed one of the labels to be multiple lines. I thought I would try it out since I’ve had issues in the past with multiple lines and using sprites for the different states. Having long labels may be an edge case but, I think, should also be accounted for.
Screenshot: http://screencast.com/t/Jvse61XPO
Apart from this, your method seems to be the best that I have used or found elsewhere. Good work!
Comment by Tony on 07/02 at 10:03 AM
Thanks Tony,
That’s definitely something to watch out for any time you’re using sprites. If you need this technique to work with really tall labels, the easiest way to “fix” it would be to space out the sprite images far enough to accommodate the label height, but of course that will always come with limitations. You cold also make the sprite horizontally spaced instead if that fits your design.
The other way would be to use jQuery to append a span element to the label, and then you could style that span with a width and height that will never grow, and put the background image on it instead of the label. This approach is more bulletproof I suppose, but we wanted to be as unobtrusive as we could with this script, so we decided against markup additions.
We may update this with a taller sprite though when we get time.
Comment by Scott (Filament) on 07/02 at 10:16 AM
Top notch once again guys! Great work!
Comment by Jonathan Sharp on 07/02 at 10:17 AM
@Tony We just tweaked the image sprite to add an extra 100px between icons. Like Scott said, this approach isn’t as bullet-proof as adding an extra element for the icon but we like the simplicity in this case. The extra spacing should cover most reasonable cases and you can always adjust as needed for your project.
Comment by Todd (Filament) on 07/02 at 01:21 PM
Awesome! I’m glad to see that you guys are so open to and quick to respond to feedback. In my current job, I have learned that you can never make any assumptions about data (especially the length of text and such). Thanks for your great work.
Comment by Tony on 07/02 at 01:26 PM
Looks good, but it presents an inconsistent user experience when a checked input is hovered over (or tabbed to) - i.e. it requires a new, additional state which represents checked AND hovered, which should show the green (hover) border around the input, in addition to the check mark / dot.
Please implement this.
Comment by Marcus Tucker on 07/05 at 02:10 PM
If the browser can not display images or they are off then inputs will be inaccessible. The checkbox and radio button will not be visible.
Comment by Cezary Tomczyk on 07/11 at 09:51 AM
Very nice! This is similar to the project Uniform (http://pixelmatrixdesign.com/uniform/demo/demo.html). Any plan to support changing file inputs?
Comment by Matthew Irish on 07/22 at 10:35 PM
What do you think of these modifications to the jquery plugin?
jQuery.fn.customInput = function() {
$(this).each(function(i) {
var input = $(this);
var radio = input.is(’:radio’);
// get the associated label using the input’s id
var label = input.next(’label’);
// necessary for browsers that don’t support the :hover pseudo class on labels
label.hover(
function() { $(this).addClass(’hover’); },
function() { $(this).removeClass(’hover’); }
);
if (input.attr("checked")) label.addClass(’checked’);
if (radio) {
// find all inputs in this set using the shared name attribute
var otherRadiosInGroup = $(’input[name=’ + input.attr(’name’) + ‘]’).not(’#’ + this.id);
input.click(function() {
otherRadiosInGroup.next(’label’).removeClass(’checked’);
label.addClass(’checked’);
});
}
else {
input.click(function() {
label.toggleClass(’checked’);
});
}
input.focus(function() { label.addClass(’focus’); })
.blur(function() { label.removeClass(’focus’); });
});
};
Comment by Gabriel on 07/25 at 02:04 PM
I love this idea… I extended it by getting rid of the div wrapper around the inputs. Now you only need the standard markup without any classes. You can check out a demo here:
http://www.paradimeweb.com/skinInput/
Please let me know what you think?
Thanks guys,
Comment by Gabriel on 07/25 at 03:33 PM
Wonderful. I second the request to have this integrated into jQuery UI for theme support. It’s easy enough to approach this solution using existing classes for checkboxes but the lack of rounded-corners support in IE makes it difficult to do for radio buttons. Full-fledged glyphs would help out a lot (and require less markup/DOM manipulations)!
Comment by Ken Browning on 07/30 at 05:01 PM
Nice.... very nice!!!
Tks
Comment by Vinidog on 08/02 at 10:21 PM
This is absolutely great. Thank you so much for working this out.
Fileuploads and normal Textfields seem to be the only basic things missing in the for stylable themeroller compatible form elements.
Comment by tronics on 08/09 at 04:20 PM
Just wanted to send a thanks to Filament Group for creating such an easy to use plugin.. and Gabriel for simplifying it even further. It is working for me like a dream so far!
Comment by Monica LaCasse on 08/10 at 11:22 AM
The heading of the article is misleading, this method of checkbox replacement is not accessible.
Comment by michael on 08/14 at 01:51 AM
The code is really nice though - I think all it would need to become accessible is to move some of the css to be added by the plugin itself, that way if script is off the normal checkbox/radios just come up.
For anyone looking for a similar but accessible solution try
http://plugins.jquery.com/project/radiobutton-checkbox-replacement
Comment by michael on 08/14 at 01:55 AM
@michael: Could you explain a scenario where this widget is not accessible? It makes use of the native HTML input (check/radio) element, positioned out of view, so users on assistive technology actually interact with the input itself rather than other markup acting as a proxy to that input. It appears to be somewhat similar to the technique you linked to above, except we’re just toggling classes on the label element based on the state of the input itself (instead of using an extra span). As far as we can tell, this is completely accessible, and we’ve tested on a couple screen readers to make sure (but please let us know what you’ve found).
As mentioned in the comments above, one scenario where accessibility may be compromised would be for visual users who have images disabled, because the background images are necessary for the visual user experience. We have updated the script locally to fix this issue by positioning the input directly behind the image icon. That way if the image fails to load, the native input can be used in its place. When we get time, we’ll try to update this article with that revised script.
In general though, we’re curious where you think this widget may cause problems with accessibility, so please let us know! Thanks.
Comment by Scott (Filament) on 08/14 at 09:23 AM
@Scott
Other than the situation you spoke off there is one more.
When javaScript is turned off the radio and checks are positioned off stage and your just left with some round and square boxes with no functionality. I like the updated method you speak of and although I have not seen this yet I think it may act the same when javascript is off.
A quick fix for the updated script could be.
Remove this from the css ‘.custom-radios label’ class
background: url(check-radio.gif) no-repeat 0 0;
at beginning of script
$(’.custom-radios label’).css({’background’ : ‘url(check-radio.gif) no-repeat 0 0’});
This way if javaScript is turned off the images wont even load and you’ll get normal check and radios that function.
What do you think?
Comment by michael on 08/18 at 07:26 PM
@ michael: oh. That’s odd. Thank you for pointing out that the classes are in the markup at page load. These should definitely be added with JS so there’s a distinct difference in experience when JS is unavailable.
We’ll try to upload the new script as soon as we can!
Comment by Scott (Filament) on 08/19 at 08:55 AM
Thanks again to everyone for the helpful feedback! We just posted an update to the plugin script and CSS that fixes a problem mentioned by Cezary Tomczyk—the widget as we had originally structured it failed when images weren’t present. So we re-factored the script to work whether or not images load. And, to Michael’s point, we also made sure that the classes to position the inputs are applied by the script, not written into the markup served with the page, so that they remain in place when JS isn’t available. Check out the updated article for details.
Comment by Maggie (Filament) on 08/19 at 03:23 PM
Awesome this is now perfect by well… my standards. Thanks for taking the comments/suggestions on board, and posting an updated script.
Comment by michael on 08/19 at 06:47 PM
when the checkbox is INSIDE the label, this script kills both :S
Comment by Luka Kladaric on 08/20 at 04:46 AM
@Luka Kladaric: I can imagine a few cases where nesting inputs in labels would simplify the markup or a related script, but we avoid marking up forms that way for a few reasons:
* semantically it doesn’t make sense for an input to be a child of its label,
* the “for” attribute associates labels to their form fields, so nesting really isn’t necessary, and
* it’s easier to style them as separate elements
For these reasons we don’t plan on updating the script to work with nested input/label pairs, but feel free to update it to suit your project—it’s open source under the MIT and GPL licenses.
Comment by Maggie (Filament) on 08/20 at 09:12 AM
for some reason, <input type="checkbox" checked="” /> will be detected as “checked” by your plugin.
Strictly speaking, it should be checked either as:
<input type="checkbox" name="vehicle" value="Car" checked="checked" />
or
<input type="checkbox" name="vehicle" value="Car" checked />
The following should not be checked:
<input type="checkbox" name="vehicle" value="Car" checked="” />
Comment by pixeline on 08/20 at 11:21 AM
Hey
What should I do to have the inputs horizontally aligned instead of vertically?
Thanks in advance
Comment by RS71 on 08/20 at 02:21 PM
@Maggie: okay, thanks for the clear response.. I do think it should work, or at least skip and not mangle the mentioned case, but it’s still a great plugin as-is
Comment by Luka Kladaric on 08/20 at 04:16 PM
@ luka.
The powers in your hands. Just apply a class to the elements that you either want or don’t want to have this functionality applied and update the script call accordingly.
@RS71 -
remove display:block; and add float:left; to the below class
“.custom-checkbox label, .custom-radio label”
I haven;t tested it but should be ok and get you started.
Comment by michael on 08/24 at 11:11 PM
@pixeline: the behavior you’re seeing—where inputs with the checked attribute set to checked="” are showing up as checked—is actually standard browser behavior, it’s not the plugin. We agree that logically checked="” should register as unchecked, but apparently browsers only look for the presence of the attribute (we think this may be the case because it only accepts one value). It looks like the safest bet is to make sure there are no empty checked="” attributes in your code.
Comment by Maggie (Filament) on 08/28 at 10:15 AM
First of all, thank you for the script. It’s small and flexible. I minimized the script and css, because I only need radio button. And made some changes. If anyone wants these. Here it is:
Screenshot: http://yfrog.com/9hcustominputg
Source: http://jump.fm/SMERO
Comment by Sevil YILMAZ on 08/28 at 06:34 PM
Hello.
Your script does not work in Internet Explorer 8, if the attribute name is array
look:
<input type="checkbox" name="elementname[key1]" />
<input type="checkbox" name="elementname[key2]" />
<input type="checkbox" name="elementname[key3]" />
<input type="checkbox" name="elementname[key4]" />
Write about it in the documentation or fix the bug, so people do not suffer.
Comment by Anton Kulakov on 09/15 at 02:40 AM
@Anton: If there is indeed a conflict with array-like name attribute values and this script, we welcome you to comment with a patch. Otherwise, when we have time, we will take a look and see if it’s something we can work around.
I understand that the practice of structuring name values in this manner is at least somewhat common among developers, but do you think the issue may have to do with IE8 itself and its conformance to the doctype you’re using? For example, the HTML 4 recommendation specifies which characters are allowed within a name attribute’s value, and that limited character set does not include square brackets. I’m not sure about other doctypes, but before we spend time on it, we’d appreciate if you could make sure the issue is actually a bug in our script, and not just the implementation in IE8 (however proper or quirky that may be).
And again, patches and constructive feedback are always appreciated.
Comment by Scott (Filament) on 09/15 at 09:15 AM
Nice Job Guys. Excellent and works great in I.E 6
Comment by Trevor Saint on 10/19 at 06:00 AM
Very Nice!! and just read in the Comments that it even works in IE6!! fantastic
Comment by Greg on 10/21 at 10:38 AM
Impressive option for forms. Thanks for putting all of this together and sharing. Much appreciated.
Comment by Jon Livingston on 10/21 at 10:42 AM
Nice script.
One thing I did notice is that the the skinned inputs don’t reflect any changes made to the values of the input fields using JavaScript.
Simple use case, I may have a form containing two radio options - “Schedule a Payment” or “Pay Now”. One of these options has an additional field associated with it where the user can enter a date or something.
If a user clicks the date field and inputs something, I want to auto-select the appropriate radio button for the user. With this script applied, this is not reflected to the user.
Perhaps a listener on the state of original input would be a good idea?
Comment by Chris on 10/21 at 01:05 PM
Adding this additional Event listener seems to solve my problem:
input.change(function(){
if (input.is(’:checked’)) {
if (input.is(’:radio’)) {
allInputs.each(function(){
$(’label[for=’+$(this).attr(’id’)+’]’).removeClass(’checked’);
});
};
label.addClass(’checked’);
}
else { label.removeClass(’checked checkedHover checkedFocus’); }
});
Of course, when changing elements via JavaScript, you need to remember to trigger the change event.
Comment by Chris on 10/21 at 01:18 PM
Wow, this is one of those techniques which are clearly, radiantly, fantastically useful. Thank you for the write-up.
Comment by Jeremy Carlson on 10/22 at 10:46 AM
FAIL - Come on guys, I tried to tab through the page, and it got it wrong on the radio buttons. It tabs straight to the selected button and then off the form. How has this been tested for accessibility?
Comment by terry t on 10/22 at 04:39 PM
@terry t: It seems you have a problem with native form behavior, as we didn’t do anything but style the checkboxes and radios; both sets of inputs rely on their native keyboard functionality. In Firefox, for example, you can tab between checkboxes because each one accepts a value, but you can only tab *to* a set of radio buttons because the entire set only accepts a single value. To make a radio button selection, you have to use the arrow keys after you’ve tabbed into the set. Try turning off JavaScript and you’ll see that our example page works the same way whether the inputs are enhanced with styles or not.
Comment by Maggie (Filament) on 10/22 at 04:55 PM
Beautiful work guys.
Odd behaviour though in IE7: the page is long and has a lot of checkboxes. Clicking on the last one brings the focus on top page, scrolling abruptly upwards in one shot.
Doesnt do so if I disable the .custom-radio input attributes in the CSS (I believe absolute positioning could be the problem).
Comment by Manaus on 10/23 at 07:03 AM
@Manaus
I have been having the same problem, haven’t had a chance to look at the javascript to see why its doing that if something isn’t posted up sooner than i figure something out ill post a response!
Comment by Matt on 10/30 at 01:11 PM
Follow up i fixed the IE 7 bug for me by removing position: absolute; from .custom-checkbox input, .custom-radio input, and adding left: -20px to custom-checkbox label, .custom-radio label. This seems to have solved the issue for me.
Comment by Matt on 10/30 at 01:20 PM
Nice Job, Nice script ---- But… It doesn’t play well with others...... Incorporating this into pages using slideToggle produces less than desirable results in IE 6,7,8.
Specifically, this is more of a slideToggle issue with nested elements using position: absolute etc.... But it makes this wonderful tool - useless
Comment by Kevin on 11/19 at 10:04 AM
Great script! I do have 1 question regarding the radio button styles. Is it possible to have each of the radio buttons have a different style? For example: 1st Radio has a Green Check and the 2nd Radio has a Blue Check?
Comment by Stephen on 12/17 at 12:05 PM
@Stephen: sure, you can apply whatever classes you’d like to the labels to style them as you need.
Comment by Scott (Filament) on 12/17 at 12:10 PM
@Scott Thanks for the prompt response. I want to use 2 different background images for the .custom-radio label style. Without making a large amount of changes to your jQuery code I don’t see this being possible. Am I missing something here? Thanks!
Comment by Stephen on 12/17 at 02:35 PM
@Scott figured it out, thanks!
Comment by Stephen on 12/17 at 03:58 PM
thanks!
Comment by yyj on 12/29 at 09:25 PM
just a small bug report… line 63 should be:
label.addClass(’checkedFocus’);
Comment by Joshua Jabbour on 01/10 at 02:15 PM
I came across this after trying to solve a problem with my own similar solution. In my HTML, the text of the label is hidden so the user toggles the checkbox by clicking the “image” (really the label with a background image). The label contains a span that is hidden if images are on.
This works dandy in Safari, Chrome, etc., but in Firefox, clicking again after the first click highlights the text of the label rather than toggles the checkbox. Obviously, this makes my label-less button pretty much unusable in Firefox.
I noticed this is happening in your demo (I also replaced my script with yours to see if there was something I’d missed - same issue) as well. I feel like I solved this recently - the Firefox-selecting behavior - but can’t for the life of me remember how. Any thoughts?
Comment by Jennie on 01/11 at 08:44 PM
Great job, thanks for this code.
In your example in IE form legend tag has its default color - blue. It seems that IE needs extra color declaration. In Firefox legend color is inherited.
Comment by Krystian on 02/10 at 12:20 PM
thanks for this script. I found a problem though when radio fields have names like radio[id]. Fixed it enclosing line 26 with double quotes:
var allInputs = $(’input[name="’+input.attr(’name’)+‘“]’);
Comment by rachel on 02/15 at 06:19 AM
I’d like to rebut your statement, “Styling checkbox and radio button inputs to match a custom design is nearly impossible...”
I have come up with a pure CSS solution for styling radio and checkboxes, http://www.thecssninja.com/css/custom-inputs-using-css
Comment by Ryan Seddon on 02/19 at 01:45 AM
@Ryan: Thanks, that’s an interesting technique, and it’s similar to ours in that you’ve found a workaround to avoid styling the actual inputs (though yours doesn’t use any JS, which is nice). We usually aim to figure out a solution that works across all the common browsers. The CSS selectors you’re using won’t work in any versions of Internet Explorer, will they?
Comment by Scott (Filament) on 02/19 at 08:14 AM
Why is this no widget in jquery ui? I think, styling forms and make them look the same in all browsers is the most common wish for all developers.
Comment by Oliver on 03/09 at 06:15 AM