Useful shell script đ
Find files that contain a text string:
grep -lir "some text" * grep -lir "some text" *.php
The -l switch outputs only the names of files in which the text occurs (instead of each line containing the text), the -i switch ignores the case, and the -r descends into subdirectories.
—
Quoted from:Â http://snippets.dzone.com/posts/show/505
Kor: 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
document.formname.elementname
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.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html lang="en">
<head>
<title>Radion Test</title>
<script language="javascript" type="text/javascript">
function radio_test(){
var str= "1. document.forms['dummy'].elements['single'].length=\n\t"+
document.forms.dummy.elements.single.length+
"\n\n2. document.forms['dummy'].elements['single'].type=\n\t"+
document.forms.dummy.elements.single.type+
"\n\n3. document.getElementsByName('single').length=\n\t"+
document.getElementsByName('single').length+
"\n\n4. document.getElementsByName('single')[0].type=\n\t"+
document.getElementsByName('single')[0].type;
alert(str);
return false;
}
onload=function(){
document.getElementsByName('submit')[0].onclick=radio_test;
}
</script>
</head>
<body>
<form name="dummy" action="" onsubmit= "return false">
<fieldset><input type="radio" name="single" >
<input type="submit" value="submit" name="submit">
</fieldset>
</form>
</body>
</html>
—
Quoted: http://www.webdeveloper.com/forum/showthread.php?t=184376
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.
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.
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).
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.
—
Quoted from: http://fordinteractive.com/2009/12/goodbye-overflow-clearing-hack/