[Solution]: element access problem when only a single radio button defined

Kor's AvatarKor: When you have a single radio button, the classical reference return, logically, a single element, not a collection. A single element has no length property. For instance, give a textbox a name, than try to find its length property. You will get undefined, logically. Same with a single radio button.

DOM method getElementsByName() returns always a collection, thus this is the reason for DOM method works, classical form’s elements reference don’t.

once again: getElementsByName() returns always a collection, thus it has always a length property, very much alike an array. Now if you have a single element with a certain name refered by getElementsByName() it is the same as you would have an array with a single element.

This is the reason for you need always an index when using getElementsByName() to refer a certain element.

Classical reference


is ambiguous. It returns a collection if there are more than one element, but it returns the element itself when there is no other element with the same name.

<html lang="en">
<title>Radion Test</title>
<script language="javascript" type="text/javascript">
function radio_test(){
     var str= "1. document.forms['dummy'].elements['single'].length=\n\t"+
     "\n\n2. document.forms['dummy'].elements['single'].type=\n\t"+
     "\n\n3. document.getElementsByName('single').length=\n\t"+
     "\n\n4. document.getElementsByName('single')[0].type=\n\t"+

     return false;
<form name="dummy" action="" onsubmit= "return false">
        <fieldset><input type="radio" name="single" >
        <input type="submit" value="submit" name="submit">

Quoted: http://www.webdeveloper.com/forum/showthread.php?t=184376

Saying Goodbye to the overflow: hidden Clearing Hack


I’ve been thinking of this for a while now, and it’s finally time to part ways with the overflow: hidden (and overflow: auto) clearing hack. Jeff Starr’s recent and excellent post – The New Clearfix Method – and the ensuing comments were enough to finally prompt me to write about it here. (And since I started writing this, Jonathan Snook has started a Twitter dialog about overflow vs. clearfix).

While the clearfix method is a tried and true hack, I’ve always disliked muddying up my HTML markup with crufty “clearfix” classes strewn about. So I ended up using overflow: hidden as much as I could. But overflow: hidden is not without its drawbacks. Although there is no extra class to apply in the HTML (win!), there may be situations when you want to have child elements positioned partially (or entirely) outside of their overflow: hidden wielding parent (or other ancestor) container. In these cases, the container with overflow: hidden will clip the element that you’re trying to partially (or entirely) position outside of it. (Case in point: If you use suckerfish dropdowns, try setting overflow: hidden on the outermost list).

So although overflow: hidden is not usable in all situations, I used to prefer it over using the “clearfix” class method. But in reality I ended up with both: I had overflow: hidden where I could get away with it, and “clearfix” classes where I couldn’t use overflow: hidden. It bothered me a bit to mix and match two different clearing methods, but I was happy to have fewer “clearfix” classes violating my otherwise semantic markup Kumbaya festival.

Then in his presentation at An Event Apart 2008 in San Francisco, Dan Cederholm suggest using the class name “group” rather than “clearfix” – a suggestion which later made it into his book Handcrafted CSS. It’s a minor thing, but I do like the improved semantics (in most cases) of the “group” class name over the “clearfix” class name, so I adopted this approach and felt okay about using it as a fallback when overflow: hidden wasn’t feasible.

In his talk and in his book, Cederholm also walks through the “big long list” idea of applying the rules for the clearfix (renamed to “group”) class directly to the selectors that need them in the CSS.

Big Long List

This keeps the HTML more pure while avoiding the drawbacks of overflow – a total win-win. But it does mean extra bloat in the CSS. Probably okay for smaller sites, but it can quickly get unruly with larger sites. I tried this approach on a few projects and decided the CSS bloat was indeed too much, so I stuck with the mix of overflow: hidden and the “group” class.

The Catalyst

But I’m now saying goodbye to overflow: hidden and the deciding factor for me is CSS3. Specifically box-shadow. At least in the sense that box-shadow was the first property I noticed being negatively impacted by the use of overflow: hidden. Like the positioned child elements mentioned above, box-shadow can get clipped when the parent (or other ancestor) element has overflow applied.

And there are several other things to consider as we move forward using more CSS3. Text-shadow and transform can also potentially be clipped by overflow: hidden (see the demo).

Example of overflow:hidden clipping a box-shadow

As we rely more and more on CSS3 properties we can rely less and less on overflow as a clearing method. So I’ll be abandoning overflow and relying upon clearfix (Jeff Starr edition) via a mix of the “.group” class in the markup and the “big long list” approach.

Suggested Reading

Quoted from: http://fordinteractive.com/2009/12/goodbye-overflow-clearing-hack/