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:
- XML - Managing Data Exchange/XHTML
- XHTML™ 1.0 - Official ducment from WC3
- Comparison of Strict and Transitional XHTML
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
- All the attributes have to be a key+value pair. For example, <option selected> needs to be <option selected=”selected”>,
- block-level elements such as <p> can only contain text and inline-level elements.
- <form> as a block level element can only contain other block level elements, as immediate children. For example, the following is not allowed since <input> is not a block level element.
<form action="somescript" method="post"> <input id="first name" type="text" /> <input id="easteregg" type="hidden" value="bacon" /> </form>
We need to encase <input> in a block element such as <fieldset>.
<form action="somescript" method="post"> <fieldset> <input id="first name" type="text" /> <input id="easteregg" type="hidden" value="bacon" /> </fieldset> </form>
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>
do
<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"
value="http://www.youtube.com/v/dMH0bHeiRNg&hl=en&fs=1">
</param>
<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">
</embed>
</object>
We need to rewrite this to validate in strict mode:
<object width="425" height="344"
data="http://www.youtube.com/v/dMH0bHeiRNg&hl=en&fs=1">
<param name="allowFullScreen" value="true" />
<param name="allowscriptaccess" value="always" />
<param name="movie"
value="http://www.youtube.com/v/dMH0bHeiRNg&hl=en&fs=1" />
</object>
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.
Thoughts
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.
If you enjoyed this article, please subscribe to my RSS for future updates.
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.
@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.
A Strict doctype renders more consistently in different browsers - that’s why I started using it (years ago).
@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.
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.
luke, I owe you money indeed :) Kudos on your site, i was wrong.
Regarding better rendering: Strict mode forces IE6 to use the proper W3C box model. Don’t know of anything else of note.
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:
http://validifier.com/
@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.
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.
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.
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 :(
here’s why it’s not supported by IE
http://blogs.msdn.com/ie/archive/2005/09/15/467901.aspx
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.
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.
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.
According to WC3:
*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 :)
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.
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.
Jin,
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.
By the way, do I need to acquire a license to use
“jquery.js”?
Thx
@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.