The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

You're right. Of course the should. But they shouldn't have to worry about that as they get started. They should first learn HTML properly. XHTML can come later, since it's not very useful after all. And it's not necessary for most of us, either.

Well no because many novices end up writing what they think is XHTML because of some misinformation that will have been fed to them in one way or other. I've seen in the past, novices starting off with XHTML. So IMO before they touch a byte of code they should learn why they don't need to be using XHTML (and why they should start off with good 'ole HTML 4), and to learn that, they need to know at the very least the basic difference between XHTML and HTML.

So IMO before they touch a byte of code they should learn why they don't need to be using XHTML (and why they should start off with good 'ole HTML 4), and to learn that, they need to know at the very least the basic difference between XHTML and HTML.

but they don't.

the beginners book "learn html/css the right way" (the book that got me interested in websites), teaches xhtml, and i think it does that for a reason, maybe to avoid confusion in markup (as html is more loose) and introduce them to W3C standards (and the validator, which is very helpful for newbs), although after they finish it, they should start expanding their knowledge (if they want to be more than just mediocre web designers) and move to html 4 as soon as possible, and maybe move back to xhtml for some "specific" projects that require the functionality of xhtml.

The biggest problem is that the W3C write the standards that the browsers are required to follow which makes allowance for a lot of bad coding practices particularly for HTML.

What we really need is an HTML validator that doesn't just check the page against the minimum standards that browsers need to follow but which also applies the standards that people writing web pages should be following in order to write quality consistent easy to maintain HTML. That means things like not leaving out certain tags just because the browser standard says browsers need to be able to handle their being missing etc. At the moment the closest to a decent HTML validator for web page writers that is well known is the XHTML validator from the W3C since XHTML doesn't allow for the sorts of sloppy coding that you shouldn't be using in a web page and will tell you when you left out tags which browsers are required to have as optional in HTML but which web page writers should consider to be mandatory in order to make their pages more consistent and more maintainable.

If a decent HTML validator for web page writers were available you'd probably find that a lot of people would switch from writing HTML with an XHTML doctype to using an HTML doctype and then using that new HTML validator to validate their pages.

What web browsers are required to accept in a web page is only a subset of the standards that any decent web page writers should be following.

I've seen in the past, novices starting off with XHTML. So IMO before they touch a byte of code they should learn why they don't need to be using XHTML (and why they should start off with good 'ole HTML 4), and to learn that, they need to know at the very least the basic difference between XHTML and HTML.

Okay, fair enough. I was thinking it might be enough to state that XHTML is a bad idea, without having to go into the details of why that is (until they have learned more and have a better chance of understanding the differences). But you're probably right.

Originally Posted by YuriKolovsky

the beginners book "learn html/css the right way" (the book that got me interested in websites), teaches xhtml, and i think it does that for a reason

I think the only reason is that some of the staff at SitePoint really like XHTML and don't want to admit that it's pointless. I don't it was something Ian insisted on (he's recently abandoned XHTML for honest HTML 4.01 Strict on Accessify).

Originally Posted by YuriKolovsky

maybe to avoid confusion in markup (as html is more loose)

No, it's not. It's exactly as strict as XHTML. The difference is that XML has more consistent rules. A valid document can always be parsed unambiguously, whether it's HTML or XHTML.

XML requires draconian error handling, though, while HTML doesn't say anything authoritative on that subject (something that will change with HTML5). And this is precisely why XML (including XHTML) is ill suited for web pages. It's not a good idea to hand-code XML, because a single mistakes prevents the page from rendering.

Originally Posted by YuriKolovsky

and introduce them to W3C standards (and the validator, which is very helpful for newbs)

HTML is every bit as much of a W3C standard as XHTML, and the W3C validator validates HTML as well as XHTML.

What we really need is an HTML validator that doesn't just check the page against the minimum standards that browsers need to follow but which also applies the standards that people writing web pages should be following in order to write quality consistent easy to maintain HTML

i absolutely 100&#37; agree, but it doesn't exist yet.

I think the only reason is that some of the staff at SitePoint really like XHTML and don't want to admit that it's pointless.

now don't start bashing on people, the only people we bash on are Microsoft and w3c, as its mainly their problem.

HTML is every bit as much of a W3C standard as XHTML, and the W3C validator validates HTML as well as XHTML.

i think felgall just explained it much better than i could.
html validator is of no help to the designer in comparison to the xhtml validator, in creating maintainable code.

But AutisticCuckoo is correct, unless you have a REAL reason for using XHTML, then it's pointless. So therefore even the beginner book you mentioned isn't really for novices, unless they aren't novices in HTML 4 and they have a REAL reason for wanting to learn XHTML. It's misleading - no wonder novices think XHTML is the latest standard or whatever.

I'm lucky because although I used to think XHTML was the 'latest way of writing HTML' I realised sometime ago that I was wrong in thinking that, and promptly switched over to HTML 4. I'm not a novice when it comes to writing HTML, but I am a novice when it comes to XHTML.

There are indeed numerous problems and pitfalls involved in producing XHTML 1.0 Web pages - particularly those composed in accordance with Appendix C of the W3C XHTML 1.0 Recommendation which are really HTML rather than XHTML documents. Practically all extant XHTML 1.0 pages are being composed in this manner. XHTML 1.0 documents should really be composed to provide XML functionality as prescribed by the Recommendation. W3C XHTML 1.0 Recommendation (Second Edition) prescribes the syntax, constructs and guidelines.

Web Authors wishing to produce optimally performing and conforming XHTML 1.0 Documents -- particularly those composed in accordance with Appendix C of the W3C XHTML 1.0 Recommendation -- should consult the following References and Resources before they embark on Web page production:

@Silver Firefly
i am saying that it is not bad, to first learn xhtml. (i can only judge by myself)
it is bad to think that xhtml works in internet explorer, and to treat it like html.

the original question was
why xhtml, if it doesn't even work in all browsers!!
and the solutions so far are, use xhtml specifically for browsers that support it, or not use it at all.
and the reason that most people use it is that it had a nifty xhtml validator handy, and it is like a new toy.

so it makes more sense to not use it at all if you are comfortable with your html writing skills, and unless you really need it and are prepared to do additional work for it.

p.s. i bet the people that have the 100&#37; valid xhtml w3c badges don't even suspect this mis-comprehension .

HTML is every bit as much of a W3C standard as XHTML, and the W3C validator validates HTML as well as XHTML.

Yes but the validators validate to what web browsers are supposed to support rather than to what makes good coding practice for those writing the web pages.

What is currently missing is an HTML validator aimed at web page writers. At the moment the closest available validator that checks HTML for good coding practices such as always including closing tags except on standalone tags and always including "optional" tags such as <head> <body> and <thead> is the HTML 1.0 version of the validator. That isn't what that validator is intended for but it still comes closest to providing proper validation of pages to the standards that web page authors should be using when writing their HTML. Ideally you'd initially use an XHTML doctype and validate the page getting rid of all the errors. You'd then change the doctype to HTML and validate again. Some people just skip this last step and end up with what they know perfectly well is HTML but which still has the XHTML doctype they used for the validation.

The way to get rid of all the pages with XHTML doctypes that are there for that reason all that would be required is for someone to release a decent HTML validator that validates HTML for appropriate coding standards that are at least as good as you get from the XHTML validator (an equivalent to the JSLint validator that is available for JavaScript that tells you about all the things in your code that might still work but which are still bad coding practice). Once there is no longer a need to declare HTML pages as XHTML just to get access to a decent validator there will be no reason for using "pretend" XHTML any more (unless there is some other legitimate reason for doing so that I have never come across).

.......... a person CAN create a valid and working document in xhtml that works bug free in text/html mime type, but what is the point in achieving the miraculous achievement? feeling of self accomplishment? wordpress? not exactly practical when creating a world wide website, in my opinion.

There are now several implementations and facilities that employ XHTML composed and served as application/xhtml+xml for optimal use, but which provide for serving as text/xml (employing internally linked XML data output). W3C Semantic Web implementations (such as XHTML+RDFa, GRDDL, FOAF, etc.) started off only permitting documents served as application/xhtml+xml but now permits them served as text/html. Blog implementations often follow this path faciltating RSS/Atom feeds via internal links. Actually, XHTML 1.0 Web pages served as text/htm have become commonplace (including numerous W3C pages) -- it has become almost the lingua franca of the WWW. Of course, as has been so often emphasized in the course of this discussion, the vast majority of extant Web pages would be best composed and served IAW HTML 4.01 specifications -- that is what I personally do, except for those I use as exemplars or for the Semantic Web.

Of course, XHTML Markup should really be checked using a XML Schema Validator (the W3C Markup Validator is SGML based). Besides precise Markup Validation, a well-formedness report is rendered. It also checks some of the HTML compatibility guidelines for XHTML pages served as text/html.

BTW, anyone interested in having a voice in the operation and function of the W3C Markup Validators (or with specific questions relating thereto) will find a welcome (after subscribing) at: W3C Validator Public Mailing list. I used to participate regularly (still receive messages) until I "retired" a couple of years ago.

Yes but the validators validate to what web browsers are supposed to support rather than to what makes good coding practice for those writing the web pages.

No. A validator's task is to verify that the code complies with the rules. Nothing more. It should be objective, not subjective. What you're asking for is a lint checker for HTML. Yes, that would be useful, but it's a completely different beast from a validator.

As an analogy, a court of law should punish a man for beating his wife, which is illegal (at least in my country). But it shouldn't punish him for referring to her as 'the old cow' behind her back. That's something that social etiquette (i.e., peer pressure) should take care of.

Originally Posted by felgall

good coding practices such as always including closing tags except on standalone tags and always including "optional" tags such as <head> <body> and <thead>

What constitutes good coding practice varies with fashion. What you described is considered god practice today, but 15 years ago it was good practice to omit everything that wasn't absolutely necessary (to save bandwidth). It's subjective, not objective.

Originally Posted by jamesicus

There are now several implementations and facilities that employ XHTML composed and served as application/xhtml+xml for optimal use, but which provide for serving as text/xml (employing internally linked XML data output).

The MIME type only needs to state that it's an application of XML. Serving something as application/xhtml+xml doesn't, on its own, make anything XHTML. It's the combination of an XML MIME type and the proper XML namespace declaration that makes it XHTML.

An XHTML document can be served as application/xhtml+xml, application/xml or text/xml. The latter is not recommended, due to the weird rules it infers for character encoding.

Originally Posted by jamesicus

W3C Semantic Web implementations (such as XHTML+RDFa, GRDDL, FOAF, etc.) started off only permitting documents served as application/xhtml+xml but now permits them served as text/html.

I haven't looked at those, but if they can be served as text/html they cannot contain anything that doesn't follow HTML's syntactic rules. A user agent that receives a text/html MIME type has to use its HTML parser, not its XML parser, to process the document.

Originally Posted by jamesicus

Actually, XHTML 1.0 Web pages served as text/htm have become commonplace (including numerous W3C pages) -- it has become almost the lingua franca of the WWW.

Yes, unfortunately. But not a single one of them can use any XML features that might motivate the use of XHTML. Each one could use an HTML 4.01 doctype declaration without the slightest difference in the outcome, because that's what browsers treat them as anyway.

It uses OpenSP (an SGML parser) to do validation against an SGML DTD or XML DTD, and then it reparses with an XML parser (without validation but still fetching the external subset for infoset augmentation) to find well-formedness errors that slipped through OpenSP.

What you're asking for is a lint checker for HTML. Yes, that would be useful, but it's a completely different beast from a validator..

Whether you call it a validator or a lint checker doesn't change the fact that the closest that we have available at the moment is the XHTML 1.0 validator - and that is one reason why a lot of people use a XHTML 1.0 doctype for their HTML 4.01 web pages.

Provision of such a tool specifically for this purpose would remove the reason for why a lot of the pages that have been created with an XHTML doctype but which are served as HTML by people who know what the difference between HTML and XHTML is. It would also remove the reason why a lot of books teach XHTML first rather than HTML.

felgall
Provision of such a tool specifically for this purpose would remove the reason for why a lot of the pages that have been created with an XHTML doctype but which are served as HTML by people who know what the difference between HTML and XHTML is. It would also remove the reason why a lot of books teach XHTML first rather than HTML.

that exactly matches my opinion.
as we are examining "why do people use xhtml for their html web pages", the above, offers some valid reasons.

AutisticCuckoo
The MIME type only needs to state that it's an application of XML. Serving something as application/xhtml+xml doesn't, on its own, make anything XHTML. It's the combination of an XML MIME type and the proper XML namespace declaration that makes it XHTML.

true.

AutisticCuckoo

Originally Posted by jamesicus
Actually, XHTML 1.0 Web pages served as text/htm have become commonplace (including numerous W3C pages) -- it has become almost the lingua franca of the WWW.

Yes, unfortunately. But not a single one of them can use any XML features that might motivate the use of XHTML. Each one could use an HTML 4.01 doctype declaration without the slightest difference in the outcome, because that's what browsers treat them as anyway.

i agree with both of you,
that is what got me thinking about xhtml.

in this thread were exploring the reasons on why is xhtml used for pages that would be better served as html 4.0, and why xhtml is used at all, as its not supported in ie (a large audience).

It's not 'new'. It's about the same age as HTML 4.01. XHTML 1.0 doesn't replace HTML 4.01; it's just a parallel standard for those few who need XML features on a web page.

Originally Posted by runrunforest

I don't think today someone is developing a site with html

You are wrong there. I do it, and any self-respecting developer does it, unless he or she is forced to use pretend-XHTML because of a template system or CMS.

And 99.999% of those who think they use XHTML are also developing their sites with HTML, since they serve their pages as text/html. It's invalid and relies on browser bugs, but it's HTML, not XHTML.

Originally Posted by runrunforest

Keep in mind developers call HTML just to refer to XHTML

Only those who don't know what they're doing. XHTML is not HTML; it only defines the same semantics as HTML. If you want to call XHTML anything other than XHTML, you should call it XML, because that's what it is.

.......... in this thread were exploring the reasons on why is xhtml used for pages that would be better served as html 4.0, and why xhtml is used at all, as its not supported in ie (a large audience).

-just a reminder to keep it from changing subject.

Thank you for the reminder, YuriKolovsky. I apologise for straying from your premise on occasion and failing to answer your question directly. I will do so now, citing personal reasons and without speculating on the motivation of others:

The reason I employ XHTML (in any "flavor") is so that I can construct Web pages illustrating the perils and pitfalls in using it in its present forms; to "show off" that I can use it fairly well (ah vanity!) with its existing constraints; so that I can extract and manipulate existing online data using W3C prescribed Semantic Web techniques and methodologies.

Only those who don't know what they're doing. XHTML is not HTML; it only defines the same semantics as HTML. If you want to call XHTML anything other than XHTML, you should call it XML, because that's what it is.

i hope that runrunforest got some insight on the subject.

jamesicus
The reason I employ XHTML (in any "flavor") is so that I can construct Web pages illustrating the perils and pitfalls in using it in its present forms; to "show off" that I can use it fairly well (ah vanity!) with its existing constraints; so that I can extract and manipulate existing online data using W3C prescribed Semantic Web techniques and methodologies.

hahaha, good one james.
so another reason would be to 'show off' that you can work with the bugs to produce results.

to "show off" that I can use it fairly well (ah vanity!) with its existing constraints;

Lawlz, I do like your coins page though, to see an XHTML page sometimes... I bookmarked it somewhere around here...

Once someone on DP stumbled upon a World Of Warcraft site and they had this cool two-layer CSS effect (a hole with a background) and looking at the source, I was surprised to see XHTML sent properly... even though my colleague had just shown me in IE7. They were doing the Quickie McSwitchy for IE. I didn't look to see if they were doing any XML stuff, but remembered the Doctype.

Why thank you, Stomme poes. The only reason they are now XHTML 1.0 (actually, of course, HTML) instead of the original HTML 4.01 is because we are building a large online Ancient Roman Coins reference library and we are using RDFa in XHTML to extract and transform all of the coin data from our Web pages so that it will be readily available to our research and collecting community.

Once someone on DP stumbled upon a World Of Warcraft site and they had this cool two-layer CSS effect (a hole with a background) and looking at the source, I was surprised to see XHTML sent properly... even though my colleague had just shown me in IE7. They were doing the Quickie McSwitchy for IE. I didn't look to see if they were doing any XML stuff, but remembered the Doctype.

that is amazing. (any good examples of Quickie McSwitchy?)

i think that would be the perfect way of using xhtml on one of your favorite websites (personal favorites), the one you want to be cutting edge, the one you find yourself polishing over and over again.

That will probably work just fine, but if one were to be pedantic it's too simplistic an approach since it doesn't take quality values (q values) into account. In theory, a user agent could send a header like this,

Code:

Accept: text/html, application/xhtml+xml;q=0

and your code would serve it XHTML.

If you search for 'content negotiation' on Google you'll find an article I wrote many moons ago (it's currently at #6 on google.com). It explains how to take q values into account and do content negotiation with PHP.