By madskristensen
via madskristensen.dk
Published: Feb 19 2007 / 10:07
Over the years I’ve heard a lot of strange selling points about XHTML, mainly from smaller web design companies. They tell you why they use XHTML and why it is a future proofing feature of their work. Some of these selling points make sense in theory, but is out of touch with the real world.
-
Fluent Assertions with FEST (bye bye Hamcrest!)
-
FlashDevelop and ActionScript 3 - how to embed image - fast tip
-
[Linux] Convert videos for your smart phones
-
How POW saved my Ruby on Rails Education
-
Limit your abstractions: Application Events – what about change?
-
Call for Action - Open web needs you now
Comments
rasman replied ago:
If you're going to title an article like that, then I expect to see a thesis, like a sentence starting with "The true selling point is...". That was just a bunch of open-ended questions.
Not just, "I use it because it look prettier" (sic).
madskristensen replied ago:
I agree that the title is misleading, but I ran out of ideas for a better one. The open ended question in the end is the point.
kenman complained ago:
kenman reported this link as lame on 02/19/2007 @ 04:01:30
So I'll be a dissenter.
"Separation of content and style"
This is a design concept, yes you can do this in XHTML or HTML 4, however it is the more forward-thinking lot that is more likely to abide by this strategy. XHTML does encourage through various methods, however, no DOCTYPE in the word can design pages for you. If you're hell-bent on making bad pages, you're going to make bad pages.
"XHTML is XML"
It says, "but try to run the validator on an entire website and see how many errors it finds". Now tell me, whose fault is that? Ever heard of GIGO (Garbage In, Garbage Out)? It still applies. Once again, simply applying a certain DOCTYPE to your page isn't going to modify the intrinsic structure of your markup. Then: "we instead could have used XPath according to the selling point. But of course, we can’t". You might as well say, "I can't follow directions and complain about the results of not doing so".
"Mobile platforms"
Once again, the DOCTYPE isn't the magic wand for markup. "The problem is that in the year of 2007, mobile devices are still terrible at CSS and JavaScript." Yes? That's to be expected. That's why there's seperation of content and style; you have to abstract what is important. The mobile platform really just cares about the content, and by utilizing smart CSS media declarations, you can easily hide non-mobile-friendly elements. "The autopostback feature of many ASP.NET controls works only in Pocket IE because it uses JavaScript." Whose fault is it to require Javascript for basic page functionality? I'll give you a hint: it's not the w3c or DOCTYPE. You should NEVER rely on Javascript for core functionality of your site, unless you actually don't care about those without Javascript. It's that simple. Javascript should be used to enhance your pages, and just like CSS, if you care about making your content accessible to a broad range of browsers, you provide progressive enhancement that lets you gracefully fallback if that enhancement isn't available.
"The newest standard"
"XHTML is the newest HTML based standard so it will be easier and cheaper to upgrade to the next standard when it arrives." You sound like this is a piece of technology you actually had to buy (perhaps using MS products you did actually have to buy it?). Either way, most designers/developers I know are generally happy about the direction things are moving, and eagerly anticipate future revisions and releases. You sound like someone's forcing you to upgrade; by all means, if you don't want to, don't. You then say "I’ll bet that the website changes before a new standard arrives and even though it arrives before, which browsers will then be ready to fully support it and will it be backward compatible?", and then also "but it doesn’t carry much weight in practice and thereby isn’t future proofing", making it sound like its trivial and not worth implementing, but in your "selling point", you say:
"The real selling point"
"The reason I use it is because it has better cross-browser support in the DOM and it look prettier". Oh, I thought XHTML had no "future proofing", and there was no reason to 'upgrade'? I could be wrong, but wouldn't better cross-browser support qualify as "future proofing"? It sounds like you're contradicting yourself to me.
madskristensen replied ago:
Kenman, you are right in what you write, but I think you misunderstand what my post is about. It is about the falls claims of XHTML as being future proof presented by varios smaller web design companies. Personally, as I also write, I am a strong believer of XHTML and standard compliance. To answer some of your counter points, here goes.
Separation of content and style
As you point out, it is a design concept that has nothing specifical to do with XHTML and is therefore not valid to claim that XHTML is future proof using this claim.
XHTML is XML
You answer: "I can't follow directions and complain about the results of not doing so". I can write XHTML to the letter and do so, but I would never trust a website that claims to be XHTML compliant because I've tried to run the validator on multiple websites that makes that claim and they fail. XML is only XML if it is 100% correct. 1 error is enough to render XPath useless, which is why I always use regular expression to do screen scraping.
Mobile platforms
I'm not sure if you agree or disagree with me here, but you don't say much about the future proofing feature of XHTML on mobile devices. Seperating content and style is not XHTML specific, and has IMO nothing to do with XHTML being future proof on mobile platforms. The point here is also that you webpage is probably filled with CSS and JavaScript, so much that it takes conciderably amount of time (money) to change it to work on mobile platforms. That is not a valid future proofing claim too me.
The newest standard
"You sound like this is a piece of technology you actually had to buy (perhaps using MS products you did actually have to buy it?). Either way, most designers/developers I know are generally happy about the direction things are moving, and eagerly anticipate future revisions and releases. You sound like someone's forcing you to upgrade; by all means, if you don't want to, don't". Again, these are not my claims, that's part of the point of my post. I also agree with you here, but that is also not the point. Being newest is hardly future proofing when revisions are years apart and doesn't change much because of backward compabability issues with older browsers.
The real selling point
HTML 4.01 strict has the same cross-browser support in the DOM as XHTML 1.0 strict, but isn't as pretty. Doesn't sound like a selling point to me, which is the final point of the post. Again, I'm not contradicting myself, but the fooly claims that I wrote about.
Kenman, I think we are on the same page, but I also think you didn't read the first part of the article. The point is also about that all these claims are good in theory, but not in the real world. Thanks for your feedback.
kenman replied ago:
Yes madskristensen, I do think we agree on a lotand I did in fact read the first of the article. I know what you mean by theory vs practice, however I have counter-points on the following:
In "XHTML is XML", I do realize that 90% of sites that I visit that have the w3c logo do _not_ pass validation. Taking the subject very literally though, consider the power of RSS, another XML implementation. Look how far RSS has come in the last 2 years, it's stunning! I think there will be a time when having well-formed XHTML docs will be just as beneficial as having well-formed RSS feeds — if we all had well-formed XHTML, would we even need RSS? — but currently XHTML hasn't reached that point of maturity.
As far as "Mobile platforms" go, I believe (and I could be wrong) that XHTML rendering engines are supposed to be leaner and more efficient than full-on HTML engines. Since they have less runtime error-correction (think missing tags, etc.) and the document is much more stringently defined, they have a smaller memory footprint and a smaller code base. Given the limited resources in mobiles, such a thing can only be good. Of course, that's assuming that my belief in the slimness of XHTML engines is correct.
I think above all else though, XHTML is as much of a principle as it is a DTD. Those who embrace XHTML are already future-proofing their work, not necessarily by using a certain DTD, but by following the ideologies that go with it. Just like OOP is as much a mind set as it is a practice, so too is XHTML.
Either way, I enjoyed your article and this discussion, cheers!
rbygrave replied ago:
You have not mentioned document.write, and innerHTML support... as I understand it these don't work "out of the box" in XHTML (compared with HTML4 Strict).
Two pretty issues for that can hurt AJAX development with XHTML - or am I wrong?
Voters For This Link (14)
Voters Against This Link (0)