Stuart Homfray The Weblog

Matt Cutt’s Google Guides

The esteemed Matt Cutts of Google releases a set of videos on various aspects of Search Engine Optimisation, starting with ‘Qualities of a good site‘.

Matt talks about all sorts of issues relating to SEO and Google and it’s definitely worth checking out the other sessions too (see Matt’s ‘Movies‘ blog archive).

Broken Styles in HTML Email

Personally, I’m not a fan of HTML email (plain text seems so much cleaner and more efficient), but anyway, here’s a quick note for anyone having problems with their CSS-styled HTML email within Mozilla’s Thunderbird client.

Last month, the Lockergnome HTML newsletters were looking a little strange; capitalised words throughout and partially rendered styles - Big Chief Chris Pirillo was clearly a little peeved by Mozilla’s baby! After taking a quick look around, it turned out that the problem was down to a line break within a couple of the font values. Here’s an example of one of the CSS rules within the problematical email:

body { color: #000; margin: 10px; padding: 0; background: #fff;
font: 9pt "Lucida Sans Unicode", "Lucida Sans", "Trebuchet
MS", verdana, sans-serif;}

Note the line break between ‘Trebuchet‘ and ‘MS‘ - remove this and everything works as expected!

What’s happening here? Well, if you attempt to validate this rule, you get the slightly cryptic message ‘Invalid number : font Parse Error - “Trebuchet MS”, verdana, sans-serif‘. It’s not overly clear what that means, is it? Time to dig a little deeper.

You may not have realised this, but a line break within a style value is invalid (’smacked wrists’ for me there too for not reading ‘Rules for handling parsing errors‘ thoroughly enough, particularly the ‘Unexpected end of string’ section!) I must admit that I’ve not come across this before, though: perhaps it’s down to the fact that I tend to write my stylesheets by hand - I would never deliberately stick a line-break in there!

There was no problem with the newsletter layout in anything using the Trident rendering engine (IE6 and Outlook/Outlook Express), but as anyone that creates CSS knows, Trident IV and earlier can be rather forgiving when it comes to style rules. The Gecko rendering engine, however, conforms to the CSS 2.1 specification in it’s behaviour. The fact that the layout looked correct within Trident and wrong in Gecko usually suggests (around 99.5% of the time anyway) that the problem lies within the CSS rather than Thunderbird/Firefox.

I’ve also tested this in Safari 2.0.4 (WebCore layout engine) and Opera 9 (Presto engine) too. Anyone using Mail within OSX or the Opera email client M2 would have seen the same problems as those exhibited by Gecko.

After I sent a message about this to Chris (and I must admit that I did not, at that point, state that the problem was invalid CSS) he pointed out that he was having a bit of trouble preventing his mailer system from wrapping lines. He’s obviously won the battle now, though, as everything looks hunky-dory!

So what’s the lesson here? The same as always - if at first you don’t succeed, make sure that

1. the software’s not playing up, and
2. the damn CSS validates! :)

Say No To Photo Cliches

Sometimes, those clients that want the ‘ultra-corporate’ look, ask (even demand) that I include one of those images that can be seen again and again on the web… I’m talking about corporate photo clipart. (Sorry Fotosearch, I’m not picking on you in particular!!)

We’ve all seen it, and unfortunately, it still seems to be quite prevalent around some UK SMEs (although I’m not mentioning any client names in particular!) Forty Media have also noticed this, and have illustrated the point wonderfully with their Ten Top Stock Photography Cliches.

If you’re intending to ask me to carry out any work on your website, please, please, PLEASE try not to include any images like these. Your customers (and I!) will be eternally grateful! :)

Fixed positioning within Internet Explorer 6

In the April 25th edition of the Practical Web Design magazine podcast (OK, I’m just catching up with my podcasts), Paul Boag talks about keeping an item fixed on the page when scrolling the main page content. As he says, this can be a lot easier to show than describe, so you might want to jump straight to the working example created for this post.

Paul describes how this effect is very easy to achieve (using the position: fixed declaration) in pretty much every browser except one: Internet Explorer 6 (obviously versions 5.x too). He goes on to say that in order to get around the problem, you need to do three things:

1. add an extra container around the scrollable content,
2. place the non-scrollable item outside this container, and
3. make the <body> itself, non-scrollable

He also highlights an article from last year at Sitepoint that utilises Javascript to fix IE by adding the extra container to the content, just so that the nice browsers don’t have to get this extra little <div> markup.

Personally, I’m not so sure that I agree with their statement that adding an extra <div> is more likely to hinder than help the browsers that don’t require it, so I’ve set up this quick’n'easy ‘how to make position:fixed work within IE‘ page. The menu is sized using ems, so it will grow or shrink depending on browser preferences (oh, and if you’re worried about the horizontal scrollbar that appears when you really whack the text size up, don’t - it’s caused by the HTML/CSS shown on the page!)

And one other thing, I have to recommend Paul’s excellent weekly Boagworld podcast - not so much ‘teccy’, more a little tetchy (sorry Paul, the old pun gland’s gone to sleep!!)

Opera 9 beta and List Items Containing Floated Elements

The other day, Ryan forwarded me an email from a user stating that Vitamin was looking decidedly unhealthy in Opera 9 (build 8303 to be exact, one of the preview builds). Here’s an example of what was happening:

See the highlighted area? Opera 9.0 beta did this!

And if you want to check for yourself within Opera 9, here’s a stripped down version of the page that illustrates the problem (the relevant CSS is embedded).

After downloading a newer version of Opera 9 (the beta 1 version, build 8367), I could see the problem for myself: this version of Opera does not like the nice overflow:hidden method for containing floats when it’s applied to a list-item element! I’m not entirely sure why - other web browsers, like Opera 8.54, Firefox 1.5, IE6[1], Safari 2.0.x, etc. seem more than happy, but there it is!

It turns out that the fix for this problem is very straightforward: you need to turn the list element into a block-level element! You could do this by floating the element (which works in the stripped down example, and may work for you) or, as I did with Vitamin, you could simply add display:block, like so:

#features li {
  margin: 0 10px 10px 10px;
  border: 1px solid #d7d18c;
  background-color: #fff;
  padding: 0.8em;
  overflow: hidden;
  display: block; /* add me for Opera 9.0! */
}

Here’s a working version of the stripped-down page (so that you don’t have to waste all that time typing in the extra CSS!!)

And don’t worry about the other browsers - the fix doesn’t affect them at all!

Internet Explorer 6 Note:

IE6 requires a hasLayout fix. On Vitamin, I used the Holly Hack’s height:1% declaration within an external style sheet for IE browser versions below 7 (yes, I’m assuming the problem won’t affect the final build of IE7!!)

Return to footnote link