XHTML Strict

by Jin, 10-03-08 // 35 comments

Since its conception in 2000, many articles, both technical and philosophical have been written about XHTML Strict doctype. Some praise it for pushing forward the web standard, while others despise it for more hassle than its worth.

Regardless, XHTML Strict is here to stay. In this article, I’ll show you what to watch out for, if you DO decide to code your next site in XHTML Strict doctype.

To learn more about XHTML Strict spec, please read:

I read a lot on XHTML Strict doctype before I started coding in it. Once I started, a lot of things caught me off guard, despite how much I read about it. I won’t regurgitate what other excellent technical references already have on this subject. Here are some of the less obvious “gotchas” I encountered.

The Basics

Target, annihilated

One of the biggest complaints people have about XHTML Strict is the abolition of the “target” attribute in anchor tags. We’ve been using target tag to launch new windows for a long time. The reason behind this change in the Strict DTD is because the enforcement of separating structure and presentation/behavior. “Target” is considered as a behavioral element. While this is sound and all, it’s highly unpractical. To fix this, we’ll need javascript. In your html, instead of

<a href="stuff.htm" target="_blank">open me</a>


<a href="stuff.htm" rel="external">open me</a>

We replace target=“_blank” with rel=“external.” Note, I’m using “external” as a logical choice of word. You can use anything you like, but make sure to reflect that in the javascript below. Add this snippet of code in a external .js file and included it in your page.

function externalLinks() {
  if (!document.getElementsByTagName && document.getElementById) return;

  var anchors = document.getElementsByTagName("a");

  for (var i=0; i<anchors.length; i++) {
   var anchor = anchors[i];
   if (anchor.getAttribute("href") &&
       anchor.getAttribute("rel") == "external")
       anchor.target = "_blank";
window.onload = externalLinks;

This code was originally written by Kevin Yank. I’ve been using it for a while.

Since my site already uses JQuery (as many of you do, due to its powerful features and rise in popularity), recently I rewrote this script using JQuery’s native functions.

First, your pages need to include the jquery.js. Then simply add the following code. (it can be added in the jquery.js or another external .js file. If you choose to use a different external .js file, it needs to be linked after the jquery.js file.).

$(document).ready( function() {
  $("a[@rel='external']").click(function(){return !window.open(this.href);});

The technique is slightly different from Kevin’s script. Basically, the script looks for anchor tags that have rel=”external.” Once they’re identified, their click events open a new window object, with the url defined in its href attribute.

Both javascript methods degrade gracefully when scripting is turned off. The links will launch in the default window instead.

Embedding Objecting Flash

Another tag that got the ax in the XHTML Strict DTD is <embed>. This becomes a pain when you try to embed a movie from sites like Youtube or Vimeo. Their generated embedding codes aren’t compliant with the Strict mode. For example, here’s a snippet of code from youtube (formatted for viewing).

<object width="425" height="344">
  <param name="movie"
  <param name="allowFullScreen" value="true"></param>
  <embed src="http://www.youtube.com/v/dMH0bHeiRNg&hl=en&fs=1"
         type="application/x-shockwave-flash" allowfullscreen="true"
         width="425" height="344">

We need to rewrite this to validate in strict mode:

<object width="425" height="344"
  <param name="allowFullScreen" value="true" />
  <param name="allowscriptaccess" value="always" />
  <param name="movie"
         value="http://www.youtube.com/v/dMH0bHeiRNg&hl=en&fs=1" />

I noticed when I switch from code view to visual view in my WordPress editor, it automatically converts my clean code back to non-compliant code. This is something to watch for. Not sure if other CMS editors do it or not.


XHTML Strict doctype is fairly easy and straight forward to adapt. I recommend reading the references I listed at the above. This article doesn’t nearly cover all the differences between Strict and Transitional. As for the Strict doctype, I feel it’s not suitable for every site. It should be used, if you have total control over site content. A huge site with a lot of user generated content may run into validation issues down the road. Also webapps with heavily front-end scripting should avoid strict too. I just don’t think the effort is worth it.

Using XHTML Strict mode is an all or nothing type of implementation. Your site has be fully compliant, not just the frontpage, but all the sub pages as well. Otherwise it defeats the purpose.

I hope this article has been helpful, thank you for reading.


also feel free to contact me on twitter or via email
Dmitry 10-04-08

I must say I’m guilty of using the XHTML Strict doctype and then breaking some of its rules, like having inputs straight inside form tags and target _blanks.

The thing is, all modern browsers are quite forgiving, so even if you make validation errors, stuff like that still works — which just encourages people like me to keep doing it :( Is there a ‘real’ incentive for having a fully Strict compliant site? I guess I could use Transitional, but that just feels bad.. makes you feel like you don’t know the proper syntax :)

I think your point about front page validating and then the rest breaking is very good. W3C Validated badge is a nice thing to have, and it’s very easy to just fix stuff up on the front page quickly, grab the badge and then not worry about the rest because you know people won’t be validating sub-pages if they wanna check your site.

Jin 10-05-08

@Dmitry, imo, there’s very little benefit for xhtml strict doctype at *this point.* HTML/XHTML transitional should be fine for most sites. As you said, I think most developers choose XHTML 1.0 Strict as an exercise, for forcing themselves to write code that is most up to date standard. I certainly did it “because I can.” Of course I ran into several issues listed in this article.

Whatever doctype is used, should be appropriate for the nature of the site.

Ben 10-06-08

A Strict doctype renders more consistently in different browsers – that’s why I started using it (years ago).

Jin 10-06-08

@Ben, I’ve read the benefit of “browser rendering” when it was first introduced. However, I can’t find the specific proof how it does it exactly. As in, a thorough testing between the rendering results of a transitional vs. strict doctype. What elements render more consistently? I’ve tried to search for details on this subject but couldn’t find any. And my personal testing between transitional vs. strict yielded no difference.

Lucas 10-06-08

So ummm … you did that jQuery script huh?!?! =P

And, “Gettin real tired of you duckin me man. … Where’s my money, wheres my money …” ;)

All that aside, strict is all around better and more refined than transitional and should be used. Almost everyone’s argument to why they hate strict is the “target” issue. But it’s not really an issue AT ALL. Most modern browsers are javascript enabled, and most of them are turned on. Any browser that doesn’t support javascript, probably doesn’t support new windows anyway, e.g. mobile browsers, and it doesn’t matter. Outside of that it degrades gracefully, AND you can still open any link in a new tab/page by holding CMD (Control on PCs I think).

I use strict and only strict but I can also tell you that I’ve never really seen any type of better “browser rendering” at all. Unless you speak in terms of because of it’s “restrictions” in the way you’re forced to markup reducing the different ways a browser could possibly translate. When HTML 3 makes it’s appearance it’ll be more important than ever for people to markup properly and be more semantic (YES!). Developing in strict is the best step in that direction at the moment IMO.

Jin 10-06-08

luke, I owe you money indeed :) Kudos on your site, i was wrong.

Dmitry 10-07-08

Regarding better rendering: Strict mode forces IE6 to use the proper W3C box model. Don’t know of anything else of note.

Nick Pettit 10-09-08

Huzzah for valid XHTML!

Objecting Flash as you so aptly put it is a problem that my buddy Jim and I encountered all the time, so we built a tool called Validifier that turns Flash embed code into valid XHTML 1.0 Strict all automagically.

Check it out at:

Jin 10-09-08

@Nick, nice app! It’s funny you posted about it. After I wrote this blog I decided to write one of my own, since I couldn’t find one that does what you have built. It’s very helpful, thanks for sharing.

Joshua 10-15-08

Is there any point in even using XHTML, I’ve been using strict/transitional for years but since realised that unless you serve the content type up (from the server) as application/xhtml+xml then its not even really XHTML. If you do serve it up correctly then all the IE browsers that ever existed simply wont display it.

Jin 10-15-08

Joshua, there had been talks of XHTML pages are SEO friendly. However after much research I can’t find any proof.

The benefits I can think of: XHTML is XSL ready. It’s also is mobile browser friendly, which increasing in market share of these days.

Another indirect benefit I can think of, is to make us write semantic code. I think of it as a strict HTML.

Joshua 10-15-08

XHTML pages are generally considered SEO friendly (especially if they validate).

My point really is that IE has never supported XHTML correctly and is going to continue not supporting it. They are not adding support for a XHTML parser in IE8 unfortunetly.

This means to serve strict XHTML to IE correctly its virtually impossible because IE just tries to download the file (there are XSL hacks of course).
Whereas using the transitional doctype IE can handle it correctly. Serving transitional up as text/html also conforms with the W3C recommendations – serving strict doctype up as text/html does not.

I’d love to serve up strict XHTML on all my sites, but I really see it as an impossibility until IE supports it correctly :(

Jin 10-15-08

here’s why it’s not supported by IE


It’s kind of interesting to hear MS talk about “compatibility” issue…

But is there any reason why you would use “application/xml+xhtml” instead of “text/html” though? from a practical stand point.

Joshua 10-15-08

From a practical stand point I guess not. But then you run into problems adding additional XML namespaces to your document (i.e. RDFa, which only just became a recommendation) because its only parsed as HTML.

If you don’t care about that kind of thing I guess theres really no problem in using strict on your website. IE will still ignore the fact you’ve set it as strict XHTML and just process it as HTML though :(

What it really comes down to for me I guess is that IE doesn’t support XHTML. By using a transitional doctype I can change the content type that the server delivers based on the Accept header (in the HTTP request) and the page I deliver will still be valid in all contexts.

Joshua 10-15-08

Am I wrong?
Should I serve up strict XHTML regardless of the content type?
I was just under the impression that you had to serve up strict with application/xhtml+xml.

Sorry for de-railing your discussion.

Joshua 10-15-08

Fair enough, I’m going to keep everything as strict from now on.

Although I’m going to have to find a good work-around for IE though in terms of using additional namespaces like ARIA.

Thanks for the article and discussion though, It helped make up my mind on what we as web developers should be supporting.

Jin 10-15-08

According to WC3:

This document summarizes the best current practice for using various Internet media types for serving various XHTML Family documents. In summary, ‘application/xhtml+xml’ SHOULD be used for XHTML Family documents, and the use of ‘text/html’ SHOULD be limited to HTML-compatibleXHTML 1.0 documents.’application/xml’ and ‘text/xml’ MAY also be used, but whenever appropriate, ‘application/xhtml+xml’ SHOULD be used rather than those generic XML media types.

*Ideally* we all should be using app/xhtml+xml. But in reality we don’t, for the reason IE doesn’t support it. Of course, we notice this, and object this because we’re developers. Think about it from users pov, they don’t care what’s under the hood…

Which renders this article useless :)

Jin 10-16-08

Thanks for bringing this up. To be honest I never gave it too much thought.

Regardless, one thing is for sure: writing XHTML Strict code is a good practice to be up to standard. It keeps us from writing sloppy code. I do it to keep myself in check.

Ricky Ly 10-22-08

Thx for putting up this site.
I am working with HTML Strict and when I had my http://www.rickyly.com validated, it gave me an error for my <a href=”" target=”nofollow”>, uncool.
However, in doing a Google search I found your page on the 1st page, and your above information helped me straighten out my intro page. Keep sharing… Ricky Ly.

Ricky Ly 10-22-08

By the way, do I need to acquire a license to use


Jin 10-22-08

@Ricky, I’m glad it was helpful. JQuery is a free javascript library.

Here’s a nice tutorial on other things you can do with JQuery.

RiverC 08-20-09

Jin, I know this article is old, but am I correct in assuming your first javascript solution to the target=”_blank” issue is simply finding all anchors with rel=’external’ and giving them target=’_blank’ ? I would suppose this gets around validating the page, but…

Doesn’t that basically mean that all browsers support ‘target=’_blank” even when they are supposedly in ‘strict’ mode? This smells of bureaucratic insanity; I don’t think it is a good idea for anyone to use Strict if it means this kind of byzantism. Wasting processing cycles to get validation works fine, but it is highly inefficient, getting ever more so with other complications that result from richer webpages (ajax, user generated content, etc…)

If I’m wrong about this, let me know…

Jin 08-20-09

@RiverC, You’re correct. In fact, the second JQuery solution I made shares the same similar logic as well.

Since I wrote this article, I’ve given it some thoughts about strict doctype. I REALLY do not like the no target rule. This forces us designers/developers jump hoops just for the sake of “this page validates” ego badge. There were times when I told programmers to use & for the url strings from their back-end code so my front end would validate. This doesn’t make it easy for anyone, normal does it have any real benefit.

Too often, we get tied up with writing compliant code, rather than to questioning if the rule makes sense.

Also, there’s almost very little benefit in writing a site in XHTML over HTML. Thank you for your comment.

RiverC 08-20-09

Ah, I see. I found this looking for a solution to an unusual problem; Mozilla when viewing our website in places (samuelsonsdiamonds.com) will kick into Quirks Mode. Now, granted it is a retooled quirks site, what is odd is that it is inconsistent; reload the same page 10 times and one out of ten loads will be in Quirks. I attempted to convert a few pages to XHTML 1 Strict compliance to see if it was some part of that formedness (or ill-formedness as the case may be) that was causing Firefox to *sometimes* choose quirks mode. I gave up when I read about the target rule.

I am going to try a few things first, but I saw one person who had this problem on the Mozilla zine site, but with no responses. I am thinking – and this is a hunch – that it is simply an inherent flaw of Firefox XHTML rendering. HTML 5 looks like a green pasture, excepting of course, the lack of anchor names (one of the most useful features of HTML ever!)

It is such a weird world out there. Thanks for the response.

Casey 09-20-09

I started using onclick=”target=’_blank’” and that works great and validates. Easier, imo.

RiverC 09-21-09

By the way, Jin. As for my second comment, the weird bug with FF went away when I changed the site from XHTML 1.0 strict to HTML 4.01 strict. I was noticing it on other computers (it was affecting display of fonts in critical areas) I suppose I originally used XHTML 1.0 because Joomla! was using it, and I used Joomla! for awhile. I wonder if others ran into the same problem.

Derrick 10-05-09

In reality, no one but other developers (and even then, very rarely) ever checks your validation badges. I find that people who code to a standard do so for themselves, not for others. Personally, I use the HTML5 DOCTYPE to force all browsers into strict mode, serve it as text/html to be cross-browser compliant, and then write XHTML-compliant code. In the strictest sense of the word, nothing I write “validates”, but given the choice between making a well-structured, functional, cross-browser website that doesn’t validate, or vice versa, it’s a no-brainer for me.

Mike S 10-19-09

I was considering moving from HTML 4.01 to XHTML because I read that it would give my sites the best forward compatibility with future browser releases, but after reading about IE I’m wondering if it’s even a good idea – it sounds like it will cause more problems than it solves.

Also is there any reason not to use Casey’s onclick=”target=’_blank’” as it eliminates the need for javascript?

Jin 10-20-09

@Mike S, because if people have Javascript disabled then all your links won’t work. See Unobtrusive JavaScript

Mike S 10-20-09

Thans Jin, I didn’t realize that onclick was javascript, not that I thought about it, but I though the javascript had to be declared in tags, thanks for the link.

Is there any way to open XHTML strict links in a new window without using javascript?

Mike S 10-20-09

What do you think of this approach, which uses a custom DTD:


It is described in more detail in the 8th message by Orbyte here:


As the last post on the page and the link below describe,

The “target” attribute should not be marked as deprecated. Though not deprecated, it is not defined in the Strict DTD either.

HTML 4.0 Specification Errata

RiverC 10-20-09


It seems to me that the target attribute should be deprecated, since the information of where to put the new page is not part of its structure, thus belonging to another layer. The problem with deprecating it is not that it is incorrect but that web pages rely on the old standard. Arguments about frames and whatnot also fail because they were hacks to begin with, to deal with a situation where the standard could not support the desired functionality (yet.) I predict (if anything) that target=” will still be supported by browsers into perpetuity, in the same way that IE’s transition effects and mozillas ‘moz-…’ css attribs are unlikely to disappear.

Either way, the most important thing here – I think – is to adhere to the standard as closely as is reasonable, and to at all costs avoid invoking quirks mode. A good design from a good designer goes bad gangbusters style with just a fall into quirks mode.

Also, I would not recommend XHTML at all. I ran into a strange bug in Firefox 3 that occurred when it tried to parse XHTML (it randomly dropped into quirks mode – probably based on how the page was loading over the ‘net) but did not happen in HTML.

However, the choice is up to your best discretion. Given that HTML 5 supports the old style HTML; no self-closing tags for instance, and the boondoggle that is XML, switching over is not a no brainer, but a definite case for a cost-benefit analysis.

Mike 10-20-09

Thanks for the note about FF, I have to agree, XHTML Strict doesn’t seem like it’s worth the trouble.

rocktivity 01-20-10

Thanks very much for the “target” javascript–it now resides on my root directory. I cut and pasted your example code, but the 3WC validator came up dirty until I put the line between paragraph tags.

And since I can call the rel anything I want, I’ve named it–WAIT FOR IT!!!–”target_blank,” of course!

Ian.J.Gough 01-22-10

Great just what i was looking for i’ve spent a couple hours trying to get it sorted but your script requiring jquery.js is great! Thanks very much.