Well, up until recently, I’d always just called on an old friend, .clearfix, and he’d sorted it out for me. I met .clearfix three or four years ago, and hardly a project has gone by since where I haven’t required his services. You know, I didn’t really ask him how he did it; he’d just quietly go about his job as I directed him, much like Michael Clayton, but without the gambling problem.

But yesterday, when I asked him to help out a colleague for me, little did I know I’d given him his last assignment.

Something happened early this morning – completely coincidentally. A little bird (or rather a tweet) came by and told me that, despite the fact Blueprint CSS uses .clearfix, .clearfix was no longer the way to go. And to be honest, it was almost a relief; the reason I’d never really asked .clearfix how he did his work was that deep down I knew that he was really a hack, and that if I just turned a blind (or ignorant) eye, then I could just pretend like everything was okay and we could all just carry on getting work done.

.clearfix is indeed inelegant, and really is a hack. And would you believe that the alternative solution is not so tricky…
Using overflow: auto; (or overflow: hidden;) on the container with a width will sort it all out for you.
Rather than explain it all here, I’ll just link to a few articles that have already put further effort into describing this:

• PPK’s Clearing floats
• Alex Walker’s Simple Clearing of Floats
• nclud’s Mind The Gap: clearfix is clearly broken

So, farewell, .clearfix, you’ve served us well.
…and thank you, MB, for the enlightenment.

But lately, I’ve come across a few sites that have made me cringe; a colleague pointed out a couple of Swiss ones: migros.ch, and gate24.ch, and I came across the new upandgo.co.nz site on newsites.co.nz.

Let’s look at some stats, with vodafone.co.nz (my old gig) thrown into the mix:

The first three sites are ASPX sites, with bloated, invalid, (W3C) table-based markup, and what appears to be no performance tuning whatsoever. Sure, they are visually heavier than vodafone.co.nz, but being visually heavier doesn’t necessarily equate to looking better, and more often the end-user benefits of the visual components are offset by the performance overhead they introduce.

So, if you’re a web developer and you don’t use, or know of, Firebug and YSlow, stop what you’re doing right now and get familiar with them. Chris Pederick’s Web Developer toolbar for Firefox is also invaluable.

Learn about ETags, far future Expires headers, gzip, script placement, semantic markup, reducing the number of HTTP requests.

These are all vital factors in presenting a great website.
Figure out what you can do to make your site lighter, faster, and more search engine-friendly.

With all due respect, (quite a bit of respect, actually, given Stephen is a recent employee of Airbag Industries LLC) I think that Stephen is wrong.

The airplane example is flawed. Sure, as with any product development, aircraft design is incremental.

But in the grand scheme of things, how long did it take for mankind to go from not flying to flying?
How long was it from when the airplane was invented to when it was a useful, commercially viable, everyday-life, kinda thing?

Not long.

And I believe the web is the same.
How long, in the lifetime of electronic communications, did it take for the WWW, from when it was first publicly available to become a part of life?
How long, in the life time of the web, did it take for web standards to become more-or-less ubiquitous?

Not long.

Things webby have been glacial, of late, but I think 2008/2009 will bring some radical changes on the web.

Leaps and bounds, people; leaps and bounds.

Douglas Vos has inaugurated Blue Beanie Day

Monday, November 26, 2007 is the day thousands of Standardistas (people who support web standards) will wear a Blue Beanie to show their support for accessible, semantic web content.

The blue beanie is, of course, in recognition of Jeffrey Zeldman‘s pioneering advocacy of Web Standards.

Digg it, if you want.

Hear, hear, I say.

So when the user activates a control, I use JS to create some ‘input’ elements (including some radio buttons), add a few attributes to them, and then insert them in a table cell.
It’s not exactly rocket science, even for a JS |\|00|3 such as myself.

Let me expand on this.

I build in Firefox and test in IE. So I use the following code:

// NB: bits and pieces have been left out for the sake of this example.

// create the cell
var newCell = newRow.insertCell(2);

// create the elements
var newInput1 = document.createElement('input' );
var newInput2 = document.createElement('input' );
var newLabel1 = document.createElement('label');
var newLabel2 = document.createElement('label');

// set some attributes on those elements
newInput1.setAttribute('type', 'radio');
newInput1.setAttribute('name', 'rdoAddRemove_' + rowIndex);
newInput1.setAttribute('id', 'rdoAdd_' + rowIndex);
newInput1.setAttribute('value', 'Add');
newInput2.setAttribute('type', 'radio');
newInput2.setAttribute('name', 'rdoAddRemove_' + rowIndex);
newInput2.setAttribute('id', 'rdoRemove_' + rowIndex);
newInput2.setAttribute('value', 'Remove');
newLabel1.setAttribute('for', 'rdoAdd_' + rowIndex);
newLabel2.setAttribute('for', 'rdoRemove_' + rowIndex);

// append the elements to the cell
newCell.appendChild(newInput1);
newCell.appendChild(newLabel1);
newCell.appendChild(newInput2);
newCell.appendChild(newLabel2);

So you can see what I’m trying to do here, and so could Firefox, because it built the code correctly.

IE, on the other hand, displayed the radio buttons, but wouldn’t allow the user to select them. After much hair-pulling and fretting, (because I can’t find a Firebug equivalent for IE), I discovered that IE wasn’t adding the ‘name’ attributes to the ‘input’ elements.

Apparently (and I’ve lost the link now) IE has a ‘feature’ that means you can’t change the name of an element once it has been created.

So I tried this:

newInput = document.createElement('<input name="rdoAddRemove_' + rowIndex + '" />' );

Yay! It now works in IE! …but the good browsers spat the dummy. And I really felt that if I were going to do this then I might as well ‘innerHTML’ everything.

So I remembered my good old friend try {...} catch(err) {...} and came up with this:

try {
	// IE will eat this, FF Safari and others will choke on it.
	newInput1 = document.createElement('<input name="rdoAddRemove_' + rowIndex + '" />');
	newInput2 = document.createElement('<input name="rdoAddRemove_' + rowIndex + '" />');
} catch(err) {
	// Good browsers will eat this instead.
	newInput1 = document.createElement('input');
	newInput2 = document.createElement('input');
}

Now whether this is the best way to do it or not, I don’t know, but it worked in all the browsers I tested it in so I’m happy(-ish).

GRRRRR @ IE for wasting my afternoon!!

E-mail was invented so people could quickly exchange text messages over fast or slow or really slow connections, using simple, non-processor-intensive applications on any computing platform, or using phones, or hand-held devices, or almost anything else that can display text and permits typing.

Amen. There is some interesting debate in the comments. So, it’s plain text for me. What do you think?

Go check out other nakedness!

Update: It’s no longer the 5^th of April; clothes are back on.