JeroenMulder.com, Skip Navigation


Current Location: / Weblog

Recent Entries

XHTML vs. HTML: And the discussion continues

Monday / 28 February 05

With the recent announcement in the SitePoint Tech Times the discussion about XHTML and HTML has started again.

The argument itself is fairly complex if you’re not familiar with it. If you like to read: the case to avoid XHTML and the case for XHTML.

I have read a good part of many articles and I feel the cases to avoid XHTML are missing something — something crucial. Some many moons ago I remember reading an article (I cannot seem to be lucky with Google) where the article categorised the advantages of using XHTML in two.

On one side we have the large technical advantages of XHTML, such as extensibility, the fact that it is well-formed XML and all the advantages those two produce. It must be clear that in order to use these advantages, authors must serve their documents as application/xhtml+xml, which, inevitebly, is not understood by our ‘favorite’ browser a.k.a. MSIE. Content negotiation might be a solution here, but I am not intending to cover that tonight.

On the other side we have the advantages of XHTML as a brand. XHTML has made many companies aware of web standards, as XHTML was slowly becoming the buzz-word in their environment. Not only in their environment, but in ours as well. It’s not uncommon for inexperienced authors to want to jump on the currently going bandwagon — today XHTML is still a large wagon going strong. Besides it being a trend in our world, XHTML is stricter and forces us to write well-formed markup. It forced us to look at a seperation of presentation and structure. It forced us to look at semantic markup. Ok, XHTML wasn’t completely responsible for this, but it surely added to it and is still actively adding to it.

Most cases to avoid XHTML are based on tackling its technological advantages and the (really significant) disadvantages — for example XML’s draconian error handling — the current technology comes with. However, I cannot imagine for all of this to be steadily improved over the next decade, I do have to agree with many designers when they say you should avoid XHTML for those technical advantages.

What I am missing in any case to avoid XHTML is a solid reason that tells me why I should not serve XHTML as text/html at this very moment. Whereas the technical side has been largely tackled, the marketing side is still standing strong. Personally, I consider this a very important side. For the past four years we have been in a state of transition: going from table-based layouts written with bad markup to layer-defined (structure, presentation, behaviour) with semantic markup. XHTML is helping in this process and I cannot see why it would be doing any harm at all. Then, when our ‘favorite’ browser has caught up with technology, we can look into a second transition: the one from HTML to XML documents.

You and me know how to write good markup in HTML4. However, the inexperienced authors often do not. If there’s nobody calling for them to move forward or to correct their mistakes, we might as well switch our calendars back to the year 1999. Please, don’t write off XHTML for not making it the cut completely. It still plays an important part in advocating web standards. Educate the people, instead of writing off technological advancements.

Comments

1Daniel posted:

01 March 05, 06:16:06 AM

Here's a solid reason.

If you already know HTML, then XHTML is the next logical step. I'll ease your job considerably.

2Faruk Ates posted:

01 March 05, 19:01:37 PM

Very well said, especially the last paragraph is seriously strong and for the keeping :)

By the way, your CSS could use some improvement:

input, textarea, select {
color: #000;
}

currently, I'm writing (and reading) this comment as light grey text on a white background. It's not the best ;)

Just fyi / supportive tip =)

3Faruk Ates posted:

01 March 05, 19:02:09 PM

That improvement is an addition, by the way. :)

(sorry for the double post -- feel free to delete this one, of course)

4Jeroen Mulder posted:

02 March 05, 03:37:40 AM

Faruk - Thanks for props, especially from you.

I'll force background color and text color on certain elements -- you're the second one reporting it as well. It's always been a bit of a dilemma for me though, afterall, you must have light grey set as a default color for your text for a reason, right?

I suppose both influence eachother, so forcing just one of the two isn't a smart option indeed.

5Faruk Ates posted:

02 March 05, 06:05:55 AM

Indeed. CSS has one of its guidelines saying that you should always specify a background AND text color together, or neither of the two. Since you use a background image and a background color, it's only right to also specify the text color :)

My OS is set up to have light text color, and default black backgrounds. Easier on the eyes for when I'm coding :)

6Jeroen Mulder posted:

02 March 05, 07:39:30 AM

Are you serious? I must have missed that guideline then, but it definitely does make a lot of sense. Thanks for the headsup, much appreciated. :)

7Faruk Ates posted:

03 March 05, 05:47:45 AM

Hrm, it seems they removed that from the CSS Validation page; that, or they only show it when the document is invalid, perhaps...

Either way, previously, you'd A) get warnings when specifying background colors in one CSS rule and no color: property was present, and B) a "Tip of the day"-like thing was somewhere... maybe that wasn't actually on the W3C's own page though. I'm getting a bit uncertain now...

also, your CSS isn't updated yet ;p *whine whine*

8Jeroen Mulder posted:

03 March 05, 06:16:09 AM

Farul - It makes a lot of sense. For the past few months I have been working with someone who has set the default background in Windows XP to a light grey. Websites too often rely on default settings when they want to show something white -- I suppose I should do the same test with my own websites as well.

It isn't? Oi, I see. I forgot to upload the right file, even though I did update the CHANGELOG in screen.css. Sorry about that :)

Ugh, the stylesheet is such a mess. I might as well redo everything soon.

9Ron posted:

04 March 05, 02:55:22 AM

Hey! I think we have worked with the same person!

10Faruk Ates posted:

04 March 05, 05:37:29 AM

Jeroen - I have inverted my WinXP colors so that I'll always spot it if I forget it anywhere, and also, I always spot it if someone _else_ forgets it :D

Very handy to work this way. Especially since black backgrounds with light grey text colors are easier on the eyes when you have to write code for hours :)

Ron - who are you talking to, and about?

11Ron posted:

08 March 05, 10:39:42 AM

Faruk - Ha! Sorry Faruk, i was talking to Jeroen! We're in the same group, so i know the person with his default background in Windows XP set to a light grey LOL.

12Mathias Bynens posted:

29 March 05, 12:05:34 PM

<blockquote>Most cases to avoid XHTML are based on tackling its technological advantages and the (really significant) disadvantages --- for example XML's draconian error handling --- the current technology comes with.</blockquote>

I think XML error handling is not exclusively draconian; it just cuts both ways. As <a href="http://kurafire.net/">Faruk</a> <a href="http://kurafire.net/articles/case-for-xhtml">says</a>:

<blockquote cite="http://kurafire.net/articles/case-for-xhtml"><p><a href="http://annevankesteren.nl/archives/2004/02/xhtml-versus-html">HTML is not strict</a>, and thus unreliable material to be used as an example. The more we spread HTML out there, the more people who are -just- getting into this world will think HTML is fine. They'll discover that certain tags, like <code>&lt;/li&gt;</code>, can be omitted. They'll stop using those tags and proceed to give an even worse example to the people that look at <em>their</em> source.</p>

<p>Now imagine doing that with XHTML. Your pages won't validate if you omit such tags; people looking at your source will copy it, and if they ever accidentally forgot a closing <code>li</code> tag, their page won't validate. They'll correct the problem and other people looking at <em>their</em> source will still have a good example in front of them to learn from. All in all, the Web is slowly becoming a stricter place, and <em>that</em> is what we ultimately need to achieve, if we wish to have Web Standards become truly successful.</p></blockquote>

Personally, I see it as a feature. Yay!

13Jeroen Mulder posted:

29 March 05, 14:31:25 PM

Mathias - Haha, sorry. I should really implement HTML support some day. The joys of doing your custom software..

You make an interesting point and I couldn't agree more with you. I was actually refering to the draconian handling as implemented in a browser such as Firefox today. Nothing wrong with the specs, just the way a browser is supposed to deal with errors is what bothers me.

14Faruk Ates posted:

30 March 05, 05:18:11 AM

Jeroen, if it's your own system, you could look into hooking up HTML Tidy for comment validation, so that people can use HTML :)

15Jeroen Mulder posted:

30 March 05, 05:23:26 AM

Faruk - Yeah, I could. I decided I'll switch to WordPress, as I have finished moving my custom code to a different project already. I just want this to work -- the tinkering is left somewhere else :)

16Ron posted:

30 March 05, 08:23:15 AM

Delegate, Delegate & Delegate... How many times do i have to say that word?!?! LOL

17TSF posted:

06 August 05, 21:01:46 PM

It appears that xhtml is one of the worst inventions in our scripting world in the last decade. It is redundant, repetitious, abusing unnecessary memory and loading time in order to compensate with poor technology in smaller devices such as mobile phone, MP3 players etc.

If anything gets stricter; people will leave using it. What’s the difference between 1+1=2, or “1+1” =”2”?

HTML is fine and it is artistic enough to feel free whatever you wAnt tO wRiTe.

I don't feel that xtml will survive long enough in the real world :)

Post Your Comment






Comment Guidelines:
Please keep your comments relevant. Abusive, inappropriate and anonymous may be edited or removed, if deemed necessary.

Privacy Note:
Your e-mail address will never be displayed in public or forwarded to third-party organisations and is only stored for security reasons.


Recent Entries

Blogging Friends