tmp.templateFile = COA
tmp.templateFile {
	10 = COA
	10 {
		if.isFalse.numRows < styles.content.getRight
		10 = FILE
		10 {
			file = fileadmin/template/1col.html
		}
	}
	20 = COA
	20 {
		if.isTrue.numRows < styles.content.getRight
		10 = FILE
		10 {
			file = fileadmin/template/2col.html
		}
	}
}

The ifs check if there is or isn’t content in the right column and the COA returns the correct cObject, FILE in this case.

And then in your main typoscript something like:

page.10.template < tmp.templateFile

instead of the more usual

page {
	10 = TEMPLATE
	10 {
		template = FILE
		template {
			file = fileadmin/template/1col.html
		}
	}
}

That’s all.

Usability

Tab Kit: My favorite tab extension. Has many many features, I use it mostly because it allow more than one row of tabs and tab grouping/collapsing.

Clear Fields: This solves a quite annoying issue with Firefox and the xorg clipboard. Xorgs lets you paste things that you have highlighted with the mouse by simply clicking the middle mouse button. However, the previous contents of the search and address fields don’t get cleared. This adds buttons to clear those fields before pasting.

Development and Webdesign

Firebug: The swiss army knife of web developer add-ons. To quote from it’s description: “You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page”. Very power- and useful.

Gridfox: Indispensable while making grid-based layouts or aligning text to a base grid.

Live HTTP headers: This is rather esoteric, but very useful for JavaScript debugging and web app development.

Web Developer: This is what I used before Firebug existed, and it’s still useful today.

MeasureIt:This is very useful for quickly measuring the size of various elements on a page.

Privacy/Security

Cookie Monster: The best cookie manager I could find. I always block all 3rd party cookies, and by default no website is allowed to store cookies on my computer. Cookie monster makes it very easy to allow cookies for sites I visit. Another nice feature is to only allow session cookies for some sites.

Flashblock: Blocks all annoying flash animations. Can whitelist sites of course. A must.

NoScript: Blocks all (3rd party) JavaScript. Indispensable security tool and gets rid of most ads as well.

There was a time when websites used “Best viewed in Internet Explorer” or “Best viewed in Netscape” kind of texts and banners. Some sites even blocked you if you were using the ‘wrong’ browser (it still happens today). That was stupid in the 90s, and locking out IE6 isn’t any smarter today.

If you want to behave like the “Best viewed in Internet Explorer” crowd of the 90s just go ahead. There was a different movement back then that still exists today: Viewable With Any Browser. There’s really no need to punish some minority browsers.

Anyone who slaps a ‘this page is best viewed with Browser X’ label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network.

Tim Berners-Lee in Technology Review, July 1996

I guess I’ll just go on and build sites that are more or less standards-compliant and hopefully don’t require special tweaking for IE6. There are enough cross-browser tools out there. Just use your favorite search engine to find JavaScript libraries, CSS frameworks etc. Of course, something will always break in the old IEs, but don’t waste time breaking it on purpose.

Update: Just found this gem from the gif-crazy 90s and had to add it:

display: block;

Other display configurations seem to create the same problem. Opera’s behaviour is incorrect, see the specs as Dave points out.

I was a little surprised, I guess more plugins will break. A fix, of course, is to simply remove ozh-admin-drop-down-menu from your wordpress/wp-content/plugins/ folder.

One of the things Ozh’s menu does is to look for the #adminmenu list and hide it. I’m not sure who’s the culprit here, the wordpress developers for not renaming their css class while doing such fundamental changes or Ozh for not checking the wordpress version. Well, it’s still a beta and maybe someone will include a better fix.

The new admin menu is kind of neat, but I think Ozh’s menu is far superior. We’ll see if Ozh changes his mind.

Update: The plugin has been updated and works fine in 2.7 now. I liked the old look better, but the improved usability and speed is what matters most to me.

So inside the domready event I simply did:

1
2
3
4
5
6
7
8
9
10
11
12

function inputify(elem) {
    elem.focus();
    elem.addEvents({
        'keydown': function(event) {
            if (event.key === 'backspace' && !elem.value) {
                history.back();
            }
        }
    });
}
 
inputify( $('SomeInputfieldById') );

Great, reusable, everthing works fine. Ok, so let’s incorporate my ideas from my HTML forms and onclick/onfocus post (basically, select on click instead of focus and pre-fill the input field):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

function inputify(elem) {
    var startvalue = elem.value;
    elem.select();
    elem.addEvents({
        'keydown': function(event) {
            if (event.key === 'backspace' && elem.value === startvalue) {
                history.back();
            }
        },
        'click': function() {
            elem.select();
        }
    });
}
 
inputify( $('SomeInputfieldById') );

Great works fine. Remember pre-filled value and only go back in history when the user hasn’t changed it. Done.

Wait… oh, noes! The backspace button is supposed to delete the input. Now, most users will unwillingly trigger the history back function. That’s as broken as it gets… Well, in theory I could focus the input field instead of selecting it, and use something like caretPos, and only go back in history if it’s at the start… But that’s not what I had in mind (well not sure what I was thinking anyway…)

So I consider this technique unusable for the time being for my own sites. The only times I focus some input field onload is for search functions anyway. There, I’d rather annoy a few users and improve the overall usability of the site. Like Harmen said in his post, don’t use onload input focus just because you can

Seriously, how can somebody miss that his complete page layout shifts some pixels to the left or right when looking at different pages of the same site.

Consider this, twitter without a scrollbar (I think this was my profile page).

The same site, but now with a scrollbar. Notice how all the content moves to the left.

On the next image I made an overlay of both shots to make the layout shifting more obvious.

In my opinion this is one of the biggest design errors, and everybody does it. And – it’s ridiculously easy to fix:

html {
    overflow-y: scroll;
}

Not using this is really hurting a website’s usability. When a user clicks on some navigation element the navigation is supposed to be at the same place on the next page. So, force the vertical scroll bar!

Now I just need to hire myself a good designer to make my page look good

When the user clicks into the field you’ll want to remove the clue. The obvious way to do this is to add an onclick JavaScript command:

<form>
    <input onclick="this.value=''" type="text" value="Your email" />
</form>

The user can still access the input field through other means than clicking. He can use the tab key for example. That’s why usually the onfocus event is more useful:

<form>
    <input onfocus="this.value=''" type="text" value="Your email" />
</form>

This seems to work nicely. However there’s still a problem. When a user fills in his email address, reads a little more on your site and clicks the input field again, his address will be removed again! So to make sure this doesn’t happen we add a little check for the content of the field:

<form>
    <input type="text" value="Your email" onfocus="if (this.value == 'Your email') {this.value=''}" />
</form>

And here it is:

Restore default value if nothing is entered

Ok, now this is working. However, when your visitor decides not to input any data, the field stays empty. If you have no label for the input he or she might forget what the field was for. We fix this by restoring the default value when the input field is left:

<form>
    <input type="text" value="Your email" onblur="if(this.value == '') { this.value='Your email'}" onfocus="if (this.value == 'Your email') {this.value=''}" />
</form>

Thanks to Ray for his example linked in the comments.

Select onclick

But sometimes this isn’t the best solution. It could be more desirable to highlight the content of the input field if you’re offering some kind of search. The user may not want to start a new search but to modify the existing one.

By highlighting the input field the user can choose to either empy it by starting to type or to modify it by using the arrow keys.

<form>
    <input onfocus="this.select()" type="text" value="Your previous searcj" />
</form>

Dynamic input color

This is a little advanced. Let’s assume you want the default value to be in a different color and change it onclick. This is one working solution:

<form>
    <input style="color: #f00" type="text" value="Your email" onblur="if(this.value == '') { this.style.color='#f00'; this.value='Your email'}" onfocus="if (this.value == 'Your email') {this.style.color='#0f0'; this.value=''}" />
</form>

Keep in mind that this might create problems when you reload the page. Some browsers will remember the value of the input field, and the color will be different even though the field does not contain the default value. Fixing that is beyond the scope of this post. See onload and domready events.