XHTML vs HTML FAQ

[joejoe04]

AutisticCuckoo,

Thanks again, I really appreciate your feedback on this. You have changed my mind and I will now be using HTML instead for now. I remember reading the part about XHTML 2.0 not being backwards compatible, but for some reason I wasn't including that in my thought process.

[C. Ankerstjerne]

I repent my sins of the past, and am now using HTML 4.01 Strict until all browsers support XHTML served as application/XML, retroactively.

[markbrown4]

I know i've argued with Tommy about this before but i still must be missing something..

I prefer the XHTML validation rules over HTML,
I like the well-formedness of it,
I like the consistent casing.

Why do so many people here prefer to use HTML 4.01 where these rules are not followed?

Is that really the only difference? - I'm talking about both documents being sent as Content-type: text/html


Thanks,

[felgall]

You can follow exactly the same rules for HTML as you do for XHTML that is to be served as HTML except for the closing / in singleton tags. The only difference is that the validator will not pick up as many of the errors you have made in your HTML if you do that because the HTML validator is not applying all of those rules the way the XHTML validator does. The W3C standards are mostly written from the browser point of view as to what the browser should support and while the HTML standards cover about 30% of the standards you should be using to create decently coded and maintainable web pages the XHTML standards covers about 35% of the standards that a web developer ought to be following. For some of us this makes XHTML the better choice even though the pages will be served as HTML because the validator checks 35% of the standards we are following for us instead of only 30%. Most of the other standards that good web developers follow would not be able to be easily checked by a validation process anyway (eg. how can any validator know if you have selected the semantically correct tag for a given piece of content). The W3C tried to make too many changes all at once when they introduced XHTML 1.0 as what was really needed was the validation rules for which tags and closing tags are required to be there and similar things such as always quoting attribute values. The new HTML 5 standards that are now under development will need to include all of the well formed rules of XHTML 1.0 (apart from self closing) as the starting point if the proposal is to be at all worthwhile.

[AutisticCuckoo]

I prefer the XHTML validation rules over HTML,
I like the well-formedness of it,
I like the consistent casing.

Then, by all means, write XHTML markup. As long as you make sure that it works as XHTML (i.e., when served properly) it's fine. If it only works when served as HTML, then I'd say it's a harmful practice, though.

Why do so many people here prefer to use HTML 4.01 where these rules are not followed?

You can follow those rules in HTML, with the minor exception of the NET syntax (e.g., <br/>).
I can't answer for anyone else, but the reason I personally prefer HTML 4.01 to pretend-XHTML is that it's more honest. You are using HTML anyway, even if you pretend that it's XHTML. It feels 'dirty' to rely on browser bugs, but that's just me. YMMV.

You often hear that HTML allows for more 'sloppy' markup than XHTML, but that's not true. HTML's rules are more complicated, since they allow some tags to be omitted and even forbid some end tags. XML's rules are simpler and more consistent, but they're not compatible with HTML's rules. That's why you need to rely on browser bugs to make pretend-XHTML display properly as intended.

The reason for the alleged 'sloppiness' in HTML is that user agents try to recover from well-formedness errors, while XML parsers are required to abort when they encounter malformed XHTML.

Valid HTML and valid XHTML can both be parsed unambiguously to generate a DOM tree. You may choose to omit </p> tags in HTML, but the rules are crystal clear and there can be no confusion about where the paragraph ends. The </p> is unnecessary, but requiring its presence allows you to write far simpler parsers. But unless this consistent, well-formed markup is served as an application of XML, user agents cannot use that simple parser anyway. (Try omitting a </p> tag in your pretend-XHTML: it will work just as well in all browsers as long as you serve it as text/html, because it is HTML and follows those rules.)

If you prefer XML syntax, go ahead and use it. But no half measures! If you use XML syntax it must work as XML. As long as you're serving it as HTML, though, be aware that there are no technical benefits at all. It may not be 'harmful', but you gain nothing either (from a technical point of view).

[zcorpan]

The new HTML 5 standards that are now under development will need to include all of the well formed rules of XHTML 1.0 (apart from self closing) as the starting point if the proposal is to be at all worthwhile.

FWIW, HTML5 allows omitting tags and unquoted attribute values, just like all previous versions of HTML. It's a useful and harmless feature. Browsers support it fine.

HTML5 also allows "XHTML" syntax to be served as text/html (/> on void elements like BR, LINK, etc) and xmlns="http://www.w3.org/1999/xhtml" on the <html> tag. They don't do anything at all, they're just allowed to make migration from XHTML 1.0 to HTML5 easier.

There is also XHTML5 which is when you use it as XML (and serve it with an XML MIME type).

HTH,

[felgall]

If that is correct then there will no reason whatever for switching from XHTML 1.0 to HTML 5 unless someone builds a decent validator that reports errors for those tags that are allowed to be omitted but which should be included if you are coding correctly rather than validating to what browsers will accept but which is still sloppy coding.

[Raffles]

Well, one reason to switch over to HTML 5 would be to make use of the nice shiny new elements.

Which nobody will be able to really use until IE supports them in 2016.

[zcorpan]

felgall, if you mean "would be well-formed when parsed as XML" then you can just override the Content-Type and validate it as XHTML5. (If you're careful with what you're doing, you can have a document that is conforming HTML5 and XHTML5 at the same time; kinda like appendix C and XHTML 1.0.) I don't see any value whatsoever in doing so, but it is possible.

It is not "incorrect coding" to omit optional tags in HTML. They are optional because you're allowed to omit them. It's like saying omitting braces in one-line "if" statements in JavaScript is incorrect, or that omitting the semicolon after the last declaration in a ruleset in CSS is incorrect, etc. It's part of the language.

You're right that there is no point to switch to HTML5 just for the sake of it, but the reason is that you don't gain anything unless you actually use the new features it provides when they are implemented in browsers (some of which already are implemented). There is also an (X)HTML5 conformance checker, btw.

[felgall]

As I said before "Leaving out many of the 'optional' tags is poor coding practice because it makes the code harder to maintain when you are making changes at a later date". The XHTML validator is useful in this regard because those optional HTML tags are not optional in XHTML and the validator therefore tells you if you accidentally left one out so that you can add it in.

The W3C standards are targetted at the browser writers as to what their browsers should support. There are a lot of things in the HTML standards that browsers are required to treat as optional because too many people don't know how to markup their page properly and leave out a lot of the tags that really ought to be there to make the page easier to maintain at a later date. Sure you can leave out the optional tags and the browser will know where they go and add them for you but when you are altering the page at a later date you may not remember where the optional tags go and may totally stuff up your page layout by inserting something in the wrong place simply because you misremembered where the optional tag was supposed to be.

The W3C standards for HTML are about 30&#37; and the XHTML standards about 35% of the complete set of standards that someone writing web pages ought to be following. They are only 100% of the standards from the browser writer's viewpoint. One standard everyone should be following in order to make sure that their (X)HTML is going to be easier to maintain in the future is that optional tags should always be coded if the browser would need to determine where the tag would go if you leave it out.

[dotancohen]

Alright, I'm convinced. I'm switching my personal site to HTML 4.01 Strict (from XHTML Transitional), though the business site will remain XHTML Transitional.

[Andrew Millne]

Wow really opened my eyes this post. I have been using XHTML Strict for no other reason than I thought it was "The correct way". It seems I should be using HTML 4.01 STRICT.

I will however continue to use the well formed rules of XHTML as I feel it leads to better structure.

[AutisticCuckoo]

Andrew, I hope you don't intend to use XML-style well-formedness with an HTML 4.01 Strict doctype. That's not on.

By all means, include all optional end tags; I do that myself.
But for element types declared as EMPTY in the DTD, don't attempt to use the self-closing NET syntax (e.g., <br/>).

If you want to do that, stick with an XHTML 1.0 Strict doctype. You must make sure that the document still works when served as an application of XML, though.

[Andrew Millne]

yeah thanks Tommy I actually realised this myself this morning re-reading this topic. It seems I actually got carried away in the concept that I was wrong when in fact really I wasn't. I now understand the consequences of using the XHTML doctype as opposed to HTML 4.01 and understand why people should educate themselves of the differences. Thanks again for the excellent posts.

[Sumi]

Hi,

Just came across another article describing about HTML and XHTML.

http://webkit.org/blog/?p=68

[Sumi]

SitePoint is using forum software (vBulletin) and it's likely that it's not worth the trouble converting templates and scripts to make them generate HTML instead of XHTML. One definite advantage of XML markup is that its syntactic rules are much more consistent than those of HTML. That makes it easier to generate, as well as to parse.

If you follow all the guidelines in Appendix C of the XHTML 1.0 specification and make sure that your pages still work as intended when served as, e.g., application/xhtml+xml, there is no real harm in serving XHTML markup as text/html.

Validation is one thing, but you can write valid XHTML markup that will not work when served as an application of XML. That's why you need to verify this (as outlined in the FAQ). A document with XHTML markup that only works when served as text/html is a very bad and dangerous thing, in my opinion. That's when I agree with Ian Hickson: it's harmful.

Am so dumb I didn't even read this thread while posting the previous one

[Daun]

aha ,thanks !
great Tommy!

[fluffyland]

Everyone seems to think that the only thing that matters is the transmission of your content to the browser and whether the browser realises that it's xml or not.

I like to be able to parse my content as xml.
I like being able to transform it with xslt.
I like being able to mix in other data types with namespaces.

It doesn't seem to hurt serving it as text/html - it is text (not binary) and it's a kind of html.

[drhowarddrfine]

Well, one reason to switch over to HTML 5 would be to make use of the nice shiny new elements.

Which nobody will be able to really use until IE supports them in 2016.

IE won't be around then. Write it down.

[drhowarddrfine]

Everyone seems to think that the only thing that matters is the transmission of your content to the browser and whether the browser realises that it's xml or not.

I like to be able to parse my content as xml.
I like being able to transform it with xslt.
I like being able to mix in other data types with namespaces.

It doesn't seem to hurt serving it as text/html - it is text (not binary) and it's a kind of html.

**sigh**

[fluffyland]

Top argument there...

(trying to get my posts up to 25 so I can have a custom avatar :-)

[AutisticCuckoo]

I like to be able to parse my content as xml.
I like being able to transform it with xslt.
I like being able to mix in other data types with namespaces.

Then use XHTML. But you mustn't do any of the things you listed if it is served as text/html, since that specificies that it is HTML.

Serving XHTML as text/html is not harmful as such. Only pointless.

Writing purported XHTML documents that must be served as text/html to work is 'harmful', though.

[fluffyland]

My point is that *I* find it more convenient having my data in xhtml, the stuff that's not in databases that is (is there a forum on this site about not putting structured data in an RDBMS?).

There are people responding to this forum saying that now they're not going to put their material up as xml because some people are telling them that they *have* to serve it as application/xhtml+xml and that won't work in IE.

That sucks.

I don't think the message should be "don't use xhtml" it should be "validate your documents".

It all seems to have stemmed from Ian Hicksons blog and I don't agree with his arguments. (and yet people who like xhtml are told they've just "jumped on a bandwagon")

http://www.hixie.ch/advocacy/xhtml

1. Things go wrong if you don't do it properly - then do it right.

2. There are some things you can do that are valid xhtml that break browsers - then don't do them.

3. XML is case sensitive - use lower case.

4. Browsers don't support it consistently - they don't support *anything* consistently so you've got to test it anyway.

5. Some mythical fully compliant SGML parsing web client is justified in scattering ">"s all over you page - I don't think I've ever seen one and you'd be pretty stupid to build one now.

I'm not even sure there was a fully compliant SGML parser because the standard was so bad, that's *why* they created XML. If memory serves me correct everyone eventually took the standard to be "the way James Clark implemented it".

(I'll skip some 'cause I'm getting bored now)

6. You can use SGML tools instead of XML tools - there are XML parsers in pretty much every language ever invented (I'm sure someone's built one for INTERCAL by now) SGML not so much, good luck with your C program.

The bottom line is that properly authored xhtml works now in real browsers and you've got gazillions of tools that work on transforming, querying and mixing it up.

(I like iframes too :-)

[lajocar]

IE won't be around then. Write it down.

I think that IE will be around

[bangkok_knight]

Thanks people I thought I knew alot about xhtml but it turns out I am missing a lot here.