March 2004 Archives

How not to use HTML

I love 'How not to do...' things. They amuse me.

Here's an immensely bloated example of how not to use HTML. I'll warn you in advance that it's over half a megabyte in size.

That's right, half a megabyte. For an HTML page.

Go on over to the homepage of law firm Hammonds.

Wait for it to load.

And wait.

Wait for 326KB of the page itself, 197KB for the main image and a bit more for a number of other files.

That's over 550KB. 5267 lines of code (just for the main page itself) that includes some mad JavaScript.

Has it loaded yet? On a 56k modem it should take around one and a half minutes.

Tuesday 30 March, 2004 (12:00 PM GMT) | Comments (16) / Permanent Link

Holiday Checklist

RIGHT THEN! I'm off. Like an old banana.

Here's a brief checklist for web designers who won't be behind their computers for any length of time, for those who might be going on holiday for example:

Unsubscribe from mailing lists

You're going to have your hands full as it is wiping out spam and catching up on legitimate emails on your return. You don't want to have to deal with a billion extra emails. I've already unsubscribed from CSS-D, Web Design-L and Evolt's The List. On a side note, as helpful and interesting as these lists have been, I don't see myself re-subscribing. I have spent too much time deleting emails that I haven't had time to read already.

Turn off blog comments

If you've got a web log, don't open your website to weeks of potential unchecked abuse. The Dog Blog has already had its fair share of idiots trying to promote their porn sites. When I'm behind the computer it's okay - I can deal with the nuisance straight away.

Check your webmail

If you can't do it yourself, get someone else to check your Hotmail so the bastards don't delete everything after x number of days. I have learned a very important lesson from this in the past. In fact, the lesson I learned was not to use Hotmail at all.

Don't think about computers

Empty that part of your brain into a jar, put it in the fridge and shove it back into your head when you get back.

Finally...

Don't wear Speedos.

Have fun. Expect the next post at the start of April.

Wednesday 10 March, 2004 ( 1:11 PM GMT) | Comments (1) / Permanent Link

New Zen Garden Trio

The infamous CSS Zen Garden needs no promotion, but I felt compelled to mention the latest batch of designs.

Sometimes the designs are a little hit and miss (the hits being some of the best designs I have ever seen), especially on a technical level, but Oceans Apart, Start Listening and Springtime are all original, striking and so different from each other that in themselves alone they demonstrate what the Zen Garden and Web Standards are all about - separating a structure, which is the same across all of the designs, and presentation, which can be so radically different.

Tuesday 9 March, 2004 ( 2:19 PM GMT) | Comments (3) / Permanent Link

Against my better judgement...

Now and then a web maker or two might fall bored, reach the heights (or depths?) of geekdom and come up with some Web Standards jokes...

Q: Why did the XHTML actress turn down an Oscar?
A: Because she refused to be involved in the presentation.

Q: Why was the font tag an orphan?
A: Because it didn't have a font-family.

Q: Why do CSS designers have too many children?
A: Because they employ lots of child selectors.

Q: Why was IE5's 3-metre wide cell in the insane asylum smaller than IE6's 3-metre wide cell?
A: Because the width of the cell included the padding.

And my personal favourite...

Q: Why was the XHTML bird an invalid?
A: Because it wasn't nested properly.

Boom boom.

I hang my head in shame...

Friday 5 March, 2004 (10:31 AM GMT) | Comments (20) / Permanent Link

Ditching Accessibility?

I have decided to stop claiming that HTML Dog is 'AAA' compliant, the highest level of accessibility as defined by the W3C's Web Accessibility Initiative.

Unfortunately, I think that claims of WAI guideline compliance often follow an attitude of 'ah, well, it's close enough' or are simply based on something such as 'Bobby AAA approved', which is quite meaningless because there are so many factors that an automated program cannot take into account, which can leave a completely inaccessible page that falls way short of the intended WAI AAA.

It isn't as easy to judge standards compliance when it comes to accessibility as it is when it comes to code, because there is so much that is open to interpretation. But in my opinion, even after any interpretation, sites claiming compliance often bend the guidelines to such an extent that they do not live up to their claim. A 'near enough' attitude is like having a perfectly valid XHTML 1.1 document bar a few font tags here and there. It is simply incorrect to claim that you are compliant with something if even the smallest detail of a standard is not adhered to. You can't pick and choose - that's the whole point of Standards.

'Guidelines'?

A possible train of thought regarding the Web Content Accessibility Guidelines is "OK, these are guidelines. I have considered them all, but decided not to implement a single one. I can still call my web page AAA". Logically, for guidelines, a pedant could claim that this argument is quite sound. As guidelines, the WAI recommendations are great and this is where they hold their strongest value but when the 'A', 'AA' and 'AAA' stamps are used, this becomes a suggestion that the guidelines have been accepted and adhered to as rules.

I'm not sure how possible it actually is to achieve true unarguable AAA compliance without making some design compromises. As one example, I prefer elastic elements, but absolute units are sometimes required to achieve a certain effect. HTML Dog uses one-pixel width borders and the header now has a fixed height measured in pixels. WCAG checkpoint 3.4 reads "Use relative rather than absolute units in markup language attribute values and style sheet property values." - no mention of text - units in general. So according to this, even using pixel-width borders is not compliant.

But these accessibility 'compromises' I have made are not compromises at all - the border widths are insignificant and the graphical header is sufficiently large enough for the visually impaired to read and actually not overly-important to the actual content anyway. It is my argument that the site is just as accessible.

Another area where I would say that HTML Dog also breaks WCAG is when it comes to accesskeys (many of which have been removed due to conflicts with browser shortcuts).

So What To Do?

Many might not argue with a statement that HTML Dog is 'AAA compliant' because the WAI is often vague and can be interpreted in different ways (often by tempting a few round pegs into square holes). In fact I think that this site is more compliant than many web sites that claim this high accessibility standard. But I am simply no longer comfortable with either strictly adhering to the WAI guidelines or with bending them and claiming to adhere to them.

I believe that the WAI. is a good thing and that standardising accessibility initiatives is a necessary step towards their proliferation. Ahead of the WCAG 2.0, one solution to this problem could be to have an independent accessibility statement built around the WCAG.

The WCAG 2.0 may well clear things up and be more up to date but at the moment we're stuck with version 1.0 and although it may be flawed, if a web page claims to adhere to that standard then it should.

Tuesday 2 March, 2004 ( 5:27 PM GMT) | Comments (7) / Permanent Link