Roger wrote:

” ... talk about XHTML as being more strict than HTML. In a sense it is, since it requires well-formedness and quoted attribute values.”

I really don’t mean to nitpick, but, using a strict doctype means that you follow the specification to it’s strictest standard. Using the word “strict” in a comparitive sense, (X)HTML is “strict’er” than HTML only because it requires the coder to write more to accomplish validation, but I don’t think that this is what “strict” really means within a doctype context—it’s not comparative.

Also, it’s a common misconception that HTML isn’t required to be well-formed. The same nesting rules apply—just because you’re not required to close tags does not malformedness make :)

Somewhat off-topic, personally, I agree with the likes of Ann van Kesteren who argue for not using (X)HTML at all unless you’re prepared to serve the Content-Type as application/xhtml+xml.

:) Anyhow, good article! geat site! and keep up to awesome work. I really look forward to the daily posts and I’ve already learned some cool stuff :)

Richard and Lawsy: Thanks! Note that there are more elements and attributes than those I mention here that are not allowed in HTML/XHTML Strict. For the full list, refer to the articles I mention.

XHTML 1.0 Strict or XHTML 1.1 – is there a tremendous difference? I assume the latter would be the best choice?

Andrew: Maybe it’s been decided that it’s annoying to auto-popup any link in a new window for unknowing users. They can jolly well open it in a new window/tab themselves if they had wanted to.

Yes, the alternative is JavaScript. If JavaScript isn’t available, then the link will open in the same way as normal.

As with most things to do with web publishing, any control you think you have is mostly an illusion. It’s supposed to be like that.

Wow, trovster. Did you really scream? LOL. And I though I was nitpicking. Sure, he left out Frameset, but who the hell uses framesets? ;) While we apparently agree on not using (X)HTML, it looks to me like you could probably do with a little relaxing, my friend :)

@Allan: Yeah I suppose I could have been a bit clearer on the well-formed issue.

@trovster: I deliberately left out the Frameset DOCTYPEs because they are rarely used and don’t have anything to do with Transitional vs. Strict, which is what this article is about. Sorry if that made you scream ;-).

Roger,

An enlightening article, with a message that’s worth saying again and again.

I personally use xhtml strict (serving application/xhtml+xml for decent browsers and vanilla text/html for ‘special’ cases) for most projects, out of habit more than anything else. I don’t use any new features the ‘X’ gives me, but I find it easier to stick to one language for consistency between myself and my collegues (some of whom are still learning (x)html). I figure stating all projects must be strict xhtml is a way of making my life easier, and avoiding future problems :)

Cheers;

Poncho

you know, I’m all for this. Standards would be great. Fabulous even.

But in the real world: nobody cares, nobody adheres, and yet the world turns.

I’ve got 3 browsers on my system: none pass the Acid2 test. All render essential elements slightly differently, or not at all. Yet in the real world all work (more or less).

I fear we missed the chance to set these standards in stone during the ‘wild west’ years of the net and unless we move to a whole nother system we’ll be stuck with broken/half-implemented standards for the unforseeable future.

I’ve read a lot from Roger, Anne, and others in the XHTML/HTML discussion, and I think that the single most important issue is the use of Strict doctypes.

The first step on the road to better standards support is to get the average developer to move to Strict. Of course, they then need to make sure they’re writing valid, well-formed code…

Once you can write Strict, you can move into the html/xhtml debate. I tend to see developers starting with tag soup, moving to (X)HTML transitional, then XHTML strict, then back to HTML strict. So we need to get people using Strict before we can have the language debate.

Personally, I use XHTML, with application/xhtml+xml. I know many would disagree with my choice, but many more wouldn’t even understand what we’re talking about.

Let’s start with Strict and go from there.

Definitely prefer to use strict; cleaner markup, more control with css etc. However I still find myself using transitional for sites strictly for the target="_blank" attribute.

I guess javascript could be used but that just seems like overkill IMHO. So why exactly is target deprecated?

bart: Yes, XHTML 1.0 Transitional triggers Almost Standards Mode in Gecko-based browsers (Mozilla, Firefox, Camino, Flock, etc).

ARGH. I screamed when I read the first paragraph of this article.

But there are two flavours of XHTML 1.0, defined by the Transitional and Strict DOCTYPEs. And HTML 4.01 also comes in those flavours.

WRONG. Plain and simple. XHTML1.0 has 3 DTD, just like HTML. Strict, Transitional and Frameset

Every XHTML doctype (without the xml prolog declaration makes browsers display in standards mode. However, only Strict HTML does the same. But this reason isn’t a reason to use XHTML.

It is also a fact you can write as semantically-incorrect XHTML as you could HTML. This is because they’re like for like on every element. And the only difference in attributes seems to be “name” mentioned below. However, you can write perfectly semantic HTML just as easily as XHTML.

I see no reason to choose the X over old-vanilla HTML. I was lured into the “world of the X”, but I’ve since understood the errors of my way and have choosen the most appropriate markup language of our day.

I’m not to say XHTML doesn’t have its benefits, especially for newcomers, as it gives the false illusion that it’s a lot stricter, and this can benefit people interested in new ways of thinking and using standards-based markup.

No, I didn’t actually scream, I’m at work here and that’d just be embarrassing.

@roger: You left out Frameset, but you still incorrectly mention that XHTML1.0 only has two DTDs, but it has three.

The mist has cleared and I’ve actually made the mistake. Dammit. I misread “those” as “three”. (My excuse it was 9.30am!) That is what lead to the anguish. However, it’s still incorrect, but less so!

Every XHTML doctype (without the xml prolog declaration makes browsers display in standards mode. However, only Strict HTML does the same. But this reason isn’t a reason to use XHTML.

Wrong ;).

IE will use “standards” mode with Transitional and Frameset DTDs too, if URL of DTD is present .

The same applies to the Opera .

Things are a bit more complicated with Gecko and its three modes .

Good article. One thing that isn’t mentioned though, is that Transitional can, at best, only trigger Almost Standards Mode in Web Browsers that support three rendering modes: Quirks Mode, Almost Standards Mode and Standards Mode.

Thanks Roger, this is another article I’ll be using as a reference.

Thanks for the links too.

@John:

Whether you aim for 100% validation sitewide or aim for strict separation of content and presentation is totally different.

It’s hard to have a totally valid website, because you may work with developpers who don’t know better and you have to make do with a stale browser base, but if you use that as an argument to use tables for layout and to mix content and layout then you’re very wrong.

John, even if users don’t care about standards (and that is true) and that even if the page still works when not adhering to standards, there are some very good and practical reasons to live by them. For instance, increased accessibility, smaller file sizes for bandwidth savings, faster page loads, etc. I feel like I’m beating a dead horse here because this same argument has been answered many times over. See Roger’s own Ten reasons to learn and use web standards.

If you are a fan of Roger’s work, or if you enjoyed this article, you’d probably enjoy The Perils of Using XHTML Properly, also by Roger.

http://www.456bereastreet.com/archive/200501/the_perils_of_using_xhtml_properly/

John,

What type of “whole nother system” would you propose we adopt?

Also, surely just because we currently live with a particular system doesn’t mean we shouldn’t strive to change it. 

At any rate, the reason to push for standards is not because nothing else works; it’s because it makes more sense to do so.

And if you were using Safari 2.0 (which passes Acid2), you’d know what a breath of fresh air it is to not have to worry about major CSS bugs when you were setting up the first-draft of your layouts. It’s a real time-saver.

Roger – Thanks for the article.

Concerning “input elements must not be direct descendants of a form element” does this mean that even inputs of type “hidden” must be within block tags?

Aaron: Yes, all input elements regardless of their type.

Interesting to know, considering i’m building a site in HTML 4.01 strict at the moment, it’s a bit annoying, and seems a slightly unnecessary restriction… (I’ve always added input type=hidden tags after the form tag or before the closing one for clarity.)

Sometimes I think somebody just made up some of these rules so I would get annoyed and then be forced to break them!

@Will Kelly:

I usually stuff all my hidden fields in the same paragraph as the submit button, it has no impact on the display.

The only time this “restriction” is a problem is when you have a form with only hidden fields. You might have to create a special style to hide the wrapping element.

@Bill:

About Safari, I happen to be developping a site in HTML 4.01 strict and a CSS-only layout on my Windows PC and though I always test on several browsers on Windows I never test on Mac (don’t have one, please donate ;)). So when I tested on the designer’s machine (yes designers use Macs) on Safari, I was in for a shock: flawless rendering. Lazy developers got to love them web standards !

Nice article! I found the elements/attributes lists very useful

Great article the list of attributes not allowed is rather long, I didn’t know you couldn’t have half of them!

You might be able to tell I use the Transitional DOCTYPE, because I really don’t have the time to improve my code.

Here’s a reason to know and use strict-compatible code and Web standards: because you can’t get a job with my agency if you don’t.

Arguments about how non-strict and non-standards compliant code work just fine and nobody cares will eventually begin to ring hollow when more and more employers, like mine, begin to insist on competent coders rather than make-do coders.

Sure, sloppy and deprecated code works most of the time. But it might be good to think about if you’ll be working most the time – or losing job opportunities to those who care about this stuff.

Phil: A very important difference between XHTML 1.0 Strict and XHTML 1.1 is that XHTML 1.1 should not be served as “text/html”, while HTML compatible XHTML 1.0 may be. That pretty much rules out XHTML 1.1 until the vast majority of browsers (hrm, Internet Explorer) support the “application/xhtml+xml” media type.

Re: “Concerning “input elements must not be direct descendants of a form element” ”

You can (and should) use a fieldset immediately inside any form element, thus making imput elements direct descendants of the set and not the form tag.

Are there any rendering differences between serving up a valid XHTML 1.0 Strict document with a Transitional DOCTYPE vs. Strict DOCTYPE?

Drew McLlelan, thats a wonderfull explaination for why target=”_blank” attributes being deprecated, but what are the alternative available if someone really need to open external website in a new browser window using XHTML Strict? is it JavaScript? Then if JavaScript is disable in client machine, what are the way out?

i’m pretty confused, why “background” is listet as no-go attribute for xhtml -in strict mode, because i’m using xhtml 1.1 that i thought not to be transitional, right?

my website is far from valid nor semantic markup, well anyway: in order to go with at least one way to impress my friends ;) i’m using an image replacement-technique on headline-text. all content comes from a blogging-platform / sql-database.

so the extension, that allows image replacement is waiting for the headline text being delivered from the blog-tool, in order to create the image.

thats why i implemented this as inline style of my blogs theme-files. (so though not allowed its working for me – think thats strange?) do you see a need or a away to rework this?

well, i’m thinking of the ability to leave this info in a dynamic stylesheet maybe, or appending information to it each time i post new articles.

am i getting you wrong?

what do you think?

I originally developed the SEO Analyzer tool for creating web standards based search engine optimized web pages. By default, the tool reports any obsolete or deprecated HTML, so it’s an excellent tool to check for what Roger is suggesting.

@erik: The “background” I am referring to is the “background” attribute in HTML, not the “background” property in CSS.

Evergreen post for web developer the best solution on DTD. Thanks a lot for informative post…