See the Demo

The demo is made of three snippets:

The HTML:

<div id="demo">
<p>All of these lines will have different font sizes.</p>
<p>This is because we have set the white-space property of the p tags to "pre."</p>
<p>This means that these lines won't wrap, and because they won't ever wrap, when the page loads,</p>
<p>The JS will attempt to fit the spans inside the p tags. Of course, this could be done with p tags inside of divs.</p>
</div>

The CSS:

#demo p{
white-space:pre;
}
#demo {
width:600px;
}

And the JS magic that fits a span into every p tag and then scales the font by percents.

<script type="text/javascript">
jQuery("#demo p")
    .contents()
    .filter(
        function(){
            return this.nodeType != 1; 
        })
    .wrap("<span/>").parent().each(
	function(){
		var size = 100;
		while(jQuery(this).parent().width() < jQuery(this).width() && size > 5){
			size -= 1;
			jQuery(this).css({'font-size' : size+'%'});
		}
	}
);

</script>

Even more importantly, inline JS is never run when embedded <script> tags are used with the innerHTML command. The following JavaScript function fixes both problems by eval’ing the content of the <script> tags and replacing the default document.write with a new function that replaces the inline JS with the output of the document.write function.

The Code

function executeJS(i){ // Pass an element ID to the function.

	var e = document.getElementById(i); 
	var Reg = '(?:<script.*?>)((\n|.)*?)(?:</script>)'; //Regex for all content between <script> tags.
	var match    = new RegExp(Reg, 'img');
	var scripts  = e.innerHTML.match(match);

	var doc = document.write; // Store the functionality of document.write temporarily.
	//Overwrite document.write with a new function that takes the innerHTML of the passed element
	//then replaces the <script> tag with the output of the passed content.
	document.write = function(p){ e.innerHTML = e.innerHTML.replace(scripts[s],p)};

	if(scripts) { //if matches
		for(var s = 0; s < scripts.length; s++) { //loop through matches
			var js = '';
			var match = new RegExp(Reg, 'im'); //find first match
			js = scripts[s].match(match)[1]; //inner content of the first match
			eval('try{'+js+'}catch(e){}'); //evaluate the inline JS.
		}

	}

	document.write = doc; //Reset document.write back to its original functionality

}

This example function only outputs the first document.write in a script block, so if you require more than one in your embedded JS, it is trivial to store the output content as a variable.

The Code

function unstrip_array($array){
	foreach($array as &$val){
		if(is_array($val)){
			$val = unstrip_array($val);
		}else{
			$val = stripslashes($val);
		}
	}
return $array;
}

Why would I need to unstrip an entire array?

It’s useful for WordPress Plugin developers or anyone whose scripts might be run on a server with magic quotes enabled. It is also excellent to strip any slashes from $_POST inputs that might confuse your attempts to escape the strings later. Running an array of post data through this will make it easier to ensure that you don’t have hacking attempts.

Why shouldn’t you define the element type?

So even though popular opinion says yes, the real answer is an emphatic no. You should never supply parent elements or element types when defining the ID of an element. Why? The ID of an element is supposed to be unique. While sometimes bad programing styles or unfriendly widgets can cause problems, the ID should always be unique, so there is only one #content_box and it is always going to be a textarea.

What’s the difference?

If you have read the longer post on profiling jQuery, you’ll notice that the fastest method to find any element is to call the #ID of the element directly. Any other call requires jQuery calling Sizzle and parsing the string.

If you use just the ID of an element, it won’t need to load sizzle and can grab it immediately using the built in JS function getElementById('content_box');. The difference of these two expressions is staggering and as my post on profiling JavaScript demonstrated, the difference is an order of magnitude.

I answered this basic question on StackOverflow just from my experience without reading the jQuery source or performing benchmarks. I was actually surprised that not only was my order correct, but also that jQuery functioned much as I expected it to under the hood. The images and explanations are directly from my answer on StackOverflow. All of the benchmark tests can be run from jsFiddle, but wait a bit before you try it out.

All Descendant Selectors in jQuery

Our methods:

1. $(".child", $("#parent")); (by using a scope)
2. $("#parent").find(".child"); (the find() method)
3. $("#parent").children(".child"); (For immediate children, I use this a lot)
4. $("#parent > .child"); (via CSS selector)
5. $("#parent .child");

Ranking the jQuery Selectors

Using a Scope and Find

$(".child", $("#parent")) and $("#parent").find(".child") are identical with the only difference is that method 1 needs to parse the scope passed and translate it to a call to $parent.find(".child").show();.

Let’s take a look into the source to see why this is,

jQuery.fn = jQuery.prototype = {
	init: function( selector, context ) {
	// Handle HTML strings
		if ( typeof selector === "string" ) {
			if ( match && (match[1] || !context) ) {
			[...]
			// HANDLE: $(expr, context)
			// (which is just equivalent to: $(context).find(expr)
			} else {
				return jQuery( context ).find( selector );
			}

The jQuery source tells us two things:

1) method 1 and method 2 are exactly equivalent. If anything, method 2 will be slightly faster.

2) Any other method will be slower because of the large block of if…else statements I removed. Parts of the code will show up later, but basically, if the passed element isn’t an ID and there is no context passed, jQuery has to use regex to try and understand it.

Why you should never use CSS text selectors

$("#parent > .child"); and $("#parent .child"); both need to parse the selector and then just call: $('#parent').children().filter('.child') and $('#parent').filter('.child') respectively.

I never researched it, so didn’t know exactly why this was, but I recently saw this video by Paul Irish where he explains why it takes longer to process this. The answer is long and technical, but the lines I clipped from the jQuery source above basically just look to see if an #id is passed and then grabs that element directly.

When you have a longer CSS selector like $("#parent > .child") jQuery has to load “Sizzle” which is a large and fairly slow CSS-based selectors library. A separate download of Sizzle is only 4KB, but it starts with this beautiful REGEX:

var chunker = 
/((?:\((?:\([^()]+\)|[^()]+)+\)|\[(?:\[[^\[\]]*\]|['"][^'"]*['"]|[^\[\]'"]+)+\]|\\.|[^ >+~,(\[\\]+)+|[>+~])(\s*,\s*)?((?:.|\r|\n)*)/g

Yipes! Chunker is a bit more like clunker if you ask me.

A Quick Note on Using .children() versus .find()

Finally, method 3 will always be the fastest because it uses .children() to do the least amount of work and uses the most direct method to get first-level children.

Profiling the Selectors, Speed test

The difference in perforamnce in the different browsers is staggering. The calculations are in computations per second, so the higher the number, the faster the selector is.

On Chrome, Method 3 is the best then method 1/2 and then 4/5

On Firefox, Method 3 is still best then method 1/2 and then 4/5

On Opera, Method 3 is still best then method 4/5 and then 1/2

On IE 8, while slower overall than other browsers, it still follows the Method 3, 1,2,4,5 ordering.

Overall, method 3 is the overall best method to use as it is called directly and it doesn’t need to traverse more than one level of child elements unlike method 1/2 and it doesn’t need to be parsed like method 4/5

Though, keep in mind that in some of these we are comparing apples to oranges as Method 5 looks at all children instead of first-level ones.

Finally, if you want to read all about profiling and perfomance in jQuery check out this slideshow by Paul Irish. It’s a very useful read if you are just starting to learn how to optimize your jQuery.

The Code

$escapes = array('.','$','^','[',']','?','+','(',')','*','|','\\');

foreach($escapes as $s){
	$r = "\\\\$s";
	$myregexbase = str_replace($s, stripslashes($r), $myregexbase);
}

It’s usage

So what sort of time would you need this script you ask? Suppose, for example, you have a dynamic list of words that need to be replaced in a block of text. Now, you don’t want to replace partial matches (“cat” should not be replaced in the word “catch”), so you need to merge the list of $words with the compete regex.

$escapes = array('.','$','^','[',']','?','+','(',')','*','|','\\');

foreach($escapes as $s){
	$r = stripslashes("\\\\$s");
	$name = str_replace($s, $r, $name);
} 
$needle = '@([^a-zA-Z0-9])('.$name.')([^&a-zA-Z0-9])@';

Why can’t you use a single slash?

The problem is that if you use a single slash it will escape the quote is it wrapped in the problem is with the line $r = "\\\\$s";. If you try to use single quotes around the string, $s is not parsed correctly. If you use $r = '\\\\'.$s; it works fine, but there is no real benefit.

Why the stripslashes? Why not just use $r = '\\'.$s;? Again, it’s a problem with a collision between the generated regular expression and PHP. When you replace the character, the \\ will be taken as a literal \\ rather than an escaped \, so the outputs in the regular expression will interpret the backslash escaped rather than the character that was supposed to be escaped.

Why not use a different hack?

Sure you could use $r = trim('\ ').$s;, but it still just a hack, and it is even less understandable. The one benefit of using \\\\ with stripslashes is that it is easy to understand what is happening. Extra backslashes have been added. They are going to be stripped away. While the actual output might not be entirely clear, the solution is understandable in that the extra slashes are being removed. Overall, the problem is kinda crazy, and the solution is even crazier and makes no sense but it works.

However, the code that was used to create these in firefox is as such.

background: -moz-linear-gradient(bottom, #999, #ccc);
	-moz-border-radius:8px;
	-moz-border-bottom-colors: #ccc #999 #6666;
	-moz-border-top-colors:  #ccc #999 #666;
	-moz-border-left-colors: #ccc #999 #666;
	-moz-border-right-colors: #ccc #999 #666;

The first line creates the gradient inside the button, the second creates the curved borders and the final 4 lines create a border gradient 3px wide. The CSS above won’t work exactly as expected because you need to separately define a border that has the same width as the number of colors, so the entire .toggle class looks like:

.toggle{
	color:#333;
	font-size:1.1em;
	height:31px;
	width:86px;
	border:3px solid #ccc;
	/*//mozilla*/
	background: -moz-linear-gradient(bottom, #999, #ccc);
	-moz-border-radius:8px 8px 8px 8px;
	-moz-border-bottom-colors: #ccc #999 #6666;
	-moz-border-top-colors:  #ccc #999 #666;
	-moz-border-left-colors: #ccc #999 #666;
	-moz-border-right-colors: #ccc #999 #666;
}

The .toggled class is:

.toggled{
	border:2px solid #333;
	background: -moz-linear-gradient(bottom, #AAA,#999);
	-moz-border-bottom-colors: #333 #999;
	-moz-border-top-colors:  #333 #999 ;
	-moz-border-left-colors: #333 #999 ;
	-moz-border-right-colors: #333 #999;
}

And since a hover class increases usability:

.toggle:hover{
	background: -moz-linear-gradient(bottom, #AAA, #EEE);
	-moz-border-bottom-colors: #aaa #ccc #999;
	-moz-border-top-colors:  #aaa #ccc #999 ;
	-moz-border-left-colors: #aaa #ccc #999 ;
	-moz-border-right-colors: #aaa #ccc #999 ;
}

This is not a Google Chrome or IE bashing post, instead of leaving it entirely in CSS and having it degrade in all other browsers to some extent, I took a screenshot and replaced all the CSS with a CSS sprite.

.toggle{
	
	color:#333;
	font-size:1.1em;
	background: url('./style/images/button.toggle.png') no-repeat 0 0;
	height:31px;
	width:86px;
	border:0;
}

.toggled{
	background-position:0 -31px;
}

It was actually easier to design the button in Firefox than in something like photoshop especially since I used the WebDeveloper toolbar to write the CSS in the browser itself.

Disclaimer

Please back up your database before using this. I claim no credit if you copy in the new or old website URLs wrong and/or create a sitepocolypse. A couple notes, if you have changed your WordPress prefix, you will need to replace all of instances of “wp_” in the MySQL search and replace code above.

How you do it.

update wp_options set option_value = replace(option_value,'http://OLD_WEBSITEURL.com','http://NEW_WEBSITEURL.com');
update wp_postmeta set meta_value = replace(meta_value,'http://OLD_WEBSITEURL.com','http://NEW_WEBSITEURL.com');
update wp_posts set post_content = replace(post_content,'http://OLD_WEBSITEURL.com','http://NEW_WEBSITEURL.com');
update wp_posts set guid = replace(guid,'http://OLD_WEBSITEURL.com','http://NEW_WEBSITEURL.com');
update wp_posts set pinged = replace(pinged,'http://OLD_WEBSITEURL.com','http://NEW_WEBSITEURL.com');
update wp_comments set comment_content = replace(comment_content,'http://OLD_WEBSITEURL.com','http://NEW_WEBSITEURL.com');

More Disclaimers

Most importantly, DO NOT add a trailing slash to either the old or the new URL. Sometimes it will be there (for example, in a link to “yoursite.com/somepage”) and others it won’t such as in the WordPress siteurl and home options.

Finally, the simple search and replace will replace strings inside serialized arrays. So if you use a plugin that stores the site’s url in it’s own plugin option array (I know cForms does), it will break all the options you have set. Plugins should never store this information, so if you find a plugin that does, you should contact its author and suggest they modify this behavior. However, there are ways around this for people who run test servers.

Running test servers easily if they are on localhost

Rather than having http://aahacreative.com and http://localhost/aahacreative, wouldn’t it be easier just to have http://aahacreative.dev? Well, that’s how we do things around here, and here is how you can to. (The reason that searching and replacing ahhacreative.com with aahacreative.dev will work is because they have the same number of letters.)

Basically, what you need to do is to add an entry to your hosts file and add a new website in apache. Just follow the instructions. I’ve never tested, but theoretically, you can also edit your hosts file to point to a server with aahacreative.dev.

Someone want to try it and tell me?

Each of the major browsers have their own syntax to implement CSS gradients because it has not been implemented as standard yet.

Webkit (Chrome and Safari) background: -webkit-gradient(linear, left top, left bottom, from(#EFEFEF), to(#FFF));

Firefox 3.6 and above background: -moz-linear-gradient(top, #efefef, #FFF);

Internet Explorer 6 and IE 7 filter:progid:DXImageTransform.Microsoft.Gradient(GradientType=0, StartColorStr='#EFEFEF',EndColorStr='#FFF');

Internet Explorer 8 -ms-filter: "progid:DXImageTransform.Microsoft.gradient(startColorstr=#EFEFEF, endColorstr=#FFF)";

Whether you have noticed it or not, this website has a CSS gradient that goes from #EFEFEF at the top of the page to #FFFFFF. (This gradient is exceedingly subtle and most people won’t notice it consciously, but it helps with visibility and eye fatigue on long posts.) The entire code used is:

.gradient{
	/* For any browser that can't create a gradient  */
	background-color: #EFEFEF;
	/*//mozilla*/
	background: -moz-linear-gradient(top, #efefef, #FFF);
	/* Chrome/Safari 	 */
	background: -webkit-gradient(linear, left top, left bottom, from(#EFEFEF), to(#FFF));
	/*IE ^/7 */	filter:progid:DXImageTransform.Microsoft.Gradient(GradientType=0, StartColorStr='#EFEFEF',EndColorStr='#FFF');
	/*IE 8 */
	-ms-filter: "progid:DXImageTransform.Microsoft.gradient(startColorstr=#EFEFEF, endColorstr=#FFF)";
}

Since each prefixed option is only parsed and understood by only one browser, they can be used in a stack without any incompatibilities or errors. This CSS only covers linear gradients; however, radial and diagonal gradients are possible. Use fancier gradients with care and as much as you may want to, never go from Green to Purple no matter how much you may be tempted.

Beware the Microsoft Filters

As a final note, in all versions of IE, the background gradient can interfere with the way text is displayed. The images below shows what happens in IE if you try to lay text over a background gradient.

This is how the text is supposed to appear.

As soon as the gradient is added, the text becomes blurred. There is no consistancy and it makes the text hard-to-read.

With the gradient and a smaller font, the text looks like it was printed without enough ink.

For this reason, I’ve left AahaCreative without a background gradient in Internet Explorer. It’s a shame, but, hopefully, the IE team will get their acts together for IE 9.

P.S. The image that goes with this post is a screenshot of a CSS-only gradient.