Candy, A Journal by a James

Why I use HTML (instead of xHTML)

Sean of Elementary Group Standards asked me, as part of a CSS Spring Reboot 2006 ques­tion­naire, why I used HTML 4. Was using HTML instead of xHTML a con­cious choice on my part? Absolutely.

While the other people who were ques­tioned man­aged to keep it nice and con­cise, I man­aged to write up a whole bucket load of words about it. As oth­ers asked me why I made sure Bite Size Standards is HTML 4, I’ve decided to post my answer here too.

As pub­lished on Elementary Group Standards:

“I’ve used xHTML for 5 years, from 2001 til 2006. My ori­ginal reason for using it was that it is sup­posed to be the future. It would have bene­fits like in-line SVG and MathML. It was presen­ted as TheThingToUse™ with CSS.

There are two things about xHTML which make it a poor choice for (pub­lic) sites. Both of them have to do with xHTML’s mime-types. In short, xHTML can be sent with text/html or application/xhtml+xml as the mime-type. On the web xHTML is usu­ally sent as text/html, as Internet Explorer (which has 83+% mar­ket share) doesn’t sup­port the other mime-type. Both mime-types are valid for xHTML 1.0, but (sup­port­ing) browsers do handle them differently.

It’s the hand­ling of the same code dif­fer­ently where xHTML’s prob­lem lies. When xHTML 1.0 is sent as text/html, it is handled as HTML. This means that it has zero user bene­fits over HTML 4.01.

When sent as application/xhtml+xml, you could use MathML — but — the browsers will also apply dra­conian error hand­ling. This way users vis­it­ing the site will be pun­ished (by not being able to see the site) for mis­takes by the cre­ator (which could be the developer, the CMS, the per­son updat­ing the text or indeed the user her/himself just writ­ing some­thing). Simple things like a mis­placed “&” on a page (instead of “&”) will com­pletely shut off a page from its users.

So not only are there no bene­fits over HTML 4.01 because you have to send Internet Explorer text/html — you do get user-punishing error hand­ling from other browsers if you decide to send to them the application/xhtml+xml mimetype.

No bene­fits but increased head­aches? Mwa, count me out.

Some people might say ‘but xHTML is the future!’ This may well be, but is of little con­sequence. The future ver­sions of xHTML (1.1 and 2.0) are not back­wards com­pat­ible with xHTML 1.0, so writ­ing xHTML now gains you little in the future. Furthermore HTML 5 is com­ing. Who says that can’t be the future?

My recom­mend­a­tions for writ­ing HTML? Use the doc­type ‘HTML 4.01 Strict’ and write your code as xHTML com­pat­ible as pos­sible. This means self-closing tags in the body, but not in the head.*

*Little known fact: It’s actu­ally in the spec that you’re not allowed to self-close the meta or link tags. Quite silly in prac­tical terms, and I would sug­gest to the HTML 5 people that they change that1.

I hope this answers all the ques­tions people have, but if you have any more (or dare to ques­tion my argu­ments!) don’t hes­it­ate to use the com­ment form accom­pa­ny­ing this journal entry.

Using tables may cause bodily harm

Go to site. Look at design. Not bad is it? Quite alright. Model’s quite alright too and doesn’t dis­tract from the products too much.

Bodily Harm

Now increase text size. (use ctrl + plus or ctrl + scroll wheel up) Ignoring the fact that most of the text remains at exactly the same size, look what it’s done to the model!

So beware: using tables may cause bod­ily harm.

On the slagging of buzzwords

Since the September that never ended (the point where the unwashed masses — us — got on the inter­net), the web has been rife with buzzwords. New buzzwords came and old buzzwords went, or worse, kept on linger­ing wait­ing to be revived (I’m look­ing at you Web 1.964beta). Amongst all this mad­ness some people, try­ing to put some sub­stance into the buzz, have tried to redefine them.

A recent example of this is Cameron Moll’s recent art­icle on A List Apart. I must note here that rede­fin­ing wasn’t really the point of the art­icle, but some (read: quite a lot of) people (mis)took it as such. In this art­icle Cameron talks about re-alignment versus redesign of web­sites, explain­ing that an incre­mental approach to design­ing an exist­ing site is quite a good thing. You can think of it as evol­u­tion versus revolu­tion; the former might seem slower, but it does bring a lot more refine­ment than the latter.

Good advice right? Well I’d say so, but cer­tain people got hung up on the use of re-align, say­ing it brought a new word with new buzz, thus cre­at­ing con­fu­sion. People, get over it. New ways of using words to express ones ideas bet­ter are being cre­ated all the time. It’s the way lan­guage works. Just say­ing that restyl­ing vs. redesign already means redesign vs. re-align is ridicu­lous. Redesign used to be a broad term, being used for little tweaks as well as full-blown new designs of an exist­ing site. However, as time passed, redesign became syn­onym­ous with the full-blown new design of an exist­ing site. The May 1st Reboot and CSS Reboot events have pretty much cemen­ted this into the col­lect­ive mind of the web (no I’m not going to say blogosphere..yuk!). Ironically, this slag­ging of re-align only increases it’s expos­ure as a buzzword so I really feel they’re shoot­ing them­selves in the foot. Others have dif­fer­ent reas­ons for call­ing it harm­ful.

That same Anne (who I had the pleas­ure of meet­ing at the last Happy Clog meet­ing) men­tioned in the a former post that xHTML has quite a num­ber of down­sides. As these include for­ward and back­wards com­pat­ib­il­ity, they’re quite hefty. The upsides how­ever seem to be zilch at present (except­ing, maybe, search engine optim­isa­tion). HTML, on the other hand, seems to be get­ting a proper spec, writ­ten with the web in mind. I myself have half a mind to change over to HTML 5 once the spec’s fin­ished. Note that this is simply a recon­sidered pos­i­tion and has noth­ing to do with inflam­mat­ory dead horses.

Moving on to the curi­ous post on SimpleBits about using ‘CSS patch’ instead of ‘CSS hack’ to get rid of the neg­at­ive con­nota­tion that’s asso­ci­ated with the term ‘hack’ (even though it has noble begin­nings, one can’t deny that due to server crack­ers being known hack­ers, hack has a neg­at­ive mean­ing now). Thus it’s handy to use another term when you’re explain­ing your hacks to Pointy Haired Bosses. This doesn’t mean that CSS hacks should be endorsed or encour­aged, in my eyes it’s still a last resort.

So do I dis­agree with everything in those twin-posts? Nah, Web 2.0 is just as mean­ing­less as three (or was it four?) years ago. After see­ing the OSCON key­note by Dick Hardt on Identity 2.0 I have some hope that server-side client-focussed (i.e. stuff requires noth­ing extra of the user but does make life easier for them) innov­a­tions like Identity 2.0 seems to be get as much atten­tion as the client-side stuff (like remote JavaScript).

That’s another thing. JavaScript has become cool, nay, accept­able again! After the night­mare that was DHTML, we’ve now got a foot­balling cleans­ing acronym for ‘cool JavaScript stuff’ called AJAX. (Thanks Adaptive Path!) Even though they saw it as ‘a new approach to web applic­a­tions’ it seems that everything con­nec­ted to JavaScript has the tend­ency to over hype bey­ond belief. Compared to DHTML (Dynamic HTML) AJAX does have one sav­ing grace. It provides a method of shov­ing more heavy lift­ing to the server-side where, in my mind, it belongs (cer­tainly if the mobile web ever takes off).

So are there any buzzwords worth slag­ging hard? Absolutely.