Web Form Elements Design Quiz, Part 1: Radio Buttons and Width Property

Browser development is active.

Along with Opera and Firefox, there have been two versions of IE within the three years along with Google’s new browser, Chrome.

These new developments in browsers are leading to some long desired features in browsers like opacity, auto-generated content and (maybe) embedding typefaces.

However there is still an unresolved issue with browsers: Web form elements are inconsistently rendered.

While anyone can see that there are problems with how forms are rendered, the question is, “what is the best way to render for elements for a given form element and CSS property?”

Along the lines of Dan’s SimpleQuiz series, I figured it’s best to ask the Web design and development community for their opinions.

Hopefully this discussion will lead to the appropriate solution that browser vendors could use when programming how browsers should handle the CSS-enabled design of Web form elements.

The first question I would ask is one that I think shows readily the problem with Web form design:

How should browsers render radio buttons when a value for width of a certain length is applied?

Pick your answer from the sample answers (which are taken from actual browser renderings) or suggest your own solution!

A. Radio buttons stretch to the size of the width property value.

fmtag-inputradio-width-ffx2-mac.png

B. Radio buttons do not resize, yet the space set by width property is applied and the radio buttons are aligned to the left.

fmtag-inputradio-width-sf3-mac.png

C. Radio buttons do not resize, yet the space set by width property is applied and the radio buttons are aligned to the center.

fmtag-inputradio-width-chrm-pc.png

D. Nothing happens.

fmtag-inputradio-width-ffx3-mac.png

4 thoughts on “Web Form Elements Design Quiz, Part 1: Radio Buttons and Width Property

  1. To me both A and D seem right, the underlying question is what a browser should render as a radio button. In A the browser (Fx2) seems to have its own radio button, with its own specific styling rules which means that they are free to apply whatever CSS they find necessary to it.

    All other choices apart from A however use the radio button provided by the OS—assumed you’re running Vista or 7 as your Windows version. I find this to be the better way, for the overall usability it is good when as many programs default to the same input-elements. When doing this however you should also stick to the styling guidelines of the OS. Not changing the size when only a width is given sounds right here.

    Arguable you could say that wit only a width given the element could scale to a bigger/smaller size keeping the same height:width-ratio. This could work much like image elements and would then stick to the OS specific looks. But if you really want to find the answer to this you will have to look it up with the OS developers.

    Either follow the OS in the ways of manipulating their own form-elements or design your own form-elements (when designing your own these should *not* fake the OS elements!) Going halfway with it and mis-styling the OS radio buttons is wrong because these were not designed to have CSS applied to them and CSS was never created to manipulate OS elements.

  2. In order to maintain consistency with the operating system I think that those elements shouldn’t be resizable in anyway.

    However, in order to properly align them in the center or left, one would require additional markup in order to position them like B or C.

    If the code were to act in an optimized manner, I think the best solution would be a mix between B and C where the position of the button itself could be defined by text-align.

  3. Ah, this takes me back a couple of years. Well, nearly:

    http://meyerweb.com/eric/thoughts/2007/05/15/formal-weirdness/

    Good luck with this—seriously. Form elements are, as I wrote, really fiendishly difficult to describe in CSS terms, with occasional forays into the likely impossible. From what I can tell, you’re pretty much going to have to invent new ways of describing elements just to recreate expected default behaviors, let alone do new stuff. I think the WebKit team has implicitly done just that with some of their new form-styling properties and values.

    I vote “D”, by the way, but then I’m not a designer.

  4. 😀
    A — No… Adhering to any sort of UI guidelines, no one should be allowed to stretch apart radio buttons. It looks wrong and in my eyes can be safely and generally discarded as such.
    B — Makes most sense. Leave button as is, consider the width but apply a standard alignment.
    C — Why center? I mean, yes… why left on B? But if there was ever a thing such as “default styling”, it would be left (or even right in some areas of the world), but not center.
    D — Quite okay except for the fact that this introduces inconsitent styling across multiple browsers. Should at least keep the boxmodel, even if it has no defined or standardized behavior.

    I go for B.

Leave a Reply

Your email address will not be published. Required fields are marked *