Thursday, December 15

Pulling up the ladders.

HTML is one of the greatest computer languages ever created, for one simple reason: it's easy. Imagine if the Web had been created using a standard programming language, even one as easy (by programming standards) as Cobol or Visual Basic. It wouldn't have caught on. The only people with personal web-pages would be programmers and physicists; the only commercial sites would be large rich companies, not small businesses. That anyone with half a brain can learn enough HTML in a couple of hours to throw a slightly dodgy web-page together is the Web's greatest strength. CSS follows in the HTML tradition: it's very, very easy — arguably, it made HTML even easier than it already was.

Not long ago, there was no such thing as a professional web-designer: every web-designer was an amateur. Those amateurs built the Web. Now, we have lots of professionals. A lot of those professionals have moved into web-programming from other computer languages. Those programmers have certain ideas about how computer languages should work: they should be rigid, unforgiving; the absence of a mere comma should make all the difference between a program working and failing. And this type of thinking has, unfortunately, begun to exert its influence on the way the Web is built.

Web-designers often complain about the way some browsers interpret code. Some of these complaints are entirely valid — if I may speak technogibberish for a moment, Internet Explorer's notorious box-model bug is an utter pain, of which Microsoft should be deeply, deeply ashamed. But all too many of the complaints are of a different order entirely: programmers complaining that browsers are too lenient in their interpretation of the code. The classic example of this is the age-old complaint about inverted commas around numbers. Let me explain this clearly, for my non-coding readers.

Internet Explorer's box-model bug (no, you don't need to know what that actually is) is a big problem because it causes Internet Explorer to display web-pages differently to other browsers, making life more difficult for designers. When we web-designers build a page, we usually put in one lot of code that is correct, followed by a second lot of code that is technically incorrect but that will be interpreted correctly by IE, all surrounded by more technically incorrect code that tells the different browsers which bit of code they should be reading. It's an utter pain, and, because it exploits bugs in the browsers, it runs the risk of going completely tits-up at some point in the future when those bugs are repaired. Complaining about a bug like that (and there are plenty of others) makes a lot of sense — not least because it's making it more difficult for unskilled amateurs to create the Web. (I actually use a different method of dealing with it, which involves unnecessary code rather than incorrect code. It's still a pain, and it still makes life more difficult for beginners.)

The inverted-commas complaint is a different thing entirely: it is a complaint about an inconsistency that makes life easier for designers. This snippet of HTML is correct:

size="30"


This bit isn't:

size=30


However, that doesn't matter, because all the browsers on the market forgive the error: use the second piece of code, and they interpret it exactly as if you'd used the first bit. Very nice of them, and entirely sensible. This mistake-forgivingness is one of the things that makes HTML even easier than it would be anyway, and hence one of the things that makes the Web great. And a lot of programmers seem to hate it, and have been complaining about it for years. They want the browsers made stricter. They want HTML to be more like traditional programming languages. They want, in other words, beginners and amateurs to have a harder time. They want small unimportant mistakes to be punished. And, sadly, they're beginning to get their way. Here's an example:

target="_blank"


This is probably the simplest of several ways of making a link open in a new window. It's being discontinued. A piece of code that works exactly as it is supposed to and which has no known bugs is to be removed from the language. There is absolutely no good reason for this. The effect will be that people who did know how to do something will cease to know. It will be easier for professionals than for amateurs to adjust.

<br>


Since HTML began, that's been the code for a line-break. It's being changed to:

<br />


It's a small change, not a big thing to learn. But it's one of many small, pointless changes. Changing the language regularly means that people who don't spend their time reading articles about the latest HTML standards — non-programmers, that is — won't keep up, will find web-design more difficult. The more people unable to design their own sites, the more work for professional programmers — or, perhaps, the fewer sites. With the latest updates, we're already at the stage where putting one or two incorrect words in the code — the sort of thing that, a few years ago, would have just caused the page to display slightly incorrectly — can lead to the page being completely blank. This is not progress.

All of which is why you should join The Campaign To Keep Code Vague. Just as soon as I get around to founding it.

No comments: