| SitePoint Sponsor |
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.Originally Posted by AutisticCuckoo
but they don't.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.
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.
Stephen J Chapman
javascriptexample.net, Book Reviews, follow me on Twitter
HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
<input name="html5" type="text" required pattern="^$">
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.
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).
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.
HTML is every bit as much of a W3C standard as XHTML, and the W3C validator validates HTML as well as XHTML.
Birnam wood is come to Dunsinane
i absolutely 100% agree, but it doesn't exist yet.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
now don't start bashing on people, the only people we bash on are Microsoft and w3c, as its mainly their problem.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 think felgall just explained it much better than i could.HTML is every bit as much of a W3C standard as XHTML, and the W3C validator validates HTML as well as XHTML.
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:
Activating Browser Modes with Doctype - Henri Sivonen's seminal resource.
W3C page on Serving XHTML 1.0 - XHTML & MIME types, 'Standards' vs 'Quirks' modes, etc.
W3C Content-Negotiation Techniques to serve XHTML as text/html and application/xhtml+xml
@jamesicus
thats some very professional looking post you got there
@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% valid xhtml w3c badges don't even suspect this mis-comprehension .
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).
Stephen J Chapman
javascriptexample.net, Book Reviews, follow me on Twitter
HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
<input name="html5" type="text" required pattern="^$">
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.
James
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.
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.
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.
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.
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.
Birnam wood is come to Dunsinane
It's not clear to me why this is so obvious... XSD is more expressive than DTDs but RELAX NG, Schematron and custom Java code is more expressive still.
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.
Simon Pieters
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.
Stephen J Chapman
javascriptexample.net, Book Reviews, follow me on Twitter
HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
<input name="html5" type="text" required pattern="^$">
that exactly matches my opinion.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.
as we are examining "why do people use xhtml for their html web pages", the above, offers some valid reasons.
true.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.
i agree with both of you,AutisticCuckoo
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.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.
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).
-just a reminder to keep it from changing subject.
For some great insight and history relating to this subject go to W3C Public Mailing List: XHTML 1.0, section C14 (2006) and browse that thread. I think the post I have selected as an entry point is on the cusp of this frequently very lively discussion.
James
Last edited by jamesicus; Jan 26, 2009 at 01:58. Reason: changed wording
new standard, new format so just use it. I don't think today someone is developing a site with html
Keep in mind developers call HTML just to refer to XHTML
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.
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.
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.
Birnam wood is come to Dunsinane
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.
James
i hope that runrunforest got some insight on the subject.AutisticCuckoo
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.runrunforest
Keep in mind developers call HTML just to refer to XHTML
hahaha, good one james.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.
so another reason would be to 'show off' that you can work with the bugs to produce results.
Lawlz, I do like your coins page though, to see an XHTML page sometimes... I bookmarked it somewhere around here...to "show off" that I can use it fairly well (ah vanity!) with its existing constraints;
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.
James
Last edited by jamesicus; Jan 26, 2009 at 10:22. Reason: added forgotten information
that is amazing. (any good examples of Quickie McSwitchy?)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.
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.
In PHP very basic and simple way...
PHP Code:if ( isset( $_SERVER['HTTP_ACCEPT'] ) && stripos( $_SERVER['HTTP_ACCEPT'], 'application/xhtml+xml' ) !== false ) {
header( 'content-type: application/xhtml+xml;charset=whatever-it-is' );
// XHTML stuff here...
} else {
// HTML stuff here
}
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,
and your code would serve it XHTML.Code:Accept: text/html, application/xhtml+xml;q=0
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.
Birnam wood is come to Dunsinane
Posting Permissions
Bookmarks