Tom Gilder's Blog

RNIB CSS++

Simon Willison's most excellent efforts started it, but while he's gone off to Glastonbury, I thought I'd have a bash at improving it. So far:

• Made navigation resize better, but design still falls apart below 700px-ish
• Removed the one layout table and replaced with floats
• Moved some presentational-only images to CSS
• Slightly changed some HTML to make it more semantic

Doesn't look too pretty on IE5.x/win, will hopefully fix that later. I also don't have a mac to test it on, and I don't know if I ever will do due to Parcel Force being incompetent, grrr.

Posted at 16:15 GMT | Comments (1) |

More psychic IE reporting

The Web Standards Project have got an article up about the future of IE. Again, they too seem to have amazing psychic abilities to state as fact that MS won't upgrade Trident (IE/win's rendering engine) before Longhorn (see my previous post on the matter).

But other than that, I would really like to know why they consider the lack of CSS2 selectors, W3C DOM event model, border-spacing and position:fixed support to be bugs in IE though..? None of those, to me, are bugs. They're simply unimplemented features. Microsoft have never claimed full CSS2 support, nor have they attempted to change their event model.

Switching to the W3C DOM event model in IE would break literally thousands of web pages and applications. I have absolutely no idea how they could implement it without that happening (anyone got any ideas on that subject, actually?).

Adding CSS2 selector support without proper CSS2 property support would also be suicidal, and break numerous sites which use them as a bit of a hack (like * > #test). Fixed positioning would be nice, but is easy to emulate and not exactly the most essential thing ever.

The real bugs in IE6 are regressions or long-standing CSS bugs (primarily to do with floating and position), and to do with them basing IE4's original HTML4 support on a draft version of the specification (which explains the lack of <abbr> support), and never properly updating it.

Posted at 15:25 GMT | Comments (4) |

404: No Sense Found

OK. So there's a dog. On Amazon.co.uk's not found page. And the picture of the dog has the filename say-what-man.gif. WHAT?!

Best commercial 404 page most certainly still goes to Netscape though. Gotta love that expression.

Posted at 01:06 GMT | Comments (1) |

Thoughts on XHTML

There is currently a very interesting discussion going on on the WAI Interest Group list, regarding XHTML's accessibility, and more specifically browsers rejecting XHTML which isn't well-formed XML.

I've been thinking about that subject for quite a while now, because I'm really not sure if it's a good thing for the web. Currently the only error messages users generally see are server-side problems: 404s, broken CGI/ASP/PHP/etc, or dead servers, and client-side script errors don't pop-up by default in any modern browser. Never before have users had to confront being told pages cannot be rendered at all because the author mucked up.

Clearly authors being forced to validate pages is a good thing for standards. But it's also an awful thing for users. Users just don't care that an author hasn't nested their elements correctly, they just want to use the site. However the XHTML specifications don't allow browsers to attempt to fix broken XML.

So what, in reality, will happen with XHTML on commercial websites (please note: I'm talking about proper XHTML, served as application/xhtml+xml)? My prediction is that at first sites will experiment with it. If they find they can't keep sites valid, they'll just keep serving XHTML as text/html, or straight go back to HTML. Alternatively, they'll look into different ways of generating XHTML: which is what I think authors need to be experimenting with right now.

Here's some random ideas on what could be done to keep pages working:

• XHTML can be generated from a server-side programming language instead of being hand-coded, meaning little slip-ups are less likely to happen.
• Documents can be checked for well-formedness when they are authored, before going public, by content management systems.
• Servers could check the validity of documents when they're first accessed, and if found to be not valid attempt to fix with something like HTML Tidy, and serve the instead (caching the fixed copy to be resource-friendly).
• Browsers could bend the rules a bit and display a warning about invalid XML, but ask the user if they'd like to shove the document through a tag-soup parser.
• Proxies could be put between users and pages, which fix broken XML before it gets to the browser.

Web standards need to focus on the user, and having pages just work, all the time. Because after all, if documents aren't readable, what's the point in any of this?

Posted at 00:09 GMT | Comments (1) |

Accessibility: Don't forget your signature!

Care about web accessibility? Good. But please, check your e-mail signature. If it's something like this (if you do happen to be using an aural browser, yes, it is supposed to sound like a mess [or skip it]):

Posted by: Tom                            Blog:
            Gilder                http://blog.tom.me.uk

Web accessibility is       |     Standards are brilliant,
great, everyone should     |     please use them, all the
get into it.               |     time.

...then please consider how it would sound in a screen reader, especially if you are sending a message to customers or a public list. Thank you.

Posted at 22:27 GMT | Comments (3) |

Force CSS Reloading

Here's a little tip: if you make major changes to an external CSS file which mean a page becomes unreadable or ugly (for instance, changing a class name - as I just did), in browsers that don't always check for CSS file updates (like Opera) simply append ?1 to the CSS URL, for instance changing "blog.css" to "blog.css?1".

If later you change it again, just increase the number after the question mark. The browser will then be absolutely forced to fetch the new CSS file, and you won't have to bother your users with reloading.

Posted at 17:05 GMT | Comments (3) |

Google gives IE free popup blocking

Google have released Google Toolbar v2 beta, which adds smart popup blocking to IE similar to Mozilla, Netscape 7, Opera 7 and Safari. Also adds some other quite nice features like search country, an auto-filler for forms, resizable search box and a button for adding sites to a blog on Blogger (which Google bought). Not bad for free, really.

Posted at 14:43 GMT | Comments (0) |

Don't Skip Skip

This is something I've been wanting to get off my chest for a while (as are a lot of the posts this week), so please excuse the random ranting.

It's a pretty sensible idea: users come to a page for the content, and not the navigation. Thus the content is more important, and thus the content should be before the navigation in the document, so non-visual and non-CSS users don't have to skip past it. It does make sense, and is especially handy on mobile or text-only devices.

There's just one problem with this: users don't always want to read every bit of content. Sometimes they might only want the first paragraph, or they might have the wrong page altogether. In that case, it's pretty likely they want to go straight to the navigation.

But if there isn't a "skip to navigation" link at the top, the user either has to wait for the entire page to be read out if they're using a screen reader, or manually skip through it all until they find the navigation (as there's no way of defining what is navigation in HTML, which is something I would really like to have).

So please, if you put the navigation after the content, supply a skip link. Thanks.

Posted at 19:09 GMT | Comments (2) |

Mac Excitement

Well done to David Hyatt and the Safari team for their excellent timing with releasing 1.0, the same week I'm getting my first-ever mac! (if anyone cares, it's one of these with more RAM).

I've never owned one before in my life, and I'm really not sure what to expect. The only times I've played with them before were have been in shops, where I've found them half really nice and half aggravating as hell (one-buttoned mice must die).

I'm getting the mac purely because I need to test sites on mac browsers, but then again I might fall in love with it and buy a brand new G5. Or then again at that price, maybe not.

So then, any suggestions as to good resources for Apple newbies? Anything special I should think about (different setups, etc) when testing sites? Oh, also, do IE/mac versions happily install side-by-side?

Posted at 11:51 GMT | Comments (2) |

An Alternate View on Alt

Right. Brave statement time.

I disagree with a lot of people's opinions on what constitutes good alt text.

That is, the view that all non-spacer images should have at least some alt text. I feel that this can actually decrease the accessibility of a page, by adding fairly meaningless and confusing words in the middle of content.

Let me explain: pretend you're a screen reader user (if you're not one already), and trying to read BBC News's front page. What do you care about? Do you care about the headlines, and about getting to hear the rest of the story if you're interested in it, or do you care that sighted users would see a picture of Tony Blair next to the headline?

Personally, I go for the latter option. I might be totally wrong, of course, as I don't use a screen reader for my daily browsing. Personally, what I'd do, is have a very short visual description in the title attribute, and empty alt text. Preferably also having a longdesc, to fully describe the photo.

So when listening to a page, I wouldn't hear "Tony Blair gives a talk. Tony Blair. The British PM has addressed...", I'd hear "Tony Blair gives a talk. The British PM has addressed...". To me, the second reading makes considerably more sense. If for some reason the user wanted to know there's a picture there (maybe to save or send it), then they could ask their screen reader to read titles too.

I feel using less alt text can sometimes make pages more accessible, by cutting down on what's read out. Less is more.

Please, tell me why I'm wrong.

(P.S. Thanks to Taras the English God™)

Posted at 01:45 GMT | Comments (8) |

IE Conclusion-Jumping

Let's just get some things straight shall we? Microsoft have not specifically said that there will be no updates to MSHTML until Longhorn, despite what several other sites have said.

Let's just take a look at the TechNet chat (or "interview" as the not-entirely-accurate News.com put it):

As part of the OS, IE will continue to evolve, but there will be no future standalone installations. IE6 SP1 is the final standalone installation. Legacy OSes have reached their zenith with the addition of IE 6 SP1. Further improvements to IE will require enhancements to the underlying OS.

And that is all we've heard from MS. As far as I can see, in absolutely no way do those comments rule out updates within OS service packs. It's already looking pretty likely that Windows XP SP2 will come with IE6 SP2. This is possibly what the above comments mean - they'll only release IE updates along with OS service packs. "Legacy OSes" could possibly be referring to the Windows 9x range.

To be honest, I really don't know - my comments are as speculative as anyone else's. But personally I'm going to wait for an official announcement (which apparently is going to be at the Microsoft PDC at the end of October), when hopefully we'll get some real facts.

Posted at 21:06 GMT | Comments (6) |

Insane Validating

New-Window Links in a Standards-Compliant World on SitePoint is quite possibly the most pointless article to ever exist. It goes on about applying target="_blank" via script instead of in the document source, just to hide it from validators.

Here's a clue: if you want to use target, use a version of (X)HTML that has it! Setting it via script is pointless. I really don't understand this practice of wanting to use the most modern standard to make pages with, and then hacking around to use removed features.

For instance, this blog validates as HTML 4.01 Strict. Why not XHTML? Because the browser support is awful:

• Internet Explorer has absolutely no support. At all.
• Netscape 6/7 and pre-a-few-weeks-ago Mozilla builds have very limited HTML DOM support, and even now lacks useful things like document.write.
• Opera has had nasty character entity bugs, and has no script support in XHTML mode.

If I have a great need or desire to have it XHTML-compatible in the future, converting it will be a doddle. For now, I'll stick with a fairly well-supported standard.

Posted at 19:02 GMT | Comments (8) |