CodeBitch says: HTML should not be hard
12 July 2000
A particularly contemptible habit of columnists in the computer trade media is to write a controversial piece designed to attract reaction and then milk another column out of that reaction (“Golly gee, I never expected to read that much profanity in response to my article on how all Linux/Mac/Amiga/OS/2 users are idiots for picking that platform”).
So excuse me for picking up on a particular issue raised in the feedback to my recent columns on Netscape (25 May and 31 May). A few delightful chaps – they are always chaps – argued that I should not complain about the bugginess and non-compliance of Netscape 4.0x because it is the job of professional web developers to get their sites working cross-browser and cross-platform. That if I wasn’t some rank amateur (unlike them, of course), I would be able to deal with these bugs.
I can see why web developers might think this. After all, if web design wasn’t hard, there would be fewer jobs for web designers. (Do you see as many jobs for word processing operators as you used to? Of course not: people in other jobs increasingly do their own typing.) The sentiment is understandable, and totally misguided.
Understand this: HTML is not programming. It is markup. CSS documents are not programs, they are stylesheets. Read anything by Tim Berners-Lee, the bloke that invented it all in the first place. His clear intention was to create something that was easy to do. It is a markup standard for generic documents, and you don’t need to be a geek to type a letter. It was never meant to be a specialist skill.
Indeed, the W3C’s canonical web browser/editor, Amaya, is WYSWIWYG, not code-based. So much for having to type the code to do“real” HTML. That the elitist attitude persists is a bad thing, and a reflection on the poor state of WYSWIWYG tools. (For the record, CodeBitch uses the Alpha text editor in preference to WYSWIWYG tools. She does not consider this a virtue.)
“I never intended HTML source code (the stuff with the angle brackets) to be seen by users. A browser/editor would let a user simply view or edit the language of a page of hypertext, as if he were using a word processor. The idea of asking people to write the angle brackets by hand was to me, and I assumed to many, as unacceptable as asking one to prepare a Microsoft Word document by writing out its binary coded format.”
Unlike many so-called web developers, I have had a lot to do with intranet development, where everyone is a web content producer. No organization can afford a team of specialists just to create the content for the intranet. That’s everyone’s job, and by and large, everyone can do it. Being able to do HTML doesn’t mean you are clever. That some think it does just indicates their limited talents elsewhere.
By now, some readers will be firing off indignant emails saying, "Oh, yeah? Can a newbie build a whole e-commerce site?" These people need to brush up their reading comprehension skills. I am not suggesting that genuine programming in a Web-based or any other environment is anything but a professional skill best left to specialists. So don’t start bringing up JavaScript, Java, PHP, Perl or whatever else. I’m talking HTML and CSS – nothing more.
So if HTML should be easy, why isn’t it? The problem is that browser manufacturers have never stuck to the standards, and thus their products generate unpredictable results. A common response to this is to test early, test often – do whatever it takes to get it working in all browsers. We tried to do this for the launch of MacEdition, while maintaining our compliance to the HTML 4 standard. We thought it was reasonable to assume that if it worked in one point release of Netscape 4.0x, it would work in the others. Were we ever wrong.
Should web designers have to put up with the kind of bugs we encountered, where certain CSS directives cause the browser to crash, but only if the relevant HTML tag contains certain other specific HTML tags? Or where in some circumstances, Navigator loses formatting after an ACRONYM tag? That’s just incompetence on the part of Netscape, long before the air really got sucked out of them. (If you are using Navigator 4.0x and you find the fonts go stupid halfway through a paragraph on this site, hit Refresh or Shift-Refresh. Trust me, it seems to work.) Now I feel like I have to check every page in every version of Navigator before putting it live, just to make sure I haven’t encountered yet another bizarre combination-of-tags crash. This isn’t how it’s supposed to be. Why can’t designers just run things through a validator? Valid, correct code shouldn’t cause crashes. I can understand having to check out different interpretations of the same code by different browsers, especially some of the wackier CSS positioning directives, but a border on a DIV shouldn’t cause a crash. ’Nuff said.
There comes a point at which testing isn’t reasonable. I have seven different browsers on my production Mac, but two of them are for personal use – the rest are just for testing. I (currently) have Netscape 4.04, 4.08, 4.6 and 6 (PR1), plus IE 4.5, IE 5 and iCab. That’s just the production box: there are Version 3 browsers tucked away on other systems to test with. I can also test using the main PC browsers. But I don’t know if that’s enough. There are hundreds of different User-Agent headers recorded in the MacEdition logs. The same goes for the other sites I am responsible for.
And it’s not just 76 language varieties of Netscape. We get a reasonable number of hits from CyberDog, and some from Stark Solutions Browser Mark IV (Macintosh, PPC, OS X). As best as I can tell, Stark Solutions is a fictional company from a comic book. Or perhaps a real one in Northern Colorado. Either way, someone’s messing with their browser tag. How am I supposed to accommodate users who don’t even tell the truth about what browser they’re using?
I think designers should produce correct code; others think designers should somehow know how to get around obscure bugs. The end result of the browser manufacturers’ errors is an ugly compromise and the notion that HTML should be hard. This might appeal to the intellectual vanity of those who want continual congratulations for completing tasks that shouldn’t be difficult. But if we have to waste so much time working around complicated combinations of tags that break brain-dead, crash-prone browsers, I don’t see how we’re meant to get a forward-thinking web-based new economy.