My account at Sphinn was deleted today, and many of you are wondering why. Hopefully this email exchange will answer that. I’ll add clarification as needed.

First, I published a new post over at SEOBullshit.com (Google’s Epic Losing Streak). Then I tweeted about it. Then I tried to submit it to Sphinn, but Sphinn was saying it had already been submitted. I didn’t know who this other person was, or how the hell they submitted my post so quickly, but I was annoyed and I contacted Sphinn through their contact form:

From me to Sphinn

Is there any way to prevent this kind of thing?

I just published an article and tried to submit to to Sphinn, but someone beat me to it:

http://sphinn.com/story/141676/

I have a couple of problems with this.

1. My avatar isn’t shown next to the article’s title.
2. The article’s summary was written by someone else, and it’s…not what I would have chosen.

So my first thought was to change my post’s URL, submit the new one, and destroy the old one…but that’s kind of a dick move, at least as far as this girl is concerned. So my question is…

What can I do to take control of my Sphinn listing?

From Matt McGee to me

Matt McGee, who is a punk-ass bitch, responded with this:

Hey Darren,

There are no rules about who can and can’t submit to Sphinn (or any other social voting site). As soon as you publish something, anyone can post it to Sphinn — so I guess the answer to your question is to submit as soon as you hit the Publish button next time.

Matt

It certainly doesn’t sound like anything out of the ordinary, but if you knew the history between me and McGee, you’d realize there are some subtle tones of mockery and condescension between the lines. It was obvious to me that Matt McGee wasn’t going to be helpful, so I submitted my own story using another URL. Then I tweeted about it and several people sphunn the story. The issue was essentially resolved at this point, assuming that whoever submitted the story the first time didn’t care about petty issues like avatars and summaries. However, Matt McGee decided to triple his bitch points by deleting my submission, sphinns and all.

(BTW…at this point, I took the time to investigate the Sphinn user who submitted my post, and I realized it was a lady whom I’m actually fond of and follow on Twitter. So FYI…she’s awesome and I have no hard feelings towards her whatsoever. And yes…this whole  incident probably could have been avoided if I had talked to her about it, but instead I ignored that part and focused on what an annoying bitch Matt McGee is.)

From me to Matt McGee

Then I responded with this:

Who deleted my submission?

From Matt McGee to me

Matt bitchfully responded with this:

You should’ve received an email that says it was deleted because it’s a dupe submission. You can vote on the original here:

http://sphinn.com/story/141676/

From me to Matt McGee

To which I responded with this:

Do you think you’re clever, Matt? Do you think your passive-aggressive bullshit goes unnoticed?

I’m about to kick off a very passionate, very determined smear campaign. I need to know if I’ll be targeting you specifically, or Sphinn in general.

Please advise.

From Matt McGee to me

Then Matt responds with this:

Darren,

I don’t understand the problem. The story is on Sphinn already and you can vote for it now, but you haven’t done so. What am I missing?

…which again sounds like a perfectly normal response, unless you read between the lines…where you’ll discover that it’s really Matt playing dumb and being a bitch again. Plus, to make matters worse, someone from Sphinn told my ex-girlfriend about this entire exchange, presumably with the hope/expectation that she would calm down her psycho ex, and so now I had to explain myself to her…which is always a buzzkill, since she never takes my side.

From me to Matt McGee

So I responded the way any self-respecting psychopath would:

Well, first your developers missed an obvious need for content owners to have the ability to control submissions of their own work. Or maybe they acknowledged the need, but instead opted for the cheaper solution: let the moderators handle it on a case-by-case basis. The point is…I write content to promote ME, just like everyone else does. I wrote the article–I should be able to submit it with MY avatar and MY summary. If you don’t understand why this might be important, let me write the summary for your next submission and I’ll make it clear.

Then after I took the time to contact the Sphinn staff PRIVATELY–per Danny’s request, following my last psychotic episode–you missed the opportunity to take me seriously and basically said “too bad.”

Then I took matters into my own hands and solved the problem myself, by submitting the story under an alias URL. Then I twittered my Sphinn submission’s URL, at which time several people sphunn it. All you had to do…was do NOTHING. Instead, you chose to do things “by the book” and deleted my submission, despite the obvious fact that it was the more-reputable submission of the two…AND despite the fact that it was the only one that had been sphunn several times.

On top of everything, you want to keep condescending me with your smug, passive-aggressive remarks:

There are no rules about who can and can’t submit to Sphinn (or any other social voting site).
You should’ve received an email that says it was deleted because it’s a dupe submission. You can vote on the original here:
The story is on Sphinn already and you can vote for it now, but you haven’t done so.

Why don’t you just call me a retard, Matt McGee?

And finally, you missed a very, VERY important opportunity…and that was the opportunity to NOT get Lisa involved.

So the answer to YOUR question is…

The problem is you went out of your way to piss me off, and now I’m about to go to some seriously-ridiculous extremes to publicly shit all over your name, your reputation, anything you’ve ever published, and every brand you’ve ever been associated with.

Do you understand now?

From Danny Sullivan to me

Matt then crawled under his bed, curled into a fetal position, and began trembling. This is where the situation turned shitty…as Danny Sullivan took it upon himself to butt into the conversation and blindly defend his employee:

Darren, head over to Digg, then find how you can take control of a story someone has submitted from your site to Digg. You can’t. Pick any number of social news sites out there. None of them operate that way.

You absolutely can submit your own story with your own avatar. Nothing prevents you from doing it. It’s simply that in this case, someone else submitted your story before you did. You seem to want the right to rip that submission away from them, so that you could submit it instead.

Well, I can understand that request. I hope you can understand that it’s simply not how social sites have operated. If you were to submit a blog post from Google, would you want Google to have the right to pull the submission away from you.

Frankly, you’re the first person I know of to raise this issue with us. It just doesn’t seem to have been a burning issue with site owners. It’s something we can consider, and I’d welcome you starting a discussion about it in the Sphinn Zone to see what others think.

But before you do that, you need to apologize for your abusive, out of line email to Matt. I’ve read through the entire email thread below. He’s answered your questions politely and matter-of-factly. Your response is to assume he’s got the time to play some absurd passive-aggressive game with you.

He doesn’t. Nor was he. So you can push the reset button with us at Sphinn by apologizing. If you don’t want to do that, we’ll ban your account. You’re free to embark upon whatever smear campaign you want, if that’s going to make you feel better. I’d think you’d have better things to do, especially when no one was attempting to victimize you in any way.

danny

The reason I say things turned shitty is because I personally think Danny’s a nice guy, and I really didn’t want him to get caught in the crossfire between me and that bitch McGee. But much to my disappointment, not only did Danny butt in…he also started demanding apologies and issuing “or else” statements, as if he’s the judge, jury, and execution for all things SEO and I’m required to offer him a sacrifice before I can enter his world.

From me to Danny Sullivan

I was definitely pissed beyond words at this point, but I really didn’t want to direct my anger towards Danny, because I know he means well. So I let off just a wee bit o’ rage:

Danny,

First of all, Sphinn isn’t Digg. Nothing that happens there has anything to do with this. I have no idea why you and Matt would both try the “but everyone else is doing it” excuse, but personally I think it’s pathetic. Besides, do I really seem like the kind of person who makes decisions based on the norm?

Second of all, I never asked you to remove anyone’s submission.

Reading the entire email thread doesn’t make you qualified to have an opinion about this in the first place. I don’t expect you to understand or appreciate what was said between the lines, and it’s no surprise that you don’t. Matt’s a big boy; let him dig himself out.

So…in your best judgment…you’ve concluded that the best way to handle this situation is by demanding an apology from me and threatening to ban my account otherwise? Are you serious? Do you also scream at drunk people?

Absolutely, without question, if there’s one thing I’m NOT going to do…it’s apologize to Matt. I’m not even close to being sorry, and I’m not going to pretend otherwise. Furthermore, I’m not going to pretend like I give two shits about my account on Sphinn. Ban it. Delete it. Do whatever you want with it. If you want to rid your site of some of the highest-quality content this industry produces, then that’s your loss. I get nothing from Sphinn, and after what I’ve seen today, I’m embarrassed to have had anything to do with it. Sphinn is just another haven for SEO wannabes and talentless marketers who all want to circle-jerk each other and confirm the stereotype that this industry is bullshit.

Great advice, asking me to email you privately to resolve any future problems, Danny. It’s worked miracles for me. You’re quite the problem solver.

From Danny Sullivan to me

Amazingly, Danny responded YET AGAIN by talking about “what everyone else does.”

Darren, I’ll repeat again, we’ve never had anyone suggest they should seize control over a submission just because they wrote the content that was submitted. You’re the first.

I think you’re the first because Sphinn operates the same way many other social sharing sites operate, where site owners don’t have that type of control. It’s sort of like suggesting that no one should be able to tweet about your stories, or submit your stories to Delicious, or to Digg, or to Reddit, or to Hacker News, or bookmark them in Google Reader … and on and on and on.

Reading the email qualifies me plenty to feel you’ve been way out of line with a member of my staff. And that is indeed how I felt it was best handled.

If Sphinn was a shop, then you had a problem in the shop, someone in the shop has patiently tried to help you, and you’ve effectively started yelling at them and threatening them. That’s simply not acceptable behavior.

We’ll have your account terminated. I’ll also have the seomofo name blocked, as I recall someone who wasn’t you grabbed that ages ago, and we handed it to you when you asked. I’ll also have your site blocked from future submissions to Sphinn, which will prevent anyone from submitting your content, so that you [won't] find yourself facing any further upset.

From me to Danny Sullivan

And that’s when I finally lost it and tried to be as offensive as possible:

Danny…I’m going to tell you something, and I hope you take it to heart.

It is people like you who have destroyed the SEO industry’s reputation. You are not an SEO, you are a marketer–a salesman. You sell people on ideas that you’re not even qualified to talk about, yet you do it anyway…because you value personal success over everything else.

You have the arrogance to ask ME to apologize to Sphinn? Are you out of your goddamn mind? Who the FUCK do you think you are? You’re a nobody. You’re a fucking pretender. Your only skill is your ability to convince other people that you know what the fuck you’re talking about. All you know how to do is regurgitate the ideas of others. You’re a LEECH on the internet and on SEO.

You want to know why I’m the first person who’s ever ____? Because I’m not a sellout like you and your fellow salesmen. You’ve padded yourself with peons who are afraid to call you on your bullshit because they don’t want to draw attention to their own. I don’t have anything to hide. When you run websites that steal my content and fuck me over, I’m going to speak up–without regard for how it might suit your god complex.

So with the utmost sincerity…I’d like to say: go fuck yourself, you poseur.

So there it is. That’s the story behind why my content will never again grace the front page of Sphinn.

If you’re using the TweetMeme Retweet Button on your blog or website, and you’ve noticed it’s been slowing down your page load times, then this article is for you. I will discuss two common ways to install the Retweet Button–through the WordPress plugin and through adding a custom <script> element to your HTML code–and I will explain why these two implementation methods are probably preventing your web pages from loading as quickly as they could be. Then I will show you how to install the TweetMeme Retweet Button in a way that doesn’t affect your page speed. My solution is not limited to the TweetMeme button, so a reasonably-intelligent person can apply these same steps to any iframe-based social media smart buttons.

Most bloggers use social media networks and micro-blogging sites like Twitter to promote their content. One of the easiest ways to do that is to install social media widgets on your blog and hope that your readers are grateful enough to share your content with their friends. I mean…it’s the least they can do, considering how many hours of your personal time you put into your blog posts. *ahem* Right?

The problem with some of these “smart” social media widgets (i.e., the ones that display a number of votes, diggs, sphinns, etc.) is that they usually require your page to make several HTTP requests for external files. Due to the way these widgets are normally installed, your page can’t finish loading until all of these requests have been answered. Ultimately, it doesn’t do you much good to put these things on your blog, if the result is a sluggish website that drives your readers away.

One social media widget that has become very popular is the retweet button from TweetMeme.com. For most of you, it looks something like this:

When you write super-amazing content like I do, your TweetMeme buttons tend to look more like this:

But the purpose of today’s article is to show you how to prevent your retweet buttons from ending up like this:

As soon as you realize my animated .gif isn’t actually going to load anything, we can continue…

To fully understand the solution I propose in this article, you should probably read the next two sections, which explain why the WordPress plugin sucks…and why the customized <script> option sucks. However, you’re more than welcome to skip straight to the solution↓.

Why does the TweetMeme WordPress plugin suck?

The TweetMeme Retweet Button plugin for WordPress has a couple of useful features, but ironically, inserting the Retweet Button code into your posts is not one of them. The features you might consider using are the TweetMeme Analytics interface, the option to automatically ping TweetMeme.com when you post new content, and the option to insert the Retweet button into your RSS feed pages. Unfortunately, the code that the WordPress plugin writes into your HTML source code is NOT usable for what we need to do. Therefore, if you keep the plugin activated, be sure to go to the TweetMeme settings and change the Position option to Manual.

Also, you will NOT be able to use the tweetmeme(); function in your WordPress templates, because it writes the same unusable HTML code. Basically, our objective for this plugin or any other TweetMeme plugin is to prevent it from inserting the <iframe> markup directly into your HTML. Here is an example of the useless code that the WordPress plugin wants to crap into your page:

<div class="tweetmeme_button">
	<iframe src="http://api.tweetmeme.com/button.js?url=http%3A%2F%2Fwww.seomofo.com%2Fwordpress%2Ftweetmeme-retweet-button.html&source=SEOmofo&style=normal&service=bit.ly" height="61" width="50" frameborder="0" scrolling="no"></iframe>
</div>

You DON’T want this <iframe> anywhere in your HTML, for several reasons, but most-importantly because: iframes block your page from loading. We’re going to work around this by using JavaScript to write the <iframe> code into a container element, after the page is done loading. We’ll get to that in a second, but first you need to kill any plugins that put the <iframe> code directly into your pages’ HTML.

Why Does the WordPress Plugin FAIL?

Here is an overview of how the WordPress plugin works, and how it eventually forces your pages to wait for the TweetMeme <iframe> to load.

1. WordPress builds an <iframe> (server-side) and inserts it into the HTML code of a page.
2. Server sends the page to the client. (e.g., a visitor’s web browser)
3. Web browser sees the <iframe> and requests its src file. Browser waits for src file to load completely before firing the onload event.
4. Your page can’t finish loading until the Retweet Button finishes loading.

First Steps for TweetMeme WordPress Plugin Users

Why does the TweetMeme button’s custom <script> suck?

The second method for installing the TweetMeme Retweet Button is to insert a <script> element into your HTML code, at the point where you want the button to appear. For details about this method, you can view the TweetMeme Button documentation from TweetMeme.com. Or…just keep reading.

At a bare minimum, you would need to include the <script> element that calls the JavaScript file, button.js, from TweetMeme’s servers. In addition, there are 4 parameters that you could use to customize your Retweet Button. I’ll explain them briefly:

• tweetmeme_url – the URL your retweet will link to on Twitter. By default, the button uses the URL of the page it’s on, so you don’t need to include this parameter unless you’re embedding the retweet button on Page A, but you want your Twitter status update to link to Page B. (For example, this would be handy for adding a retweet button to your RSS feed.)
• tweetmeme_source – the Twitter @username that will appear after the “RT.” By default, this parameter is set to “tweetmeme,” which results in retweets like this: RT @tweetmeme TITLE URL
• tweetmeme_style – choose between normal or compact button design. Default is normal. The compact button looks like this (I added the drop shadow):
  
  
• tweetmeme_service – choose one from TweetMeme’s list of URL-shortening services. Default is ow.ly.

The following code is an example of the kind of crap that the script method might use. Theoretically, you would paste this directly into your pages’ HTML code.

<script type="text/javascript">
	tweetmeme_url = 'http://yoururl.com'; // only necessary if different from current URL
	tweetmeme_source = 'SEOmofo';         // Twitter @username that will be retweeted
	tweetmeme_style = 'compact';          // only add this line if you want to create a smaller button
	tweetmeme_service = 'bit.ly';         // URL shortening service you want to use
</script>
<script type="text/javascript" src="http://tweetmeme.com/i/scripts/button.js">
</script>

Are we going to be using the custom <script> parameters? No, not exactly. But you need to be familiar with them for our final method of installing the retweet button. We won’t be using them within <script> tags, but we will be using them to create a custom src URL for our iframe.

The reason why we DO NOT want to use these <script> tags is the same reason we don’t want to use the <iframe> code directly: they block the page from loading. When a web browser is rendering the page, it will see the <script> tag that references the button.js file and immediately send a request for it. To make things worse, the button.js script uses document.write(); statements to insert the <iframe> code into your document…and then we’re back to square one, waiting for the <iframe> to load. In other words, this method for installing the retweet button is actually worse than the WordPress plugin, because instead of building the <iframe> code on the server side, it has to request button.js (client side) and wait for it to build the <iframe> for you.

Why Does the Custom <script> FAIL?

Here is an overview of how the <script> method of installing the button works, and how it eventually forces your page to wait for the <script> to build your <iframe> code and then waits for the TweetMeme <iframe> content to load.

1. Server inserts custom <script> elements into the HTML code of a page.
2. Server sends the page to the client. (e.g., a visitor’s web browser)
3. Web browser sees the <script> and requests its src file. Browser waits for src file to load.
4. Src file inserts an <iframe> into our document.
5. Web browser sees the <iframe> and requests its src file. Browser waits for src file to load completely before firing the onload event.
6. Your page can’t finish loading until the Retweet Button finishes loading.

The Solution

Load the TweetMeme Button AFTER the Page Loads

Despite all the bad things I’ve said about iframes and scripts, we’re actually going to use both in our implementation. The difference is we’re going to host our own JavaScript, and we’re not going to insert the TweetMeme button’s <iframe> into our document until after everything else is finished loading.

STEP 1: Build Your Button’s <iframe> Code

Instead of relying on WordPress or button.js to build our <iframe> code, we’re going to do it ourselves. Don’t worry, it’s much easier than it sounds. To accomplish this, we first need to understand what button.js actually does. Here is the JavaScript code after I’ve formatted it and added comments to it. FYI, I’m not an expert on JavaScript, so my interpretation of this code might be totally wrong. But if you’ve read this far…there’s no turning back now, sucker!

// Get page URL
var _url = window.location.href;

// Remove illegal characters
var _url = _url.replace(/((?:\?|&)?fbc_receiver=.+)?(?:#.*)?$/, "");

// Convert your custom script parameters into local JavaScript variables.
// Make sure they are strings and escape illegal characters.
var url = escape(typeof tweetmeme_url == "string" ? tweetmeme_url : typeof TWEETMEME_URL == "string" ? TWEETMEME_URL : _url).replace(/\+/g, "%2b");
var source = typeof tweetmeme_source == "string" ? escape(tweetmeme_source) : typeof TWEETMEME_SOURCE == "string" ? escape(TWEETMEME_SOURCE) : false;
var style = typeof tweetmeme_style == "string" ? escape(tweetmeme_style) : typeof TWEETMEME_STYLE == "string" ? escape(TWEETMEME_STYLE) : "normal";
var service = typeof tweetmeme_service == "string" ? escape(tweetmeme_service) : typeof TWEETMEME_SERVICE == "string" ? escape(TWEETMEME_SERVICE) : false;

// Apparently, if your URL-shortening service offers an API, you can 
// configure it with the tweetmeme_service_api parameter. I couldn't 
// find any documentation on this parameter from TweetMeme, so I'm not 
// sure about this.
var service_api = typeof tweetmeme_service_api == "string" ? escape(tweetmeme_service_api) : typeof TWEETMEME_SERVICE_API == "string" ? escape(TWEETMEME_SERVICE_API) : false;

// I didn't see any TweetMeme documentation about the tweetmeme_alias 
// parameter, so I have no idea what this does.
var alias = typeof tweetmeme_alias == "string" ? escape(tweetmeme_alias) : typeof TWEETMEME_ALIAS == "string" ? escape(TWEETMEME_ALIAS) : false;

// This is our iframe src URL before we've added our custom parameter 
// values to it in the form of a query string.
var src = "http://api.tweetmeme.com/button.js";

// This is a poorly-programmed way of setting the height and width of 
// our iframe. (BTW...I tried using the rednose style but nothing 
// happened. It looked just like the default style.)
switch (style) {
	case "compact":
		var h = 20;
		var w = 90;
		break;
	case "rednose":
		var h = 61;
		var w = 50;
		break;
	default:
		var h = 61;
		var w = 50;
		break;
}

// Add our page URL to the src URL
src += "?url=" + url;

// Add our button style option to the src URL
src += "&style=" + style;

// If we defined a value for the tweetmeme_source parameter, 
// then add it to the src URL.
if (source != false) {
	src += "&source=" + source;
}

// If we defined a value for the tweetmeme_service parameter, 
// then add it to the src URL.
if (service) {
	src += "&service=" + service;
}

// If we defined a value for the tweetmeme_service_api parameter, 
// then add it to the src URL.
if (service_api) {
	src += "&service_api=" + service_api;
}

// If we defined a value for the tweetmeme_alias parameter, 
// then add it to the src URL.
if (alias) {
	src += "&alias=" + alias;
}

// Insert iframe code into our page 
// (where we placed the script tags).
document.write('<iframe src="'+src+'" height="'+h+'" width="'+w+'" frameborder="0" scrolling="no"></iframe>');

// Inexplicably reset this huge fuckin' pile 
// of redundant JavaScript variables.
tweetmeme_url = null;
TWEETMEME_URL = null;
tweetmeme_source = null;
TWEETMEME_SOURCE = null;
tweetmeme_service = null;
TWEETMEME_SERVICE = null;
tweetmeme_service_api = null;
TWEETMEME_SERVICE_API = null;
tweetmeme_style = null;
TWEETMEME_STYLE = null;

As you can see, the button.js script really doesn’t do much. All we really have to do is take this <iframe> code and replace the variables with our own values:

<iframe src="src" scrolling="no" frameborder="0" width="w" height="h" ></iframe>

To build your src variable, you can follow this pattern:

1. Start with http://api.tweetmeme.com/button.js
2. Add ?url= followed by your page URL (for right now, just use URL as a placeholder)
3. Add &style= followed by either normal or compact.
4. Add &source= followed by your Twitter username.
5. Add &service= followed by a URL-shortening service from this list:
   
   
   • bit.ly
   • awe.sm
   • cli.gs
   • digg.com
   • is.gd
   • tinyurl.com
   • tr.im
   • su.pr
   • ow.ly
   • twurl.nl
6. If you have a URL-shortener API, add &service_api= followed by your API key. (Only available for awe.sm, cli.gs, digg.com, and su.pr services. I’m not sure if you’re really supposed to put your API key here or not. Frankly, I just made that up.)

Your completed src variable should end up looking something like this:

http://api.tweetmeme.com/button.js?url=URL&style=normal&source=SEOmofo&service=bit.ly

Now set the w and h attributes.

For a normal style button: width="50" height="61"

For a compact style button: width="90" height="20"

Now that you have your values for the variables src, w, and h, you can plug them back into your <iframe> code, which should now look something like this:

<iframe src="http://api.tweetmeme.com/button.js?url=URL&amp;style=normal&amp;source=SEOmofo&amp;service=bit.ly" scrolling="no" frameborder="0" width="50" height="61" ></iframe>

STEP 2: Create a Container for Your Retweet Button

In Step 1, we created our own <iframe> code. Our goal is to store that code in a JavaScript function that we can call after the onload event is triggered. In order for our JavaScript function to work, our web page needs to have a containing element ready to insert the <iframe> code into. This element should have a unique id attribute assigned to it, so that we can tell our JavaScript function exactly where to put the iframe. Here is an example: <div id="tm_button"></div>

If you’re using WordPress, you have several options for getting your container <div> into your page code. I’ve mentioned a few examples below. If you’re not using WordPress or you already know how to do this, then go to Step 3.

1. Add it to a select number of posts, by simply typing the code directly into the HTML view of your Edit Post screen.
2. Add it to your WordPress theme’s template files, which would add it to all web pages that use that template (e.g., single posts, pages, archives, etc.)
3. Add it as a plain text widget in your sidebars.
4. Add it to a WordPress hook, by writing a function in your theme’s functions.php file.
5. Add it to a Thesis hook, by writing a function in your custom_functions.php file (only available to those of you using the Thesis WordPress theme).
6. Create your own WordPress plugin that adds it to certain types of pages.

For Thesis Theme Users

// Define a function that adds your TweetMeme container <div>
// to all posts except for when you're just previewing it.

if (!function_exists('addTMContainer')) {
	function addTMContainer() {
		if (is_single() && !is_preview()) {
?>
		<div id="tm_box"></div>
<?php }
	}
}

// Hook your TweetMeme container to a Thesis hook

add_action('thesis_hook_before_headline', 'addTMContainer');
		

/* Make room for my button next to the page title */

div.headline_area{position:relative; margin-right:6em;}

/* Move my button to the top right corner of .headline_area */

#tm_box{position:absolute; right:-6em;}
	

STEP 3: Define Your <iframe> Code as a JavaScript Function

There are several ways to do this, but I’ll show you what I consider the easiest one. Copy your HTML code and paste it into this tool that converts HTML into JavaScript. Select the option that says Build up a string variable that you can use later and give your variable a name. I’ll call mine iframeCode.

Copy the converted code and paste it into whatever program you use for editing JavaScript/HTML/plain text. Here is what my code looks like now:

var iframeCode="";
iframeCode += "<iframe src=\"http:\/\/api.tweetmeme.com\/button.js?url=URL&amp;style=normal&amp;source=SEOmofo&amp;service=bit.ly\" scrolling=\"no\" frameborder=\"0\" width=\"50\" height=\"61\" ><\/iframe>";
	

If you remember…we still have a placeholder variable where our page URL is supposed to go. We can’t hard-code an actual URL here, because this JavaScript function has to work for any page that calls it. So instead, we make JavaScript get the requesting-page’s URL for us by replacing our placeholder URL with its JavaScript equivalent: document.URL. We can also use JavaScript’s escape() function to encode the URL just like TweetMeme does in their button.js script. Here is our new code:

var iframeCode="";
iframeCode += "<iframe src=\"http:\/\/api.tweetmeme.com\/button.js?url=" + escape(document.URL) + "&amp;style=normal&amp;source=SEOmofo&amp;service=bit.ly\" scrolling=\"no\" frameborder=\"0\" width=\"50\" height=\"61\" ><\/iframe>";
	

We have defined the contents of our iframeCode variable, but we still need to put it in a function that writes this content into our TweetMeme container <div>. Here is an example:

function tweetMemeButton() {

	// If our TweetMeme container doesn't exist,
	// then this function will basically do nothing.

	if (document.getElementById("tm_box")) {

		// This is the code we wrote a second ago.

		var iframeCode = "";
		iframeCode += "<iframe src=\"http://api.tweetmeme.com/button.js?url=" + escape(document.URL) + "&amp;style=normal&amp;source=SEOmofo&amp;service=bit.ly\" scrolling=\"no\" frameborder=\"0\" width=\"50\" height=\"61\" >";

		// Insert our iframe into our TweetMeme container

		document.getElementById("tm_box").innerHTML = iframeCode;
	}
}

STEP 4: Use the window.onload Event Handler to Call Your Function

The window object has an event handler called onload that occurs as soon as a page is done loading. What we’re going to do now is program our tweetMemeButton() function so that it gets called when the onload event is triggered. In other words, we’re not even going to begin loading our TweetMeme button <iframe> until after the page is officially done loading. In order for us to accomplish this, we can add window.onload = tweetMemeButton; to our JavaScript code, which is now ready to be pasted into an external .js file.

In the name of page speed and site performance, I’ve combined all of my site’s JavaScript files into one. I link to this file from the <head> section of every page on my site. However you want to go about it is up to you, but one way or another you need to put your JavaScript code somewhere where all the pages that need it can access it.

If you’re wondering something like this: “Can’t I just paste the entire code into the <head> section of every page?”, then by all means, go right ahead…and punch yourself in the face. Then do it the right way, by pasting a reference to your external .js file into the <head> section of every page (that uses the TweetMeme Retweet Button). For faster page rendering, it’s best to paste this code after (below) your CSS file references. For example:

<head>
...
	<link rel="stylesheet" href="http://www.seomofo.com/wp-content/themes/thesis_16/custom/custom.css" type="text/css" />
...
	<script type="text/javascript" src="/external.js"></script>
</head>
	

Here is our final JavaScript code, ready to be pasted into your external .js file:

function tweetMemeButton() {
	if (document.getElementById("tm_box")) {
		var iframeCode = "";
		iframeCode += "<iframe src=\"http://api.tweetmeme.com/button.js?url=" + escape(document.URL) + "&amp;style=normal&amp;source=SEOmofo&amp;service=bit.ly\" scrolling=\"no\" frameborder=\"0\" width=\"50\" height=\"61\" >";
		document.getElementById("tm_box").innerHTML = iframeCode;
	}
}

window.onload = tweetMemeButton;
	

STEP 5: Share This Super-Amazing Article

That’s right…people are going to wonder why your blog is so damn fast, and when they do…you send them my way. Oh…and for more page speed tips to speed up WordPress, check out my previous masterpiece: WordPress Comments Slow Down Page Speed.

Peace, I’m outta here.

There has been a lot of buzz lately about page speed. Matt Cutts has commented about how page speed might be added as a signal to Google’s ranking algorithm, sometime in the future. Google has released the Site Performance feature in the Labs section of Google Webmaster Tools, despite the fact that it’s useless. And of course, all the popular SEO/SEM blogs have predictably started churning out virtually-useless blog posts about how to make your website faster.

Regardless of whether or not Google makes page speed a ranking factor, optimizing page load times and overall site speed is a best practice that all web developers should be mindful of. Besides, if the Site Performance Lab is any indication, I’d say Google won’t have their page speed data signal “production-ready” for another 15 years. Using the Google Toolbar to detect page load times is quite frankly one of the dumbest ideas I’ve ever heard, and I sincerely hope it’s just another scare tactic to get webmasters’ minds off of SEO and PageRank (and onto something that actually benefits Google). I don’t know how Google collects the speed data they use in their AdSense quality score, but I pray to God it’s more robust than this Site Performance joke. Anyway, rants aside, the fact remains that everyone is suddenly very interested in making their websites faster…and this post is going to address one small piece of that puzzle: WordPress comments.

How does WordPress handle comments?

When WordPress responds to a page request, it has to figure out how to output the comments associated with that particular post. Here is a very basic overview of the steps WordPress follows:

1. Fetch the comments from the wp_comments database table.
2. For each comment that matches the page ID being served, loop through and insert the raw data into HTML code. Here’s a simplified example:

<h6><a href="comment_author_url">comment_author</a></h6>
<p>comment_date</p>
<p><img src="http://www.gravatar.com/avatar/comment_author_email /></p>
<p>comment_content</p>

How does WordPress handle Gravatars?

If a post has 0 comments, the steps shown above end pretty quickly because there’s nothing more for WordPress to process. However, even if a post has several comments to process, the computation cost is relatively insignificant when you compare it to the cost of downloading each commenter’s Gravatar. In other words, WordPress can build the HTML page pretty quickly and send it to your browser, but then your browser still has to request the Gravatar images from gravatar.com. As you’re about to see, it is the multiple HTTP requests for Gravatar images that really slow down your pages. I’ll try to explain why that is…by giving you an overview of how Gravatar works (as I understand it). Here’s the gist:

1. For each comment, WordPress takes the commenter’s email address and applies the md5 hash algorithm to it (in order to protect commenters’ email addresses).
2. The hash is attached to a gravatar.com URL, which creates the src destination for the Gravatar’s img tag. For example: <img src="http://www.gravatar.com/avatar/3904bc1a75d86eb05dd07425214002df" />
3. After the HTML page is sent to your browser, your browser sends a request to Gravatar’s servers for each Gravatar image embedded in the comments.
4. Gravatar’s servers check their records for the hashed email address. If it exists (meaning the email address was registered at gravatar.com), Gravatar returns the corresponding image. If it doesn’t exist, Gravatar redirects to your blog’s default image, which you can select from the WP admin menu for Settings → Discussion:

Why do Gravatars slow down WordPress?

Enabling comments and custom Gravatars on your WordPress blog can definitely encourage your visitors to participate and join the conversation, but on the other hand, the Gravatar system has some inherent flaws that negatively impact your page speed. Here are some examples:

• Every comment contains an img element that points to a unique URL on gravatar.com. This means that every single person who comments on your blog post is costing you an extra HTTP request…regardless of whether or not they’ve registered their email address at gravatar.com.
• If a user is NOT registered at Gravatar.com, their image request will be redirected to the default location. This redirect means yet another HTTP request, either to your server or another gravatar.com URL (depending on what you set your default image as).
• Several different src URLs return the same exact image. This is because every email address results in a unique hash, which in turn creates a unique URL. Many of these unique URLs will redirect to the default Gravatar image, because not all your visitors will be signed up for Gravatar. This triggers a “page speed tip” in Google Webmaster Tools that looks like this:

Page Speed Testing

Below you’ll find some page speed data I collected, using this web page speed tool. It is the same tool Matt Cutts mentioned in his WebPro News interview. The page I used in this test was my article about how stupid people hate Twitter’s new retweet feature, which had a total of 18 comments (from 10 unique users) at the time of testing. The detailed results are linked to below, but I’ve summarized the data results for you as well.

For the full results of each speed test, click the links below:

No comments • No Gravatars →                          Speed Test 1
   Comments • No Gravatars →                          Speed Test 2
   Comments •    Gravatars • Default is Blank →       Speed Test 3
   Comments •    Gravatars • Default is Mystery Man → Speed Test 4
   Comments •    Gravatars • Default is Custom →      Speed Test 5

What can I do to speed up my comments?

Here are some suggestions for speeding up your WordPress posts by optimizing your comment settings. I will try to list these based on how big of an impact they have on your page speed. The suggestions that could improve your page speed the most are listed first:

1. Disable comments completely.
2. Load comments dynamically (e.g. a button that says “click here to view comments”).
3. Delete any comments that don’t add value to your post. (Ego boosts don’t add value.)
4. Disable Gravatars.
5. Set your default Gravatar to Blank.
6. Set your default Gravatar to a custom image on your server.
7. Restrict your Gravatar images to small dimensions (e.g. 32px).

Kill the Smiley Faces!

I just thought of one more setting you can tweak to speed up your WordPress comments. You can UN-check the option that says “Convert emoticons like :-) and :-P to graphics on display.” This will prevent WordPress from having to request the emoticon images such as and .

Something I found interesting about WordPress is that the Mystery Man default Gravatar image is stored on gravatar.com. So the reason why the Blank avatar and my custom avatar returned faster page load speeds…is because they are both stored on my own server. Theoretically, you might be able to speed up your page loads by simply saving a copy of Mystery Man to your own server and designating it as your default (I’ll eventually write a post that explains how to do this). Older browsers will only maintain 2 connections to any given host, so if your web browser is requesting ALL the Gravatar images from www.gravatar.com, then it can only grab two at a time. On the other hand, if the default Gravatar image is located on your own server, then your web browser can grab it even when both www.gravatar.com connections are busy.

To put it all in perspective…

After reading a Twitter response to this article, I realized that I wasn’t entirely clear about how much comments slow down WordPress posts…as a relative measurement. I’ll try to put it into perspective for you.

First of all, I only ran the speed tests on one page, so certainly these results will vary, depending on variables such as:

• How fast is your server, compared to gravatar.com’s server?
• How many comments does the WordPress post have?
• How many of those comments are from unique visitors (i.e. unique email addresses)?
• What type of web browser are your visitors using to view the page?*

* Older browsers only permitted 2 persistent connections per host. Newer browsers support more, and therefore multiple Gravatar images can be downloaded from www.gravatar.com in parallel. For more details, see the Roundup on Parallel Connections by website speed guru, Steve Souders.

One of the reasons why my test results only differ by a couple 10ths of a second is because my test page only had 18 comments, and only 10 of those were from unique email addresses. Also, I’ve been busy tweaking. My website, in order to improve overall performance. So try not to think in terms of my specific test page, because this data will mislead you:

1. Without any comments, the test page loaded in = 0.956 seconds.
   t1  =  0.956s
2. After I enabled the comments (without Gravatars), the test page required an additional 0.166 seconds to load.
   t2  =  t1 + 0.166s
3. After I enabled the Gravatars, the test page required an additional  0.190 seconds to load.
   t3  =  t2 + 0.190s  =  t1 + 0.356s

Why is that data misleading?

It’s misleading because some of you [lesser intelligent] people don’t know the importance of relative measurements, and you’ll interpret my data to mean something like this:

Hooray! Comments and avatars only slow down a WordPress post by 0.356 seconds! That’s totally…like…not a long time to wait. Social media really is the best internet marketing strategy evar, tee-hee! I’m gonna put a trillion comments on every page of my site! Even the comments on my comments will have comments!

Instead, look at it from a glass-half-empty point of view:

1. Without any comments, the test page loaded in some [unknown] amount of time.
   t1  =  x
2. After I enabled the comments (without Gravatars), the test page took 17.3% longer to load.
   t2  =  (117.3%)(t1)
3. After I enabled the Gravatars, the test page took 16.9% longer to load than the page without Gravatars. And compared to the first page (which had no comments and no Gravatars), the test page took 37.2% longer to load.
   t3  =  (116.9%)(t2)  =  (137.2%)(t1)

Get your math equations out of my face and just spell it out in plain English!

What I’m telling you is…

Adding 18 comments to my blog post made it 37.2% SLOWER.

I’m still not convinced!

Alright, I got another test case for you. This one is a comparison between two different posts on Outspoken Media: one that has 5 comments vs one that has 130 comments. The content isn’t exactly the same, but it’s close enough. No? It’s not close enough? You demand more-accurate testing? Fine, I copied the content portion of these posts, pasted it into empty HTML pages, hosted them on my own site, and ran the tests again on just the content. If you really want to see the difference, the results are here:  Page#1  Page#2. The only relevant information those results show is that the page with 130 comments has a slight disadvantage (due to an extra image) and takes 0.2 seconds longer to load (not including the comments, of course). Anyhow…let’s get to the important stuff now. Let’s compare the page load times of the actual posts…comments and all.

Speed Test #1

• Post: It’s Not the Recession, You Just Suck
• 130 comments
• 85 unique Gravatars
• Average load time before cache: 9.315s
• Average load time after cache: 4.155s
• full test results

Speed Test #2

• Post: Penalties, issues and filtering; it’s all just confusing me
• 5 comments
• 5 unique Gravatars
• Average load time before cache: 4.636s
• Average load time after cache: 2.352s
• full test results

In plain English

The results of this second set of tests indicate that…

Compared to the post with 5 comments…the post with 130 comments took roughly TWICE as long to load.

Grand Finale

Click the small green button below to see the waterfall graph comparison between the 130-comment post and the 5-comment post.

I was checking out a few of Google’s recent patent applications, and I inadvertently made a startling discovery: evil. That’s right…we’ve all heard the Google motto, “Don’t be evil,” but apparently that doesn’t stop them from incorporating evil into their technology or making it accessible to evil users, as is clearly depicted in the following document:

United States Patent Application 20090327855
Annotating Webpage Content

To be honest, I didn’t even read this patent thoroughly. I just skimmed through it…searching for SEO-related gems. It looked to me like a patent for Google Sidewiki, although it never actually mentioned that name. It did, however, mention the ability to annotate web pages and how to use the Google Toolbar to fetch any annotations that are stored remotely for that given web page. Since Sidewiki has no implications for SEO, I mostly just looked at the diagrams (which I cannot stress enough how helpful they are for understanding patents). Some of the diagrams represent users with a crude stick man (who apparently rides horses a lot), and all of the stick men look like pretty decent people:

But then when you get to Figure 9, you find a stick man who obviously has evil intentions, as is indicated by his black eyes:

So the question is…why did Google draw only this one user with solid black eyes? Does Google think all laptop users are evil? Is this user actually an alien, researching our solar system in preparation for enslaving mankind? Is Google trying to corner the intergalactic online ad-serving market? It’s too hard to say at this point. The only thing we know for sure…is that this post was totally useless.

This is a followup response to Everfluxx, who wrote a post about the robots meta tags that Thesis inserts into archive pages.

Everfluxx discovered that when you opt to add the noindex attribute to your pages’ robots meta tags, Thesis automatically assumes you meant noindex, nofollow. However, the nofollow attribute can cause a loss of site-wide PageRank, so many Thesis users will probably need a way to remove it.

For a complete explanation, check out this must-read post from Everfluxx:
Using Thesis? Then beware of the “hidden” nofollow on archive pages!

In his post, Everfluxx describes the problem and proposes a solution. His solution is quick and easy, but it requires editing Thesis core files, which makes some bloggers nervous (since they would have to redo that code edit every time a new version of Thesis is released). In his closing paragraph, Everfluxx writes:

A final word to fellow Thesis developers/hackers: if you can think of a Better Way To Do It that does not require editing the theme files (e.g., via WP hooks, I dunno), please drop it in the comments. Thanks

I was in the mood for some php coding, so I set to work and made it happen. But…it was just too beautiful to leave as a comment…so I kept it all to myself! (Sorry, Everfluxx! If it’s any consolation, I’ve used hot pink throughout this post…in your honor! =P)

How to Customize Your Robots Meta Tags in Thesis

1. UN-check the boxes under Add Noindex to Archive Pages in the Thesis Options menu. (The code below will add the robots meta tag for you, so if you leave the Thesis options checked…you’ll end up with 2 robots meta tags on each page.)
2. Copy the code below and paste it into your custom_functions.php file.
3. Edit the robots meta tag that corresponds with each page type to suit your specific needs. I have included a variety of page types already, but feel free to delete the ones you don’t need. For more-advanced customizations, reference the WordPress conditional tags.
4. Promote this post for me by clicking the social media widgets below.

// Define your motherfuckin' meta robots tags
function my_mofo_meta_robo() {
	if (is_home())
		$mofo_robo = "<meta name=\"robots\" content=\"index, follow\" />\n"; // HOME PAGE
	elseif (is_single())
		$mofo_robo = "<meta name=\"robots\" content=\"index, follow\" />\n"; // SINGLE BLOG POSTS
	elseif (is_page())
		$mofo_robo = "<meta name=\"robots\" content=\"index, follow\" />\n"; // PAGES
	elseif (is_category())
		$mofo_robo = "<meta name=\"robots\" content=\"index, follow\" />\n"; // CATEGORY ARCHIVES
	elseif (is_tag())
		$mofo_robo = "<meta name=\"robots\" content=\"noindex, follow\" />\n"; // TAG ARCHIVES
	elseif (is_author())
		$mofo_robo = "<meta name=\"robots\" content=\"noindex, follow\" />\n"; // AUTHOR ARCHIVES
	elseif (is_date())
		$mofo_robo = "<meta name=\"robots\" content=\"noindex, follow\" />\n"; // DATE ARCHIVES
	elseif (is_search())
		$mofo_robo = "<meta name=\"robots\" content=\"noindex, follow\" />\n"; // SEARCH PAGES
	elseif (is_404())
		$mofo_robo = "<meta name=\"robots\" content=\"noindex, follow\" />\n"; // 404 ERROR PAGE

	echo $mofo_robo;
}

// Add your motherfuckin' meta robots tag to the <head> section
add_action('wp_head', 'my_mofo_meta_robo');

The content below used to be on the page called “Updates.” I no longer need to keep track of changes to my site, so I’m moving this to a regular post under the WordPress category. This page simply lists all the changes I made to my site during the first month after I installed Thesis/WordPress. It might give you some ideas for what to do after a fresh WP install.

Nov. 28, 2009

• Updated a few posts with new formatting styles.

Nov. 27, 2009

• Added the WordPress Super Cache plugin.
• Added the Bad Behavior on WordPress plugin.
• Added the WordPress Breadcrumbs plugin.

Nov. 26, 2009

• Added a sweet, sweet image of stupid Taz to my Stupid People Hate Twitter’s New Retweet post.

Nov. 23, 2009

• Added custom default Gravatar image.

Nov. 21, 2009

• Added social network links and widgets after the content of each post.

Nov. 20, 2009

• Published a post about why Stupid People Hate Twitter’s New Retweet.

Nov. 19, 2009

• Spent most of the day trying to ignore the constant stream of complaints about the new Twitter RT feature.
• Started writing a rant about stupid people.

Nov. 17, 2009

• Changed home page <meta name="description" /> content (back to my ASCII art version).
• Configured Comment Link Manager to whitelist a few comment authors.
• Enabled nested comments.

Nov. 16, 2009

• Published How to Monitor Google Sidewiki Comments.

Nov. 14, 2009

• Installed the Comment Link Manager plugin, which requires comment authors to have 10 approved comments before their links become active.
• Installed the PS Disable Auto Formatting plugin, which prevents WordPress from adding/deleting <p> and <br />.
• Modified my Twitter icon again. This time I made it into a sprite to reduce page size and speed up the hover effect.
• Started adding content to my About page.

Nov. 13, 2009

• Installed the TweetMeme WordPress plugin.
• Modified a Twitter icon to use for “Follow Me” link.

Nov. 12, 2009

• Updated to WordPress 2.8.6.
• Set up the MyBrand feature on Feed Burner. Feed URL is now http://feeds.seomofo.com.
• Installed the FeedBurner FeedSmith plugin.
• Added Subscribe links to right-hand column.
• Enabled the Google XML Sitemap plugin.
• 301 redirected all date archive URLs to the home page. Here’s the mod_rewrite code I added to .htaccess:

  RewriteCond %{REQUEST_URI} ^/[0-9]+/ [NC]
  RewriteRule ^(.*)$ http://www.seomofo.com/ [R=301,L]
  

  
  
  

Nov. 11, 2009

• Battled the DNS monster some more today and finally defeated that beast. Site should be up and running now.
• Removed the smiley face image [ ] that’s inserted by WP Stats.

  /* KILL THE WP STATS SMILEY IN FOOTER */
  img#wpstats{display:none;}
  

  
  
  
• Added Updates tab to top navigation.

Nov. 10, 2009

• I spent most of today battling the semi-functional DNS dashboards on 3 different hosting sites. Site will be down until DNS propagates. Probably could have avoided down time if I were patient, but I’m not…so to the 20 people who visit my site today: I apologize.

Nov. 9, 2009

• In preparation for setting up my blog feed at feeds.seomofo.com, I’ve started to move my site from its cheap hosting over to my VPS hosting.

Nov. 4, 2009

• Wrote a post called Best Way to Research Google Patents.
• Removed the Thesis default header and added my own.
• Added some sweet, sweet shadow effects to my new header logo and some <h2> headings.
• Here is the code I added to the custom_functions.php file:

  // Remove the Thesis header
  remove_action('thesis_hook_header', 'thesis_default_header');<br /><br />// Define my own header
  function mofo_header() {
  ?>
  		<div id="logo_mofo">
  			<div id="domain_mofo"><a href="/"><em>SEO</em></a><span> </span>mofo<span id="dot_mofo">.</span>com</div>
  			<div id="slogan_mofo">The <span>&uarr;</span> <b>SEO</b> links to my home page!</div>
  		</div>
  <?php	
  }<br /><br />// Add my header
  add_action('thesis_hook_header', 'mofo_header');
  

  
  
  

Nov. 3, 2009

• Wrote a post called Thesis Phi-Column Layout. In it, I marked up phi with <var></var> tags, despite the fact that φ represents an irrational constant. Does that make me a bad person?
• Changed a bunch of formatting in custom.css file.

Nov. 2, 2009

• Added favicon code to <head> section.
• Changed Twitter widget settings to show last 3 tweets.
• Installed the Syntax Highlighter Evolved plugin.
• Changed Thesis default formatting for the “current” tabs so that it shows a pointer when you mouse over it (instead of the text cursor). Here’s the CSS I added to custom.css:

  ul.menu li.current a:hover{cursor:pointer;}
  

  
  
  
• Edited .htaccess file to redirect /blog to /.
• I’ve also temporarily deactivated my XML Sitemap plugin and the ping-o-matic feature until I’m ready for the new URLs to be crawled.
• Installed the Subscribe to Comments plugin.

Oct. 30, 2009

• Posted Nokia Promo Spam Email.

Oct. 29, 2009

• Moved WordPress from /blog to /.
• Edited Thesis design options and custom.css styles.
• Wrote a post about how to add rounded corners to the Thesis top navigation menu.

Oct. 25, 2009

• Wrote a crapost about a typo/bug I discovered in the Thesis font formatting options, but then Thesis 1.6 was released and the typo/bug disappeared.

Who should read this article?

If you meet the following criteria, this post is for you:

1. You use the Thesis theme for WordPress.
2. You allow comments on your posts.
3. Under Thesis Options, you have selected the option to “Show list of allowed HTML tags.”
4. The solid border around your comment form’s <textarea> does not line up with the dotted border of the element underneath it (the element that contains the text You can use these HTML tags and attributes…).
5. You want to fix the borders so they line up perfectly!

If you qualify, read on, valued reader! If you don’t qualify, read on, valued reader! If you don’t want to hear me nitpick petty details, then just skip to the solution.

What are these comment form borders you speak of?

Here is an example of a comment form with misaligned borders:

Show list of allowed HTML tags

Here is the Thesis Options menu where you enable this option:

Why aren’t my borders aligned?

If you show the allowed HTML tags, and your main content column width is outside the range of approximately 438px – 508px, then chances are your borders are effed up. Complicating the issue further is the fact that your borders will appear more effed up or less effed up, depending on the web browser you’re using. Below is a zoomed-in view of the borders on Matt Cutts’ comment form, as seen in some major web browsers (using Windows Vista for all of them except IE6 and IE7, which were captured via their respective Microsoft Virtual PC images running on Windows XP SP3):

The illustration above revealed a couple of interesting observations: (1) IE8 (which is supposed to be the most standards-compliant version of Internet Explorer) deviates the furthest from the intended dimensions. Every other web browser rendered the width of the top part (the <textarea> element) as either 686px or 687px, while IE8 rendered it at 682px! WTF, Microsoft? (2) IE8 in compatibility mode was NOT rendered exactly the same as it was in IE7.

Comment form HTML node tree

For your reference, I’ve created a simple HTML node tree of the comment form elements. Think of this as the raw HTML source code, with all the content, irrelevant attributes, and closing tags removed. The only information this node tree is meant to convey is the hierarchical nesting of HTML elements. This notation is helpful for understanding CSS styles and how they cascade. Check it out:

<form id="commentform">
	<p>
		<input class="text_input" id="author">
		<label>
			<span class="required">
	<p>
		<input class="text_input" id="email">
		<label>
			<span class="required">
	<p>
		<input class="text_input" id="url">
		<label>
	<p class="comment_box">
		<textarea>
		<span class="allowed">
			<span>
				<em>
					<acronym>
	<p class="subscribe-to-comments">
		<input id="subscribe">
		<label>
	<p>
		<input class="form_submit" id="submit">

If you take a look at lines 14 and 15, you’ll find the sibling elements who just can’t seem to get along. In plain English, that means that <textarea> and <span class="allowed"> are the two elements whose borders don’t line up. Therefore, our goal is to make these two elements the same width.

Thesis Writes Dynamic Stylesheets

If you haven’t spent much time tweaking the CSS styles for Thesis, you probably don’t know that the 2 primary stylesheets are dynamically built by your server, based on the font size you’ve defined in the Thesis Design Options menu, under Content Area. So for example, Thesis wants the border of its comment form to be 1px, regardless of what your font size is, but it also wants to define everything in em units (which is usually the preferred unit for maximizing cross-browser compatibility and displaying properly across many different devices and display resolutions). Therefore, if you set your content font size to 16 (where 1em = 16px), then Thesis will build a stylesheet that defines the border of its comment form to be 0.063em. Multiply (16 pixels/em)(0.063em), and you get a border width of 1.008px, which rounds to 1px. The only reason I’m mentioning this about Thesis is because my illustration below shows the <textarea> padding (defined in /wp-content/themes/thesis/custom/layout.css) as 3px on each side, but your layout.css file will define it in em units. Thesis will adjust the em value to ensure that all font sizes result in 3px of padding on all sides of the <textarea>, and 0px of padding on the sides of the <span class="allowed"> (it has 7px of padding on the top and bottom, but this doesn’t affect our border issue).

From looking at the illustration, you can see that our two elements will line up when the following equation is true:

(.96)(parent width) + 6px = (.973)(parent width)

Sub-pixel Rounding in Major Web Browsers

Even though the equation above has only one solution, we can actually take advantage of sub-pixel rounding to get a range of acceptable solutions. In order for these two elements to be the same width, the parent element (p.comment_box) needs to be in the range of approximately 415px – 485px. After taking the 23px into account, this means our content column width (which you can define in the Thesis Design Options menu) needs to be in the range of approximately 438px – 508px…otherwise the borders will break. If you left your content column width at the Thesis default value of 480px, then your borders should be okay…at least in SOME browsers. The chances of your borders lining up in IE8, however, are extremely slim…due to the fact that Internet Explorer is absolutely the shittiest browser in the World. With terrible browsers like Internet Explorer still in use, we need to find a solution that doesn’t require any unit conversions (e.g. 1.3% = 6px). This won’t guarantee that all browsers render the comment form at the same width, but it will guarantee that the borders line up.

Can you STFU and give us the solution now?

Sure. Copy this code and paste it in your custom.css file:

#commentform textarea{width:97.3%; padding:0;}

Serious? I just read all that crazy shit for one line of code?

Yup.

How do I know if this will work for my blog?

Simple. Just save this bookmarklet to your bookmarks, go stare at your effed up comment form borders, and click this sumbitch. Did it work?

OMG, you rock! How can I ever repay you?

Hmm…maybe you could click on some of these awesome social media widgets:

If you’re using Twitter to promote yourself or your company, then you need your profile page to make a good first impression. Twitter offers a handful of simple formatting options for customizing your profile page, and one of those is the option to use a custom background image. This article will show you how to design a Twitter background that looks great on all of the most common computer monitor resolutions, and therefore appeals to the broadest audience possible.

A well-designed background image can have a positive influence on how your brand is perceived by your customers, business contacts, and colleagues. On the other hand, a poorly-designed background image can make you seem incompetent, lazy, disorganized, or just plain stupid. The goal of this article is to establish some intelligent guidelines and best practices for creating a custom Twitter background image. Since I am a perfectionist, I will probably go into ridiculously-detailed details about why or how I determined my final guidelines. However, if you already know that I’m a genius and that everything I say is a holy gift handed down to me by Informinus (the Roman god of correct information), then you’re certainly welcome to skip to the design tips or the template. If you’re not yet convinced of my awesomeness, then put on your OCD thinking caps and follow me.

What are the Twitter page dimensions?

In order to create an optimal background image, we need to know the dimensions of the various elements in the page layout. In other words, we need to know where Twitter’s content is going to appear so we can build our image around it. We’ll start by measuring the elements whose dimensions are independent of the user’s monitor resolution. Then we’ll discuss the dimensions that DO change as the monitor resolution changes.

Static Dimensions

Some of the dimensions of the header spacing and navigation menu are defined in relative units (meaning they could increase or decrease if a user changes the default font size of their web browser), but for the sake of designing our image, we will assume that our users have not changed the default font size (1em = 12px). Here are the dimensions of the page that we can assume will never change:

CLICK IMAGE TO VIEW LARGER

In the image above, I have highlighted the dimensions that might be useful to know. The image also has a chart of the heights of each color-coded section. The first measurement represents the height as it is rendered in a web browser. Some of the elements have a second measurement in parentheses–these represent the dimensions as they are actually defined in Twitter’s CSS stylesheet. For reference, here are the CSS styles from the original Twitter stylesheet (colored squares correspond to the image above):

The only one that might be confusing is the purple section’s dimensions. Note that the purple section’s height is defined by more than one CSS style. Once you take the 12px font’s line-height into consideration (default = 125% = 15px), you get the purple height as the sum of:

<1px border><6px padding><15px line-height><6px padding><1px border>

Damn it! As I’m writing this, the developers at Twitter are changing their CSS file! Grrrrr. Ok, as far as I can tell, they only removed the style that defines the top nav text as font-size:1em. Since this style was overriding the one before it, deleting it brings us back to 1.05em. I don’t know which of these is going to be used long-term, so I’ll just show both. The difference is only a couple of pixels:

CLICK IMAGE TO VIEW LARGER

Variable Dimensions

This is the trickiest part of designing your custom background, and it’s the area where most people fail. After you upload your new image, it will be positioned in the upper-left corner of your web browser window, and it will stay at that position regardless of the users’ monitor resolutions. However, the container element (i.e. the main page content) is centered in the browser window, so its starting position DOES change, depending on the size of the monitor. You can see this for yourself by going to Twitter.com and adjusting the size of your browser window. As you drag the side of the window to make it bigger/smaller, you should notice that the containing element readjusts so that it’s always centered. As a result, the visible portion of our background image changes as well. One of the things we need to figure out…is the relationship between a user’s monitor resolution and the size of our drawing “canvas,” shown here in green:

Canvas Width vs. Monitor Resolution

To find the width of our canvas, we start with the monitor width and subtract out any widths of browser window borders and scroll bars. This is tricky, because scroll bars have different widths, depending on the operating system…and browser borders have different widths, depending on which browser it is. So we’re going to have to make a generalization here, erring on the side of caution.

After testing all of the major browsers in Windows Vista, I found that most of them have no side borders when the window size is maximized. However, Internet Explorer and Opera both kept some type of borders, even when maximized. Of the two, Internet Explorer had the thickest borders at 2px per side. So our generalized measurement for all browsers will be 4px of total width assigned to browser borders. This generalization assumes that your visitors are using a maximized browser window. (Otherwise, they will have adjusted their browser window to an arbitrary width and height, and you can’t really plan for that.)

Scroll bars can change sizes, depending on the operating system being used. I don’t have access to many different OS’s, so I only measured the widths in Windows XP (left) and Windows Vista (right). Both came out to 17px wide. If you know of any operating systems that use scroll bars wider than 17px, let me know. Until then, our generalized measurement for all scroll bars will be 17px.

After subtracting 21 pixels from the screen resolution, we then subtract the width of the container element, which is 763px. The result equals both sides of the exposed background image, but we only care about the left side, so we divide by 2. Overall, our formula for canvas width is:

canvas width = (monitor width – 4px borders – 17px scroll bar – 763px container) / 2

Canvas Height vs. Monitor Resolution

Measuring the canvas height is not as accurate as the width was. With the width, we only had to generalize the width of the browser borders and scroll bar. These dimensions do not vary much. But the height has to take more into consideration, such as the height of all menu bars and task bars. These dimensions vary greatly, depending on the browser and the operating system. For example, compare the top of Chrome to the top of Firefox after I installed several Firefox plugins:

Since the browser choice can make such a big difference in the canvas size, the generalized measurements will be much shorter than what some users will see. We will assume that all users have a ridiculously plugin-laden Firefox installation like mine, and they are running Windows Vista. In addition to the 238px height of the top portion (shown in the comparison above), we must also take the bottom portion into consideration. Here is the Vista task bar + Firefox bottom:

Our generalized formula for canvas height would be:

canvas height = monitor height – 238px top – 52px bottom

Okay, the hard part is over. Now all we have to do is take a list of common screen resolutions and adjust the width and height, according to our formulas. The end result will be a list of canvas sizes we can expect to work with as we create our custom background image. In order to determine what the most common screen resolutions are, I sampled Google Analytics data taken from 4 different websites over a period of 6 months, from July 1, 2009 – December 1, 2009. This data represents 3.1 million total visitors, so it should be a pretty good representation of internet users in general. Below are the top 18 screen resolutions and their corresponding canvas sizes. These 2 graphs are the same data, but one is sorted by popularity and the other is sorted by screen resolution:

Many of these screen resolutions have similar widths, so I compressed the top 18 screen resolutions into the top 6 screen widths. The majority of the poorly-designed backgrounds I’ve seen contain information or graphics that are too wide. Look at the following graph…you should notice that more than a quarter of internet users are using screens that are 1024 pixels wide. This means your background image needs to display all your contact information and important graphics within the leftmost 120 pixels–otherwise a quarter of your viewers won’t be able to read it!

I haven’t seen nearly as many backgrounds exceeding the canvas height, but I’ll show the chart anyway. The data in this chart suggests that you keep your important information within the topmost 478 pixels.

More Screen Resolution Statistics

The following table contains popular screen size data provided by W3Cschools.com. They also have web browser stats that you might find useful or interesting.

W3Cschools.com Users
January 2010

What are the Twitter background image dimensions?

Many people fail to realize that the viewable portion of a Twitter background image changes, depending on the dimensions of the viewer’s monitor. In other words, there are no one-size-fits-all measurements. However, Twitter does impose a limit on the width of any images you upload, and it will automatically scale your image down to 2048px wide. The height is not limited, but it will change proportionately to the width, if Twitter has to scale your image down to meet the 2048 pixel cutoff.

Recommended Background Image Dimensions

Width: 1920 pixels
Height: 1200 pixels

Maximum Background Image Dimensions

Width: 2048 pixels
Height: no limit

Fitting your important information within your visitors’ viewable background is only half the battle. The other half is making sure your image completely fills the background on your viewers’ screens. There are 2 ways to accomplish this.

Make it Big

The simplest way to make sure your background image is big enough…is to make it as big as the biggest monitors you can reasonably expect your visitors to use. In my opinion, the minimum size you should use is 1920×1200 (this size is used by more than 5% of users). This will cover the vast majority of your visitors’ screens. If your image is relatively simple (i.e. increasing the dimensions by a lot only increases the file size by a little), then you might consider going up to 2048×1600, which is the maximum width that Twitter allows, coupled with the height of a 30″ monitor.

Blend the Edges

The second way to make sure your image is big enough…is to use an image that terminates in a solid color at the edges, and set that color as your background-color. To change your background color, you click Settings → Design.

If I were designing a background image to use with the color #C4E0EC, it might look something like this:

And adding it to my #C4E0EC background would be seamless:

If you already have an image, but you don’t know how to match the background color to it…you can use the Firefox plugin called Colorzilla, which lets you click on anything in your browser and it tells you the color code for that pixel. It’s basically like the eyedropper tool in Paint, Photoshop, Illustrator, etc., but it works in your browser.

Tips for Designing Your Own Twitter Background

1. If your custom background image displays important information like your business name, website, email address, etc., then it should be no wider than the leftmost 120 pixels. Any wider than this and your information will be unreadable to about 25% of your visitors (using monitors that are 1024px wide).

2. The viewable height of your background image depends on which web browser your visitors are using, how many plugins they’ve installed in it, and which operating system they’re using (i.e. the height of the task bar). A conservative estimate of your usable background would be the topmost 478 pixels.

3. The space between the document window and the top of the main container element (i.e., the space where the Twitter logo and top navigation are located) is 66 pixels tall. If your background image displays contact information in the top 66 pixels, then visitors using 800×600 monitors (only about 2-3% of users) will see the Twitter logo on top of that information. If you wish to avoid this, display your information below the top 66px.

4. To make sure your background image fills your visitors’ entire screens, you have two options. You can blend your image into a solid color around the edges and set your Twitter profile’s background-color to match it. Or you can make your background big enough to cover the highest resolutions available on the consumer market. If you choose the latter, your background image should be at least 1920×1200.

Custom Twitter Background Image Template

The images below are guides to help you with the design of your custom Twitter background. The one on the left is the recommended 1920×1200 resolution, and the one on the right is the XL resolution of 2048×1600. The XL version is not very practical, but I’ve included it for the sake of completeness. The colored boxes represent the canvas sizes as they are viewed in each of the top 6 most common screen sizes, and the XL version also contains the yellow area, which represents the viewable dimensions of the 2560×1600 pixel monitors. The images are also annotated with helpful tips that explain each section of the layout. You can copy an image and paste it into your image editing program, and then build your own background image over it.

If you want to stay current with all the incredible information this site has to offer, you can subscribe to my feed¹, or set your web browser’s home page to http://www.seomofo.com².

1 – Example of a link.
2 – Example of a plain text URL.

One of the SEO theories I’ve heard is that if Google finds a plain text URL in your content, it might interpret that URL as some kind of signal. Does it count as a link to the URL? Does it contribute to the URL’s authority? Does it count towards anything at all? Probably not. Matt Cutts addressed this theory in one of his Webmaster videos and essentially killed it:

It sounds to me like plain text URLs aren’t counted for anything…but you can never be too confident about these sorts of things. Sometimes these theories end up being partially true, simply because Google engineers have overlooked rare cases that indirectly validate the theory. I came across a particular case today that shows at least one instance of Google treating a text URL like a link. Mind you, what I found is more like a bug in Google’s caching logic, and not an intentional use of text URLs as a ranking signal. In other words, the information in this post may be interesting, but it’s virtually useless. (Unlike most SEO bloggers, I hate publishing useless shit, but I’ll make an exception for myself this time.)

Earlier today, I viewed the text-only cached copy of my amazing article about monitoring Google Sidewiki comments through RSS. My goal was to see how Google was caching my social media widgets that I insert at the bottom of every blog post. If you don’t know what I’m talking about, scroll to the end of this article and take a look at my sweet widget collection. And while you’re down there, you should probably try out each of the widgets and make sure they’re functioning properly. Also, according to some recent studies I just made up, promoting my site has been shown to improve your site’s rankings and increase traffic!

Anyway…back to my story. So I was viewing Google’s cached text version of my page, because I wanted to see if Google was executing the widget scripts that are remotely hosted on their respective social network domains. Why would I care about that? Well…I’ve run into problems before where Google has executed locally-hosted scripts, which led to a whole bunch of JavaScript-driven links being counted as regular HTML links. (FYI: you CAN lose PageRank through JavaScript links.)

So I viewed the source code of Google’s cached page and compared it to the original source code. I was glad to see Google was NOT caching any content from the JavaScript-driven widgets. Instead, it just stripped out the <script> elements. But then I noticed something very odd: Google had also stripped out the <textarea> tags that I use for my link widget. Take a look…you’ll notice that lines 2 and 4 are gone:

Original Code

<div class="post_widget_mofo" id="copy_link_mofo">
	<textarea onclick="this.focus();this.select();" rows="5" cols="24">
		<a href="http://www.seomofo.com/orm/monitor-sidewiki-comments.html">How to Monitor Google Sidewiki Comments</a>
	</textarea>
	<p style="color:#999; font-size:10px; line-height:1.2em; text-align:center; margin:0;">Link</p>
</div>

Google’s Cached Code

<div class="post_widget_mofo" id="copy_link_mofo">
	<a href="http://www.seomofo.com/orm/monitor-sidewiki-comments.html">How to Monitor Google Sidewiki Comments</a>
	<p style="color:#999; font-size:10px; line-height:1.2em; text-align:center; margin:0;">Link</p>
</div>

When text and HTML code are enclosed in <textarea> tags, web browsers will not render the HTML; they will treat all of it like plain text. This is why my link widget contains un-encoded HTML but is displayed in the browser as plain text:

…but obviously if Google strips the <textarea> tags, then all that’s left is the HTML code, and now Google shows a link for what was supposed to be plain text:

Original Widgets

Cached Widgets

To be honest, I didn’t even know <textarea> elements would show un-encoded HTML as text. I’m usually very conscious about encoding HTML brackets (using < instead of < and > instead of >), but I didn’t catch this one because it was rendering the way I wanted it to.

I have updated my WordPress function to use encoded HTML brackets in my widget, but I still want to play around with this bug, so I’m going to set up several <textarea> elements with various code snippets in them…and wait for Google to cache them. I’ll update this post in a few days with the results…but it will probably still be virtually worthless information.

Exhibit A: this is basically a repeat of what I’ve already seen. I’m including this to verify that Google is still behaving the way I observed already.

Exhibit B: the onclick attribute is removed from the <textarea> element. Is this attribute what caused Google to strip out these tags?

Exhibit C: the link HTML has been replaced with an image tag. Can I smuggle an image into Google’s text-only cache by wrapping it in <textarea> tags?

Exhibit D: the link HTML has been replaced with a simple JavaScript function. Can I execute JavaScript from within Google’s text-only cache by wrapping it in <textarea> tags?

The Results Are In!

Wow, that was fast. According to Google’s cache date, this post was crawled at 19:57:08 GMT. I posted it at 9:11 am, Pacific time…so that would be 17:11 GMT…which means it took Google about 2 hours and 46 minutes to find my page and crawl it. I don’t know when it appeared cached, but it couldn’t have been more than 4 hours from the crawl time (I noticed it was cached when I checked at about 23:45 GMT).

So here are the results! First off, here is the cached code (you don’t have to analyze it too much…I’ll interpret it for you below):

<div id="exhibit_a" style="width:25%; float:left;">
	<p class="mofo_label">Exhibit A</p>
	<a href="http://www.seomofo.com/">World&#8217;s Greatest SEO</a>
</div>
<div id="exhibit_b" style="width:25%; float:left;">
	<p class="mofo_label">Exhibit B</p>
	<a href="http://www.seomofo.com/">World&#8217;s Greatest SEO</a>
</div>
<div id="exhibit_c" style="width:25%; float:left;">
	<p class="mofo_label">Exhibit C</p>
	SEO Mofo
</div>
<div id="exhibit_d" style="width:25%; float:left;">
	<p class="mofo_label">Exhibit D</p>
	
</div>

Here’s what it looks like rendered:

And finally…here’s what it all means:

Exhibit A: as you can see, Google turned our HTML text into a link by removing the <textarea> tags. This is just more of what we already saw.

Exhibit B: this has also been stripped of its <textarea> tags, which suggests that the onclick attribute in the <textarea> tag was NOT the reason why Google removes them.

Exhibit C: this has also been stripped, but so has my <img> tag, leaving nothing but the alt text in its place. This suggests that Google parses the content nested in the <textarea> element independently. My attempt to smuggle in an image failed.

Exhibit D: same result as Exhibit C, but this was a <script> element, so it didn’t have any alt text to leave behind–just a hole where the script used to be. If the <img> trick failed, then it makes sense that this one would too.

Conclusion

The conclusion here is that Google’s engineers have overlooked a minor detail. When Google processes a page and prepares the text-only content, it fails to recognize that the content of a <textarea> element should be treated like text and not like HTML code^†. If Google is going to strip out the <textarea> tags, it should also make sure the newly-exposed content is encoded properly so it doesn’t render as HTML.

† The W3C specification says: “The TEXTAREA element creates a multi-line text input control. User agents should use the contents of this element as the initial value of the control and should render this text initially.”

Any Takeaways?

Not much to take away here. The only things I can think of are:

1. If you’re trying to comment-spam a site that doesn’t allow links, maybe it allows links wrapped in <textarea> tags? Ha. Somehow I doubt any CMS programmers would make a special exception like this…but hey, it’s possible.
2. Every once in awhile, view a couple of your pages’ cached text versions. A lot of times it will reveal content that Google is caching that you don’t want getting cached, for example: “This site requires Flash…blah blah blah…please click here to go to the Flash download page. If you get lost, just follow my PageRank.”