I felt I had to point this one out: Joe Clark’s excel­lent Failed Redesigns.

When teenagers’ hobby­ist blogs (short for “Web logs”) have better code than brand-new Web sites, somebody’s doing something wrong. And that somebody is you, the developer. In a just society you would simply be fired; in an Orwellian society you would be sent to a reëdu­ca­tion camp. Failing either of those, you could at least read a fucking book and upgrade your skills to a point where you are no longer a total laughingstock.

100% of brilliant, and absolutely right. If you’re making money from build­ing websites (i.e. you’re a web profes­sional), bloody well do it properly you lazy sods.

…you’re not the only one getting to the end of your tether.

We had a major website release to put together the other day. We’d fixed every possible bug we could find in the C#, HTML and JS code, bar one: A CSS bug in Internet Explorer was break­ing something vital.

I don’t get visibly angry very often, but on this occasion I was absolutely steam­ing. People were waiting on me to find this fix so we could do the release and go home, but I just could not figure it out. I tried margins, padding, heights, widths, overflow, even obscure position­ing techniques. Everything I could think of — all to no avail. I was getting more and more frustrated as time went by but that wasn’t helping either. The handy developer toolbar wasn’t helping — it pointed out that element had the right amount of margin, padding and their wierd hasLay­out property.

Ahhhhh, all of them except that seemingly completely unrelated one. I hadn’t fed a specific height to one element and the whole thing came crash­ing down.

Once I figured it out, that anger faded away to relief and we got the release out of the door. But it made me think: a CSS designer/developer’s profes­sion requires that they pander to a product that despite being vastly technic­ally inferior, is the most popular on the market.

Despite all of this though, I could never contem­plate going back to the old way: Using <table> and spacer.gifs to lay out and style a page. I’d need to retrain all over again for a start — I really can’t remem­ber most of the old tricks we used to use back in the day. There’s one partic­u­lar (internal) website at work that’s horrendous in that regard — it uses every trick in the book so the slight­est change takes hours. What’s more, it limits you in so many ways: Would Sir like to position this box over there? Or perhaps Sir would like a slightly differ­ent layout when he comes to print, or when serving to a handheld browser? Sorry Sir, no can do.

Yes, the pain of pander­ing to Internet Explorer is defin­itely offset by the advant­ages that the standards-based method­o­logy offers.

I’m sure I’ve mentioned this before. Internet Explorer 6 is quite possibly the worst bit of software I have ever encountered.

The thing is, from the front end it’s not really too bad. OK, so it’s looking a bit dated, but as far as the user can see, it renders web pages without complaint, it’s not too slow, it’s got a fairly easy to use bookmarks system. It’s simple. We can’t get people to upgrade because (as far as they know) it does the job perfectly well. They simply don’t know that they can do so much better.

From the other end though — the point of view of the developer — it’s a complete night­mare. I’ve sure already covered the myriad ways in which the HTML, CSS and caching parts of the engine are funda­ment­ally broken. Now, it seems, the Javsacript engine is completely borked aswell. I won’t go into the details (I’ll only end up getting angry and dumping a truck­load of slurry on Micorsoft’s doorstep), but suffice to say that it runs like a dog on IE6, though every other browser executes it like it’s Thrust SSC on speed. Great. Some resources to help if you’ve in a similar situation:

• Optimizing JavaScript for Execution Speed
• A compen­dium of JavaScript optim­iz­a­tion techniques
• Javascript Closures
• JavaScript Memory Leaks
• PPK on Javascript memory leaks
• DHTML leaks … not so much, actually
• Fixing JavaScript memory leaks for good.
• BeeByte’s JS Links

Someone remind me, just how did IE6 get through Microsoft’s quality control program? Roll on IE7, I say.

I had a bit of geek pleas­ure this week. I took an in-house web-application and tidied it’s output up. What was once a pile of tag-soup junk is now clean, access­ible, sentat­ic­ally correct, valid HTML. This was relat­ively easy, once I’d got my head around the way the app works. It’s quite nice now — but it sits on our intranet, so you’ll never get to see it unless you happen to work in the same place I do.

Then I got cocky. I thought If I can do that for that app, why can’t I do it for this ever so slightly more complex one?

So I started looking at the source files. Holy crap! It looks like the code was written by a gibbon jumping up and down on the keyboard! As soon as I started trying to tidy it up, things got squelchy. Undo, undo undo! Put it back exactly how it was! Phew. Making that one look nice is going to be an inter­est­ing experience.

Still, I think it’s worth doing, even if it’s “just” an in-house intranet applic­a­tion. Your in-house custom­ers are just as import­ant as the outside ones. If you don’t keep them happy, the products and services that they produce for outside custom­ers won’t be as good. Keeping the inter­face and the code clean and access­ible means that it’ll be nicer for user’s to inter­act with. What’s more, it’ll be easier for the next set of program­mers and design­ers to work with next time around.

I’m currently working my way through a sample chapter Sitepoint’s DHTML Utopia book — partly to see if I want to buy the book, and partly because I’m trying to get my head around event listen­ers. I got some way through the chapter, testing my work in Firefox as I went, and it was all going swimmingly.

What happens in Internet Explorer then?, thinks I. Precisely nowt. It was at this point that my colleagues looked around to see what the swear­ing was all about. From the book:

Naturally, making events work cross-browser is not as easy as just follow­ing the DOM stand­ard. Internet Explorer doesn’t imple­ment the DOM Events model very well. Instead, it offers a propri­et­ary and differ­ent way to hook up event listen­ers and gain access to event data.

What’s the point in having a stand­ard if the most popular sodding browser is going to completely ignore it!?

Luckily, the book explains ways around Internet Explorer’s Javascript deficien­cies in a calm and friendly manner (e.g. This is incon­veni­ent but not catastrophic; it just means that you have to take differ­ent actions for differ­ent browsers.). It’s entirely possible that I’ll buy the book, simply because it’ll help dig me out of some big holes.

WARNING IE USERS! STROBE EFFECTS LIKELY!

So, I decided to try apply­ing the lessons learned to one of my own projects. It was all going fine, up until I went to test it in IE. This time, the scripts were working perfectly. No, IE had to find some other way of bugger­ing it up. Now, every time an event was fired, IE decided to re-load all of the background images in the elements effected. Flickerytastic dude! Does this mean I have to put an epilepsy warning up on the page? I navig­ate away, click ‘back’ and all is fine again.

A bit of googling, asking around on mailing lists, and tearing out of my fast-greying hair reveals that are two ways of fixing the problem:

1. Get every single one of your visit­ors using Internet Explorer, AOL, or indeed anything else that uses the IE engine, to alter their Internet Options: Go to Temporary Internet Files, then Settings, then choose Automatic. Realistically, that’s not going to happen is it?
2. Get your server to add the Cache-control header to the images on your server. Doing this works differ­ently for differ­ent servers: ASP.net Resources has the fix for IIS, Dean Edwards has the fix for Apache. If you’re using something else you’ll have to rely on google.

It’s really frustrat­ing that every time I try to do almost anything on the web, Internet Explorer jumps in front of me and holds up an enourmous stop sign. It’s good in a way, in that it forces me to find an accept­able way around the problem. I just wish finding that answer didn’t usually double the time it takes to complete a project. If IE7 really has improved as much as Microsoft say it has, I can’t wait for it to arrive. It’s just a pity that IE5, 5.5 and 6 will continue to linger for as long as they inevit­ably will.

A couple of years back, when working for a small design firm, I put together a little website for a new restaur­ant in Leicester, called Mobius.

I was quite proud of it at the time, except for the glaring bug. It makes use of the Suckerfish menu system. Due to a (still unfixed) bug in Gecko-based browsers (includ­ing Firefox), if the menu inter­sects with an element which has a style of overflow:auto;, it’ll disap­pear as soon as you mouse-over that element.

At the time this really annoyed me. I posted on various web-forums asking if anybody had come across the same problem and if so, how they went about fixing it. It soon became clear that it was a bug in the browser, and there wasn’t a lot I could do about it. In the end, I gave up and left it. At the time, Firefox was very much a niche browser, not one who had been downloaded by 80 million users and was coast­ing comfort­ably past the 10% market share point. Alas, the site still suffers from the problem, just as it always did.

Out of the blue

Now, I was quite surprised when out of the blue, two years later, someone calling themselves “Event Horizon” emailed me out of the blue with a poten­tial fix for the problem. “Perhaps you could apply this fix on the Mobius site you worked on.” they said. “Not likely” I replied, “I don’t work there anymore, but thanks nonetheless”.

The very next day, I was ever so slightly taken aback once more, when I took a phonecall from Mark Sanders at Chorlton Web & Design. “Two years ago” he said, “you had some problems with overflow in Firefox”. “Indeed I did” said I, “and in a very odd turn of events, I got an email about the fix last night”. “Bloody Hell!” exclaimed he. Very bizarre.

Anyway, I figured that if two people were going to contact me about the problem in the same week, there’s quite a demand for this knowledge. So I thought I’d share the story and the link to the solution. I hope it’s useful to someone.

A friend of mine wants to get into this whole web-building thang — but doesn’t really know where to start. He asked me for some help, and I replied with something along these lines…

What do you think the best way to do things is? I’m guess­ing HTML as the basic ground­work — then onto XHTML and CSS, with Flash & JavaScript for the movey bits. then maybe onto XML and PHP?

I could write a whole book on this, but I’ll try to keep it relatviely brief for now. I’d do it like this:

First things first: Download and install Mozilla Firefox. Its gener­ally a much better web-browser than Internet Explorer, and follows the stand­ards much more closely, which makes it a much better browser to work with during development.

Now that you’ve got a decent browser, you should start by learn­ing your basic XHTML. Don’t worry at all about how the thing looks at this point — its all about document struc­ture, and using the right tag for the job. A few examples would be:

Use <div> tags to divide a document up into logical divisions, such as <div id="header">, <div id="navigation">, <div id="content"> and <div id="footer">.

Use <hx> tags for all of your headings, e.g. <h1>Level 1 Heading</h1>, <h2>Sub Heading</h2>, <h3>Sub-sub heading</h3>, all the way down to <h6>.

Pick up a magazine, or a diary. Look how they are set out and try to match up the XHTML tag with the content. <h1-6> for headings, <p> for paragraphs, <strong> and/or <em> to strengthen or emphas­ise text, <table> and its siblings for tabular data (and not for page layout).

Make sure that your code valid­ates — upload it to http://validator.w3.org/ to check it out. Only then can you blame the browser if it gets things wrong.

I know that this bit isn’t in the least bit excit­ing, but its very import­ant that you get this bit right. Do it properly and you’ve gone a long way towards getting access­ib­il­ity issues and search engine friend­li­ness sorted right from the word go. In this day and age, those are very import­ant features in any website.

Once you’ve got a ground­ing with XHTML, you can start on your CSS. Start basic and get more complex as you get the hang of it. Make sure your code is correct over at the CSS Validator: http://jigsaw.w3.org/css-validator/

One of the best places to start out with CSS is Mako4CSS. Some of the inform­a­tion is out of date and refers to Netscape Navigator 4 — you can safely ignore that these days. Once you’ve got the hang of the basics, take a look at places like CSS-Discuss and the Sitepoint forums. If you want to see just what’s possible with CSS, take a look at the CSS Zen Garden.

Try not to curse Internet Explorer for getting it horribly wrong. Its really not a very good browser anymore, but millions of people still use it. A good place for finding ways of working around its flaws is Position is Everything.

Once you’ve got this ground­work down, you might like to start exper­i­ment­ing with a bit of ECMAScript (its what they call JavaScript these days), Flash or PHP.

The import­ant thing here is that you shouldn’t rely on client-side techniques (i.e. browser script­ing and plug-ins) for critical site function­al­ity. If the user has it switched off, or the plug-in isn’t installed, or they’re simply using an older browser, your site should degrade gracefully.

For instance, if you display some critical inform­a­tion using Flash, you should fall back to an altern­at­ive method (plain text is probably fine) for users who don’t have it installed.

Another example would be form valid­a­tion — its helpful to have a ECMAScript alert telling you that the email field is compuls­ory for instance, but this should be backed up on the server side (for isntance with a PHP script), in case the user has disabled ECMAScript.

As for books, I’ve never used any, but I’m told the follow­ing ones are good:

• Elizabeth Castro: Creating Web Pages with HTML: Visual QuickProject Guide
• Zeldman: Designing with Web Standards
• Dan Cederholm: Web Standards Solutions
• Eric Meyer on CSS

I hope thats helpful, and let me know if you’ve got any further questions on any of it.

Cheers,
 
 
 
Olly.

Just a quickie to tell you that I’ve upgraded the gallery to SPG Version 1.1.

I’ve made it work in all of the browsers I’ve got here (Firefox1.0, Opera7.5, IE5.0, IE5.5, IE6.0, all on Windows XP SP2). If you’ve got something differ­ent, could you have a look and let me know if its OK please?

Its not perfect in Internet Explorer 5.x but it’ll have to do for now. It was bloody hard work making IE5.0 work at all! I had to jump through all manner of hoops to work around the bugs in that one, but I think we got there in the end.