Please note that you may have been redirected (you might like to make a note of the URL in the address bar of your browser and update accordingly) This is a permanent archvie but is no longer actively maintained. Please visit http://joshuaink.com for the latest updates.

Thoughts about XHTML and other stuff

Wednesday November 24, 2004

No matter how much you read about it or how much you discuss it you will, eventually, have to make your own mind up about XHTML and validation and how you approach it. That's not to say it has to be a permanent decision but if you don't take a stand, albeit temporary or indeed wrong and a little fuzzy, how can you possibly make a plan for improvement?

XHTML versus HTML

It's not even a debatable issue as far as I am concerned. It has to be XHTML if only for the idea of what I am trying to do, the place I am trying to reach for. The simple fact remains that, tag soup though it may well be, it works (most of the time) on the browsers I aim at and I don't see that changing any time soon. Seeing XHTML at the top of my pages simply reminds me of the very reason I gave up WYSIWYG to join the good fight, nothing more.

Strict versus Transitional

I am in danger of contradicting myself here, no, I am going to contradict myself here but it doesn't matter. For me marking up with XHTML Transitional misses the point completely and I can't help feeling that people use it just to make getting that lovely blue strip when validating that tiny bit easier. I am guessing of course but I used to do it myself, it felt good, it looked good. Right now, I would rather have a page in strict that doesn't validate because, for example, I used <strike>. This way I can start to look at what I am getting wrong, what tags I shouldn't be using and correct my mistakes where possible and hopefully when I finally make the move to XHTML 1.1 I will be a little better prepared.

The peppery fire of tag soup

I have had a number of, occasionally heated, discussions about tag soup i.e. serving up XHTML as text/html and I am aiming to get this site in order as soon as I can (still with you on that one Hayo) and that is fine. This is my personal site, it's here for me to play with and if a page, or the whole site, falls over because I have some malformed code hiding in a corner, it doesn't matter, nobody gets hurt and I learn something in the process.

I simply can't afford to take this attitude towards my clients websites and to make matters more difficult, 80% of my small business clients want some form of control, they want to update themselves, they want their site to continue to work afterwards. I for one have bills to pay and kids to feed, I am not going to tell them no.

It begs the question once again, why even bother with XHTML if it's just tag soup and is ultimately going to be destroyed by someone who doesn't know or care very much about the code?

I have two thoughts on this; firstly part of it is for me, for my job satisfaction, so I can finish the job and say to myself, I gave it 100%. Secondly, it's about how you approach content management. It's about assessing your clients level of interest and abilities and then choosing the right CMS for them (not you). You can't simply steer away from standards just because you don't think the client can handle it. It's my job to make standards work for them as best I can and to try and get them interested in the idea at least, then maybe one day... who knows?

When, or should that be If, I find a client who wants the correct mime type, who does care about everything but Internet Explorer (instead of the other way around), who wants me to make every single update on the site, then I will do the job how, as we all know, it should be done. Meanwhile, I can't preach from on high at my clients, it just don't work.

Internet Explorer

It's a problem but it ain't going away any time soon. As I afford myself the luxury of charging for my services I have to take it into account, I have no choice, period.

The almighty validator

The only real question I have left for myself is does the almighty validator have any place left in my compromising tool set? Yes it does, it's incredibly valuable when things aren't working as they should. On many occasions an apparent bug in Internet Explorer has turned out to be a <div> I forgot to close and the validator is good for that but I just can't obsess about it these days, I can't lose sleep over it. I know for a fact that at the time of writing, a link on the front page of this site is causing it to be invalid but I don't care, it still works (hopefully). I know that before I publish this post I will whiz it through the validator but what happens if a comment causes it to become invalid? Nothing that's what, nobody dies as a result.

  1. Angad

    1366 days ago

    About validation, I think it’s absolutely unecessary as long as the page looks ok on all platforms.

  2. Kev

    1366 days ago

    I too go for XHTML 1.0 Strict. I see it as the ‘right thing to do’ for numerous reasons.

    First, its good for the site itself. Valid code is (compared to non valid code) leaner and provides a good, stable starting point.

    Secondly, its good for me. My aim is to get better and better with markup so that I can produce underlying code that works now and for a long time into the future.

    Thirdly, its good for the web overall. More valid sites equals a more reliable WWW. As you know, I’ve written an article about accreditation for web designers that touches on my beliefs in this area. I really do think that we as web designers have a responsibility to not only our clients but to ourselves and to the medium in which we work.

    As for the whole serving XHTML as text as oppose to XML, this is something that I’m trying at the moment to learn all I can about. There’s a great article on content negotiation with PHP over on autisticcuckoo.net that might help a few people out in this respect.

  3. Nathan Pitman

    1366 days ago

    2 identical sites, 1 validates as XHTML, one does not. I guess it’s like the difference between a good car and a great car. :?

  4. Jon Hicks

    1366 days ago

    I’m with you here John, but I disagree with Angad’s comment. Validation is important, just ‘looking OK’ isn’t enough. I’m no validation nazi, but its important to check that your code’s not shite.

    This is a great tool to keep an eye on your pages, XHTML validation by RSS!:
    http://www.benhammersley.com/tools/xhtml_validator_to_rss.html

  5. John Oxton

    1366 days ago

    Just to add that I fixed the link and learnt something new. I had always assumed that because it was an external link I must leave it as I found it in the address bar, not so. The invalid &’s have been changed coded as they should (comments strip HTML so I'll have to leave you to figure it out what I mean) and all is well. Yeah, I kind of like the idea of that.

  6. Patrick

    1366 days ago

    Regarding XHTML Transitional, it’s a ‘Passage from one form, state, style, or place to another.’
    The way I see it, it’s a bit of a “getting used to the real thing” language for those used to (non-X)HTML, which is great, short term, but, I agree, sticking with it forevermore is slightly missing the point.

    No-one can sensibly expect everyone to know standards inside-out, and I think you’re doing the right thing – XHTML isn’t just there to be used only when you know it like the back of your hand and in the mean time use tag soup. There’s a learning curve to everything.

    Validation’s very useful when figuring out what’s what – the standards are there for a good reason and it’s often the quickest way to sort out problems. And I’ve not really come across any limitations in XHTML Strict compared to HTML 4/XHTML Transitional – you can , for example, (and should, semantically speaking) use del instead of strike.

    Oh, but after all of the effort, wave goodbye to validity if you’re handing something over to a client who expects to add / manipulate things…

  7. Gordon Mackay

    1366 days ago

    My only reservation about XHTML is that it is an unfinished specification, while HTML 4.01 is complete? Maybe that’s incorrect and i’m just speaking turd :)

    One of the neatest things I read here in the comments was from Kev…

    “Secondly, its good for me. My aim is to get better and better with markup… ”

    Writing pages in Strict certainly boosts your knowledge into the upper realms, and seeing that blue strip makes it worth it to an extent.

    Great post John!

  8. Tim

    1366 days ago

    “My only reservation about XHTML is that it is an unfinished specification, while HTML 4.01 is complete? Maybe that’s incorrect and i’m just speaking turd :)”

    Yep, that’s incorrect.

    XHTML 1.0 Transitional is a complete and published spec.

    XHTML 1.0 Strict is a complete and published spec.

    XHTML 1.1 is a complete and published spec.

    XHTML 2.0 is still in the works, AFAIK.

  9. Tim

    1366 days ago

    Angad wrote “About validation, I think it’s absolutely unecessary as long as the page looks ok on all platforms.”

    I hope to God that Angad is trolling, but I suspect that views like his/hers are not as uncommon as standardistas would like.

    The only way to have a web site look the same as you see it is to invite all your users round to your desk. It might get a bit crowded, though.

    Either that or upload a great big image map :)

  10. Angad

    1366 days ago

    Alright, alright!

    Maybe I was too quick to comment, when John posted this.
    After reading the post on Kevin’s site and the comments here, I agree with all of you.

    And oh just so you know, my blog does not validate because I just moved to textpattern, and over that I’m in the process of redesigning it really slowly, as I’m short on time. :)

  11. Jared Christensen

    1365 days ago

    I’d like to point out that valid code is not necessarily good code. there is plenty of bad stuff you can do with valid code that completely misses the point of semantic markup. So validation is not and should never be the only goal of a web designer.

    I’ve always seen XHTML Transitional as just that—transitional. There’s no shame in using it if it fits your needs. Ultimately, it is best to go strict where possible, but it is possible to create perfectly valid, semantically sound pages with Transitional markup.

  12. Jina

    1365 days ago

    I use XHTML 1.1 with the correct mime-type, only because it forces me to code correctly – if I don’t, the page gives me one big fat XML error. I guess I can be a glutton for punishment at times.

    When I code for clients, however, sometimes I find that I have to code Transitional or Strict – or even just plain old HTML. Why? Everytime I hand over the source files, and their IT guy starts hacking away at the code, he’s always going to be throwing in tables and nobr tags and font tags… It’s out of my control. sigh

  13. Houser

    1365 days ago

    Nice write-up, man. I took a look at my site which I coded as Transitional and moved it up to Strict. Luckily, I was not that far off the mark. Remove a few border attribs from imgs, change my targets to rels and whamo.

    Next up, I suppose, is getting my photo blog up to snuff. Should be phun.

  14. Ryan Mack

    1365 days ago

    My opinion: Any DOCTYPE will do, but with very few exceptions, it has to validate. Garbage in, garbage out.

  15. the dullneon

    1365 days ago

    i personally think that it’s ok to choose any doctype (HTML 4.01 to xHTML 1.1) as long as the code validates. Each spec has it’s own set of features that a certain project may need (like iframes validate in xHTML 1.0 Transitional and not in Strict) and i like using ‘The Appropriate Spec’ for a project, as long as it validates (and i see validation as a way of ‘future-proof’ing the site).

    i’d reckon it’s like writing a program in C or Java – with any specific compiler, use the features that the compiler lets you use and make sure it compiles with no problems. A somewhat loose metaphor and i hope i’m making sense…

Christmas gifts?

Beginning CSS Web Development book cover

Recently

The last seven posts made on this site.

Geeky shiteMeta

A proud member