At some point as a front-end developer I think we all have to draw a line for HTML validation. Strict validation is not a holy grail you need or can crusade for. It improves your code but has also it’s downside. For example target:_blank is no longer available, you need a javascript snippet to get around it. And when you get there, what’s the point? Your template no longer really validate. The target attribute doesn’t validate because you can’t choose for the user to open a link in another window, but you decided for him anyway!

That’s why I only validate my template with a strict validation and not the entire website. This way I am sure my template is rock solid before it goes in the CMS or framework. When the production goes CMS, the validation change from strict to transitional because I don’t know who’s working on it next. The client could put his text content inside, and the back-end developer could do minor modifications.

And from there you can’t be sure what is happenning, the client doesn’t know about your javascript trick for links or that you need to close all tags with a “/”. He certainly doesn’t care, and you can’t hammer him with this kind of little bugs. As for the back-end developers, even if they should, some of them are careless, and don’t have strong feeling about beautiful XHTML code.

What is alot more important than validation, is for your HTML and css to be well written. In a perfect world where everyone is perfect, strict validation would be perfect, but unfortunatly, there is alot of lazy ass, me first… I think relying only on strict validation doesn’t improve your code, using a good semantic for your html and css however does, anyway there will always be someone to mess up your strict validation.

28 thoughts on “XHTML Strict validation is a tool, not a way of life

  1. I always code my websites to transitional ant then I change the document type to stict, if it’s valide, then cool, if it’s not – let’s get back to transitional :).

  2. Personally, I have to disagree. I think following standards is important for the web as a whole. The differences between xhtml transitional and xhtml strict are fairly small though. From memory, the only difference has to do with tables and a couple of small things. Correct me if I’m wrong.

    The target attribute is really not that great, as opening links in a new window is generally considered bad in terms of usability. Let the user decide if the link should open in a new window with a simple right click.

  3. Standart are important, but the web is a mess, most site would never validate in xhtml strict because alot of persons who don’t know anything about web standard edit website.

    As for the target attribut, I desagree, most average internet user never right click, they assume it gonna open in another window if it has too. You could say it depend of the website target audience..

  4. I agree with Anthony Short: if you want a better web, you should care about validation and web standards.

    Talking about links: the best solution is to have a JavaScript checkbox to open pages in a new window, using no target by default. Users with screen readers will hate you if you change the active window.

  5. I’ve never really got into that “strict” thing. I tend to write xhtml transtional code, and validate pages against it. IIRC modern browsers can open target=”_blank” in a new tab, which is great.

    That said let’s do not forget that without a proper MIME type in HTTP headers browsers parse XHTML documents like a “tag soup” and not as a XML document. For example, in such conditions a browser will never halt after an unescaped ampersand in a document. Things might change with HTML 5 which hopefully will introduce predictable error recovery.


    A.
    http://passiomatic.com/

  6. I think using rel=”external” on links then using unobtrusive javascript to open links with rel=”external” isn’t a bad way to go, if you must have pop-up windows. At least that way you can also target the attributes of the window you want. Putting rel=”external” also isn’t a great overhead on the author’s brain.

    If JS is disabled then they just open in the same window, no major issue really.

    So I’d avoid target=”_blank” at all costs if you’re using Strict.

    Validation is a funny thing, it’s something we should be aiming for IMO but it’s not the end of the line if we don’t make it for some minor reason. Personally I try to validate, but at the end of the day the product goes to a client and they own it. Which is your point. We can’t force this practice. But the argument about the lowest common denominator is always a dangerous one. I read somewhere that a study about 3 years ago showed only 1% of websites use a DOCTYPE. No we shouldn’t ditch doctypes because most people don’t use them or can’t be bothered. While this has improved greatly, we now have the opposite issue – more DOCTYPES but many of those are just put in by the CMS / blogging tool.

    Anyway, opening a new window is a behaviour so JS is really the right way to do that task.

    But I see your point, and it’s often discussed Cedric. I think very carefully about Strict vs Transitional when it goes to the user, too. If I have no input / control I revert to a Transitional as well (although I would still use the rel=”external” just because it’s better).

  7. I understand using rel=”external” is a good alternative. What I’m saying, is using it, is a bit going against your own standard. It’s not there for a reason.

    But I must admit I didn’t think about acessibility for screeen reader.

    Now, I don’t say strict is bad, I like strict. I just feel it is not apropriate for alot of these cms and framework site out there.

  8. I disagree. Creating valid XHTML strict is totally easy.
    The target atribute is the only thing that I think is crap. Why not give a chance for web designers to open new windows without using JS?

  9. There is a difference between rel=”external” and target=”_blank”. rel=”external” indicates that the relationship between the current document and the destination one is that the referenced document is not part of the same site as the current document. [1] It suggests nothing about *how* (whether to open it on a new window or not) the UA should proceed with such resource. On the other hand, target=”_blank” suggests that the resource should upon on a new window, regardless of it being an internal or external document.

    I personally assign class=”open_resource_on_new_window” to link elements that I want to upon up on a new window. JavaScript finds these elements and assigns an onclick event. If there is no JavaScript, it will just open the resource on the current window.

    [1] http://www.w3.org/html/wg/html5/#link-type-external

    http://www.csarven.ca

  10. I totally agree with your statements here.

    To the naysayers out there who think that Standards Must Be Adhered To Above All Else Praise God;

    If you’ve ever worked on a real production website, you’ll understand that while we can aspire for greatness, the reality is that there are people with varying degrees of skill who will work on a site, and I’ve yet to meet the CMS which can actually put out 100% valid code 100% of the time.

    Aspirations are great, but reality is a much different beast.

    http://www.radicalhive.com

  11. I agree and dont agree. It is always good practise to ensure that you develop your code as close as you can and if so even valid. But you are right we never really have control over the next person editing our hard work.

    http://www.toastedpixel.org

  12. I always validate my site with transitional validation, i think its far better then sticky in terms of coding. i think most important thing is to saw your site perfectly in all browsers and OS. many time i validate my site but did not support all the browsers. 😀

    thx,
    chetan
    http://www.hiddenpixels.com

  13. IMO, Strict is a good practice, forces us to write semantic code. But it’s an all or nothing type of deal. There’s no point of using Strict if you can’t guarantee the entire site validates. I recently wrote on an article on this topic as well, covering no target and embedding issues.

    http://www.8164.org/xhtml-strict/

  14. IMO, It would be way stupid to code new pages in Loose, &/or Transitional… It was Created almost 10 years ago. And allows for Best Separation of Content, Style, and Function…

    There’s going to be a line… to draw. Where you either know html, or you know xml Mash….
    Good Luck in Coding

    P.s. *my site uses all new technologies IN STRICt…
    check it out http://graphicalinsight.com

  15. personally, for sites i control, I believe it’s only fair that I decide whether or not a new window opens for certain situations. Yes, yes, screenreaders will bark. Fine, then why not come up with something to include for them, in browsers or in their screenreaders themselves that recognize these actions and disables them. Why is it always on us to make our sites work worse for everyone just so some can have an easier time? I don’t mean to be callous, but for something as useful as being able to target a new window/tab, it jsut seems like it would be easy for screenreader setups to be “setup” to recog/dismiss this and allow us to still make good use of it. Or the browsers could have an OFF switch for targets just like they do for javascript. Then people who don’t like it, don’t have to deal with it, and those that do, and those that create it for a reason are allowed to enjoy it’s usefulness.

    Example of useful and benine use of target=blank: Giving your viewers the option of clicking an image to view it/or download it in a much larger size then your designed site or designed thumbnail size. Which, by the way, was already shrunk down to minimal size for the dial-up crowd, notated for screen readers and generally stripped of quality to make it load fast. Well, if I want to give them a shot at viewing a higher res image while keeping them from having to hit back buttons and wait for reloads everytime they do, then I should be able to by targeting a new blank window for them that they can close and have never left the main page.

    We shouldn’t have to create a bunch of JavaScript to cause pop-ups or new blank pages to do the same thing because this just adds wasted time for the author and confusion to those using our templates, not to mention all the tons of extra bytes created by JS, the new errors created by it, the users that shut JS off, and on and on and on…

    This should not be a requirement of strict as it is now and just confirms to me that those qualifying our code and doctypes are not well rounded or remotely creative enough to be creating restrictions for us. They are instead simply creating a job for themselves, simply power-tripping, or just plain bored with life and spend their time mucking up everyone else’s life.

    Is it really that hard to put out one single doctype, get the major browsers to agree to follow and work with this one doctype and dismiss all others? Then everyone would be on the same page with the same restrictions. There would still be bright people coming up with ways to be able to achieve the creative goals within this new single and strict doctype and yet, there will also be peace on the web, peace with the accessibility needs and peace in my mind that I won’t have to change all my sites, melt my brain around another worthless rule change and best of all… stop waste anymore time prognosticating about the possibilities of getting slapped by some ridiculous, proprietary “rules committee” SE for wanting to open a new window instead of forcing all my viewers to keep reloading pages to get back to previously loaded content.

    Is this all an attempt to keep JS relevant in every site, a continuing attempt to keep the majority of people out-of-the-loop or simply, meant to make our lives h3ll?

    enough.

  16. for Rob…

    Since I’m guessing you’ve got the technical side down, or at least is sounds like it from the info on your posted site, I won’t question your knowledge about “new technologies”.

    But your strict attitude about not using past doctypes and inferences about html/xml are really way off base and overbearing. Especially evident after I got a look at your site, then felt the disconcerting feel of each link and page as JS reared its ugly hiccup twitching head after each click. Your site is the opposite of what I strive for both in aesthetics and smoothness. New technologies have long passed the choppy pause-then-slam JS page switches, blinking gif images and such and leads me to believe you have spent way too much of your time trying to satisfy the W3C like it’s your bible.

    You mentioned an interest in graphic design and if this is true, may I humbly suggest you use the same zeal you’ve attacked the backend of the web with and now attack the front end. At the same time, take some 50 grit sandpaper and rub off some of that engineering mindset that was engraved in your soul in school.

    If you do put in the time with an open mind to new things(i’m talking aesthetics here), with the knowledge you have of what is capable from behind, you could be one of the rare few that stand out from the crowd and demand respect from what you create and not from what you simply say.

    Good Luck in Creating.

  17. Cedric I agree totally. Also, have to say, great color selections on this site, graphic quality. Very smooth. It’s a treat to look at and works just as well.

  18. i disagree, sometimes when you do a lot things that are not really legal but they work in all the browsers, there is new ways of doing things which the validation standards doesn’t recognize, their hacks my code never validates but it looks great.Im an absolute div kinda gal anyways so i have divs sideways everywhere lol…

  19. most of the sites here are very heavy content and they just look like a bunch of Bo jangled junk, i see you can validate but you have yet to learn site placement and usability, quite frankly the use of good design, organization people, radical hive is okay- however Ive seen the same layout a trillion times thats been ripped off more than a baby wipe.

    Just from looking at these sites i can see why you guys concentrate on validating because you have no design capabilities, I can make something ugly like that and have it validate for sure… lol

  20. well as far as screen readers go thats the least of your worries concentrate on making a site “not ugly first” look at smashing magazine and deviant art just go on a “inspirational spree” if you cant design then just to back end development, but don’t act like your sites the shit cause it validates, if it looks like crap whos gonna visit it anyways, lol!

  21. I have no problem with validation, it’s the whackos who’re getting retentive about it, that frighten me. Really though.. I should have used a div instead of a span, why again?!!?

Comments are closed.