HTML 4.01 / XHTML / Strict / Loose / Transitional? What should I use?

if you have a server-side scripting language it is fairly simple to overcome IE's lack of support for XHTML.  Your server-side language needs to access your HTTP headers and determine whether or not the browser will support the application/xhtml+xml MIME type.  If it will, then it does so, and if not your script would then present the page as text/html.

a good article on this subject is: http://www.smackthemouse.com/xhtmlxml

Just like to add a couple of things;

My personal take on the XHTML debate is use it as your doctype IF you are using XML elsewhere on your site. i.e. undertaking XML / DTD / XSL transformations, handling XML RSS feeds etc.

From the point of view CSS / browsers there's no substitution for testing - make sure you test cross-browser as you develop & address quirks & hacks as you go.

http://www.smackthemouse.com/xhtmlxml is not a good article.

Quote:
All we need to do is to test if the accept-header sent by the browser, etc., contains the string "application/xhtml+xml"

So:
Accept: text/html,chickensapplication/xhtml+xml (I accept text/html and some made up MIME type)
and
Accept: text/html;application/xhtml+xml;q=0 (I accept textx/html, but I DO NOT accept application/xhtml+xml)

would both be sent application/xhtml+xml.

And if you are going to serve to some clients as text/html, why not serve to all? Its not like you are getting any of the benefits of client side XML.

If you are undertaking XSL transformation - why transform to XHTML? You can transform to HTML just as easily.

dorward is right:
1.  Currently, your best option is strict HTML 4.
2.  Content/presentation separation principle says your html should strictly reflect the structure of your content without any type of reference to layout.  Then you use CSS to do the layout.

dorward, clearly the method undertaken by the article at smackthemouse.com works.

open that link in both IE and FF and view the source in each.  In IE, you will notice the first line is the DOCTYPE, and there is an included meta tag declaring the content as text/html.  Then view the source in FF.  You will see that now it is loading as an XML document (first line is xml declaration), and the meta tag is not in there.

The method does work, and allows XHTML to be used by compliant browsers(aka FF), and still viewed as text/html in those that don't support XHTML (aka IE, etc.).

flow79: Clearly you do not understand the points I made.

Point 1:

The HTTP Request header:
  Accept: text/html;application/xhtml+xml;q=0
says: "I accept text/html but I DO NOT accept application/xhtml+xml".

The code provided at smackthemouse.com will look at that accept header as see "Ah, the string application/xhtml+xml is there, therefore they accept application/xhtml+xml" - which is wrong.

The HTTP Request header:
  Accept: text/html,chickensapplication/xhtml+xml
says: "I accept text/html, and I accept chickensapplication/xhtml+xml".

The code provided at smackthemouse.com will look at that accept header as see "Ah, the string application/xhtml+xml is there, therefore they accept application/xhtml+xml" - which is wrong.


Point 2:

The benefits that XHTML can give you (mixed namespaces) can't be used when the XHTML is served as text/html. So the XHTML that you write can't use the benefits of XHTML if you want to serve it as text/html. So what's the point of serving what is (as far as the browser is concerned) HTML with errors in it?

I've seen a server side script that will check the q value of the mimetype also, and if the ua doesn't support xhtml, it will get rid of all the /> and other xhtml stuff, so it serves pure xhtml to those who really can support it and pure html to those who can't.

Anyways, my opinion:

XHTML is alright to use, get ready for the future, XHTML 2.0 will be separate from 1.x, so don't worry
That mimetype stuff isn't all that bad, as long as you do it right.
I would use XHTML Strict, I personally use 1.1
DIVs aren't bad either, they are not a last resort, they are a presantaional element, meant for you to mess with them untill you like what you see, like this: http://www.chudosok.info/, a website I made that works great in IE6, FF, Opera, the layout is all DIVs and CSS.
IE is definetely the browser to give you the most trouble, you may have to apply hacks.
As for IE5.x, I haven't messed with it, so I can't say anything about that.

>XHTML is alright to use, get ready for the future, XHTML 2.0 will be separate from 1.x, so don't worry

If XHTML 2.0 is going to be seperate from 1.x, then isn't that the future and 1.x is a waste of time?

> That mimetype stuff isn't all that bad, as long as you do it right.

Which, as has been demonstracted, is very hard.

I note that the website you referenced is serving XHTML 1.1 as text/html despite the "SHOULD NOT" having over doing that.

And _still_ if you aren't going to use any of the XHTML features which give it advantages over HTML then what's the point of using it?

> DIVs aren't bad either, they are not a last resort, they are a presantaional element

Divs are a last resort - which doesn't mean document with 20 divs in it is a bad document, just that you should look for an element that is a better fit *first*. Generic elements for everything is almost as bad as using tables for layout - the difference is that instead of haven't wrong semantic information you have NO semantic information. What are screen readers supposed to do? Or search engine indexers? Or browsers which don't support CSS?  So if you have a paragraph - say its a paragraph (Use <p>, not <div>), and if you want empathis say emphasis, not span with a class.

They aren't presentational elements either. They are generic block elements with no semantics and no presentation (other then being blocks) attached to them.

As for chudosok ... using JavaScript instead of links? That's horrible.

On the subject of designing in divs: http://www.rikkertkoppes.com/thoughts/smurf-language
It's just as bad as designing in tables. Dorward is right when he states you should design using CSS. Html is only semantic markup to create a logical structure in your data, use css to transform the default layout to what you think is more visually apealing.
Some aditional text that goes well with explainging the use of html, specifically classes (same author): http://www.rikkertkoppes.com/thoughts/class-and-style

On the subject of xhtml 1.1, don't ever use it!! The majority of the market still uses IE, IE is completely incapable of handling xhtml 1.1 because xhtml 1.1 must be sent as text/xml. When you feed it to IE as text/html it no longer renders in strict mode and the css bugs will hit you in the face, hard!

I too would recommend using html 4.01 strict, personally, since a lot of people around me just don't get it, yet, I use transitional a lot, you don't have to use the crappy aditional muck in transitional when you declare, but you can, if you want too, and still render in strict mode, to make your css-styling a little less of a hassle.

My two cents,

  Martin

My use of <div> would merely be to devide the page in three or four areas: logo, top menu, left side navigation menu, and main content. In the main area can be different elements with different functions, like login form, table data in a list, help text about the page, etc. I still use html-tables to display lists of data with column headers, or two column tables with left side the column name and right side the value.

We use several elements on the page of a website, for instance help text. The help text has a different layout, so I use a <div class="help"> around the help text. Inside that div, I use h1, p, b, whatever I need to structure the data or text. So there I use standard html the way it was meant. I could do <h1 class="help"> and the same for p etc, but that's not really handy. In the CSS I define it like "div.help h1 { color: red; }" etc. The container-div is handy here for margins, backgrounds, padding, etc.

So this way I use divs to layout the page, and I wouldn't know how to do it differently.

But, you could for instance set the class="help" on you body instead, because the fact that you're on a help page applies to everything there, even if you only style the content differently and not the menu.

Other than that, what you're doing is more or less the essence of using divs for divisions, so I'd say you're on the right track there. I hope that our differences in opinions about which doctype to use aren't too confusing and wish you the best of luck on making your decision :)

 Martin

The discussion about doctypes is beginning to make sense, especially the part about the mimetype, and that it's useless to server xhtml as text/html. I think I'll stick with html 4.01 strict. It's quite interesting though, this discussion.

mreuring, what you say about setting the help-class on the body is not an option. The help-text is just an optional element on a page, and therefor it's in a div.

I've had this discussion too often to find it interresting anymore :) There's a permanent difference in opinion on the matter, I just think practicallity should be leading, and that would lead to strict and not xHtml, just make sure you validate the html-code and I think the standards fanatics will be quite content.

On a sidenote, for ease of work, you can install an extention in FireFox which will validate using w3c's tiny validator, this will give you imediate feedback when browsing your pages using FireFox. A must have for developers who want to get serious in making validated websites.

concerning the help-class makes a lot of sense setting the class on a surrounding div then :)

Word of warning: Tidy isn't a validator, its a lint - and it does make errors in its syntax checking process from time to time.

> If XHTML 2.0 is going to be seperate from 1.x, then isn't that the future and 1.x is a waste of time?

Well, helped me get used to all the standard complient stuff and throw the quirks off

> Which, as has been demonstracted, is very hard.

True, I'll go search for that premade script you can use

> I note that the website you referenced is serving XHTML 1.1 as text/html despite the "SHOULD NOT" having over doing that.

Well, it's kind of temporary, I'm working 2.1 which will be sent as application/xhtml+xml to those that can handle it and I'll think of something for IE, like text/xml + an xsl hack so that it will display correctly. The point is, it's not the worst thing that ever happened.

> And _still_ if you aren't going to use any of the XHTML features which give it advantages over HTML then what's the point of using it?

I probably will, give me some time. And it's good for learning to do things strict.

> Divs are a last resort - which doesn't mean document with 20 divs in it is a bad document, just that you should look for an element that is a better fit *first*. Generic elements for everything is almost as bad as using tables for layout - the difference is that instead of haven't wrong semantic information you have NO semantic information. What are screen readers supposed to do? Or search engine indexers? Or browsers which don't support CSS?  So if you have a paragraph - say its a paragraph (Use <p>, not <div>), and if you want empathis say emphasis, not span with a class.

Sometimes I will have to stick a few <p>'s in a element, div's are good for that.

> They aren't presentational elements either. They are generic block elements with no semantics and no presentation (other then being blocks) attached to them.

I meant not presentational but for doing pretty stuff, sorry for the wrong word >_<.

> As for chudosok ... using JavaScript instead of links? That's horrible.

It uses ajax, just an experiment I wanted to do, it will be fixed in 2.1

> Well, helped me get used to all the standard complient stuff and throw the quirks off

Why wouldn't HTML 4.01 do that?

> I'll think of something for IE, like text/xml + an xsl hack so that it will display correctly.

What about lynx? And GoogleBot?

> I probably will [use XHTML features], give me some time.

Which will break it for all non-XHTML user agents.

> And it's good for learning to do things strict.

So is HTML 4.01 Strict.

> Sometimes I will have to stick a few <p>'s in a element, div's are good for that.

If you need to group the paragraphs together and there is no element with the right semantics ... but then that is the last resort.

> Why wouldn't HTML 4.01 do that?

Because the browser won't complain as much if you do something wrong, especially on javascript.

> What about lynx? And GoogleBot?

Serve it as text/html to those. I'm probably going to edit that script and make it go accross bots too.

> Which will break it for all non-XHTML user agents.

That's why I'm taking my time.

> If you need to group the paragraphs together and there is no element with the right semantics ... but then that is the last resort.

Well, I guess, but I never considered it that way.

> Because the browser won't complain as much if you do something wrong, especially on javascript.

Is this a quirks/standards mode thing? HTML 4.01 Doctypes can trigger standards mode.

If its an XML thing, then that just introduces even more issues - such as having to use namespace aware DOM methods, but since those don't work in HTML mode you end up having to write have your scripts twice.

It's more about XML, but if you use HMTL 4.01 DTD, the broswer will still let you give it malformed HTML. XML willl not allow it.

Ah, do you use innerHTML? I tend to use the DOM functions to build elements, that prevents you from writing non-well-formed code.

The thing is, I think using XHTML isn't all that bad, I would encourage it, in fact. It will result in better built websites if developers check the validity and accross most popular browsers, espacially the ones who support the xhtml mimetype

> Ah, do you use innerHTML? I tend to use the DOM functions to build elements, that prevents you from writing non-well-formed code.

It depends, most  of the time I use DOM functions.

How will valid XHTML result in better built websites compared to valid HTML?

How will they be worse?

I've mentioned some of these points already, but here goes.

1. Browsers which deal with XHTML as XHTML generally don't do incremental rendering.

2. Some browsers which deal with XHTML as HTML follow the SGML rules and render a ">" character after each tag using XML minimised tag syntax.

3. There is a distact lack of tools for testing conformance to Appendix C of the XHTML specification.

4. To avoid points 2 and 3, you burn server resources converting XHTML to HTML, but using XHTML in the first place gives no benefit to end users.

5. If you serve as XHTML to some user agents and HTML to others, you have to rig your cache control to vary on the accept header - which makes caching proxy servers less useful.

6. XML DTDs don't support SGML exclusions, so validation can't reveal some errors in an XHTML document that would have been picked up in an HTML document.

My main point is you don't need to discourage XHTML usage, if people have the capability of doing it, then let them. I feel discouraging XHTML usage slows developement of the web down. The reason I asked that question was because I don't want to argue (even though we did a little). I know of XHTML's pitfalls, and all we have to do is inform people of how to avoid them.

XHTML 1.0 is a dead end. Not using it isn't going to hold back the web. XHTML 2.0 is going to be pretty much an entirely new language.

Oh, and (7) Since XHTML isn't HTML, the HTML specific bits of CSS (such as little things like class selectors) aren't supposed to apply to it.

Oh well, it's all really a matter of opinion, so no real use arguing about it. And IE 7 is coming out in the not-too-distant future, so in a few years, when XHTML 2.0 isn't ready yet, we can enjoy the benefits of XHTML 1.x with most browsers supporting it.

The benefits of XHTML being of no use whatsoever to the vast majority of authors. Not really a lot of enjoyment there then.

Huh? You mean right now? Maybe, but I said in a few years, you could proabably use XHTML 1.x freely, when 2.0 won't be ready yet.

And the point of using XHTML in a few years time would be what? Mixed namespaces? How many authors have a use for MathML? What's wrong with sticking SVG in an external file?

... and you would still have browsers out there which didn't support it.

I, for one, am tired of making tag-soup, so XHTML is good for me there, and anyone else who is tired of the tag-soup. BTW, if you want to know what chudosok 2.1 is going to be like, you can check out the beta at http://www.chudosok.info/21 I'm quite sure it's not that horrible.

You can also make your own namespaces and stuff to use, plus plenty exist, so not only MathML users are going to use that feature. And XHTML is a little faster than HTML because XML rendering is easier on the UA. In a few years, the browsers that don't support XHTML will probably be used by >1% of internet users.

Just wondering, but are you like, totally against XHTML 1.x?

"Just wondering, but are you like, totally against XHTML 1.x?"
Yes!

There's nothing in xHtml that accually does anything for an author that's usefull. Getting rid of tagsoup? I don't think so, I can use as much tagsoup as I want int xHtml, accually, I can use a whole lot more tagsoup in xHtml 1.1, using those custom namespaces you mentioned.
Want to get rid of as much tagsoup as possible? Start validating your 4.01 strict documents, so that they're accually html 4.01 strict, instead of claiming the title and failing horribly.
Accually, you can validate 4.01 non-strict to get rid of your tag soup too.

I completely agree with dorward, you're only making it harder on your server by trying to serve non-xHtml browsers a different document, oh, and that would be pitfall number one, you'll have to code against at least two documents. To get back to the javascript problems, IE servers xHtml 1.1 as quirks html, introducing some nice javascript incompatibilities as well as CSS-troubles.

xHtml just brings so much more trouble and fixes nothing you couldn't already fix yourself, it's not worth the time to learn, wait for something usefull to come around, like 2.x

 Martin

Most articles that discourage the use of XHTML say that advanced authors can avoid the pitfalls, but these authors are very few, and those authors are all right with using XHTML, the people who write those articles don't discourage them. Those who want to join these, like me, are more than welcome to do so in my opinion, as long as they know what they're doing. I've studied all the XHTML 1.x stuff thouroghly, and I can get past the quirks of IE and all that with XHTML. Like, for example, IE won't render 1.1 when served as application/xml, you can only serve 1.0 to IE. If someone can handle these issues, let them. XHTML renders faster, BTW, cuz it's xml.

XHTML might be parsed faster - but browsers tend not to start rendering it before its all been parsed. That doesn't make much difference until you throw in the time it takes to transfer a document across the Internet. HTML renderers usually do incremental rendering. So while the entire document might be displayed sooner with XHTML, with HTML it seems faster to the user, and the user can start reading it sooner.

So, what would you say about the people who can actully handle xhtml?

As far as I know, the people that can handle xhtml are more rare than those who can get around the pitfalls of using html 4.01 strict. This is mainly because one only needs to validate a strict 4.01 document to make sure the syntax is correct while for using xHtml you have to validate the document (alright, the browsers handles this) and then test it accross the browsers that you're sniffing to serve a different header.

And if the only benefit of xHtml (so far it's the only one I've seen you give us) is a slightly faster rendering, I don't think it's really worth the trouble. So let's talk differences:

html 4.01 strict requires:
- proper validation, needs an external tool which is readily available.
pro's:
- All known browsers support it
- renders in strict mode
- scripts in strict mode
con's:
- Still allows you to serve invalid documents, validation is a seperate process.
- Not the latest technology

xHtml 1.1 requires:
- proper validation, any capable browser will do, or readily available external tools
- different mimetype header to service IE (request header)
- different doctype to service IE or it won't render nor script in strict mode
pro's:
- renders in strict mode
- scripts in strict mode
- can be handled by any xml parser for possible server-side modifications
- enforces valid xhtml structure
con's:
- requires serverside script to sniff browser acceptance
- breaks down when handled improperly

I've tried to be as objective as possible here, and, you should realise this, I've only just last week moved my own site back to html 4.01 strict because of just such a debate as this one...

Let me know if your missing anything in the pro's/con's or dissagree with them.

 Martin

html 4.01 strict:
- Not the latest technology

That's not a con. Latest doesn't mean greatest.

xHtml 1.1:
- different mimetype header to service IE (request header)

Using that different mimetype violates the specification
Its not just IE that you have to worry about. Lots of user agents do not support XHTML. Googlebot included.

- enforces valid xhtml structure

No it doesn't. It enforces well-formedness, not validity.

All right. I agree with most of what you said, but if someone knows how to avoid the pitfalls, then let him. Let's not argue anymore, let's let the person now decide what he wants to use.

another option would be to code your page in actual XML, and then use XSLT to convert it to HTML/CSS.  that way you get all the abilities of XML, but the layout of HTML/CSS.

Yes, that's an option, but you have to know what you're doing, since it can be rather complex. If you're an advanced user, you can go ahead.

As doward said -- "XHTML as XHTML is not supported by some major clients - e.g. GoogleBot and Internet Explorer. So its not very useful on the WWW."... Most "XHTML" sites are normally only HTML with a very strict code, served as "text/html" -- not as "application/xhtml+xml", which, as doward says, amongst others, Internet Explorer doesn't support. It is simply only really strict HTML code. But I recommend you to use this strict HTML, so-called "XHTML", code, as it is more widely supported by the browsers, as long as it is "text/html". And you can also proudly put the "Valid XHTML 1.0" button on your site!

HTML 4.01 is supported better, since the HTML Compatability Guidelines in Appendix C of the XHTML spec depend on browsers not implementing HTML correctly - and some get it right. Having ">" scattered around the output isn't fun.

And you can stick a Valid HTML 4.01 button on your site if you really want to.

http://www.cs.tut.fi/~jkorpela/html/validation.html#icon

We have a web application created in JSP. The setup is pretty complicated, and there are many small errors in the HTML code. The way everything is setup, it's difficult to track down the errors. When I posed the question I thought I was going to rebuild the complete application, start from scratch. The plans have changed, and now I'm partially rebuilding the site, using JSTL (JSP Standard Tag Library, an XML language, similar to XSLT) and XML/XSLT. The XSLT has all the HTML code, which keeps it very compact and clean. These JSTL-pages are included in the normal pages, so they are just a part of the page. The rest of the page is old code. In a few months I hope to find the time to convert that as well. But for the moment the code still has errors. So I'll leave it at HTML 4.01 loose for now.

But in the end I will probably choose HTML 4.01 strict. I know it would be possible to serve multiple formats depending on the browser, but that would probably mean creating different CSS stylesheets as well, and then it can get out of hand. The conversion also means that the CSS stylesheets have to be changed, but with the XSLT's it's probably going to be a lot easier to change the HTML to the needs of the layout, so I hope the CSS will be simpler as well.

(Btw, JSTL/XSLT rocks! It's a lot easier than I thought it would be.)

And I forgot to say: thanks for all your input. Some of the discussion was too much for me, but in the end I got the important parts I think.

One thing about CSS is I've never seen anyone use different stylesheets for XHTML and another when serving the XHTML as HTML. My sites will render 100% same in XHTML and HTML. So, the CSS shouldn't get in the way, whether or not you use XHTML.

God Bless.