Why XHTML?
This is a well-discussed and very important topic. Personally, presently I write XHTML for my web interface code, but lately I’ve started to stagger in my standpoint. For normal general web page design, what’s the gain? If you don’t extend the code with namespaces, use MathML, have your own DTDs and so on, why would you want to use XHTML?
Many people answer that question with: “It makes me write leaner code, code that has to validate and be more semantic correct”. Martin 
wrote a post recently why he uses XHTML (unfortunately, it’s in Swedish).
But I don’t agree with the argument that it has to be XHTML to achieve that particular goal. I think it’s more of a developer standpoint than using XHTML. If you’re really dedicated to what you do, you use the correct tags for the correct purposes (H1 for headings etc), you write as lean and minimal code as possible and you close all optional tags like LI, P and so on.
Basically, you can live up to that with using the HTML 4 Strict Doctype, and separating content (HTML) from layout/look (CSS) and interactivity (JavaScript).
Another reason people use it is that they might think it makes them better programmers, that they code ‘the real deal’. It might also be as a selling point, for the project manager or his/her like, to tell the customer that: “Yes, we know what we do, we code XHTML”.
But, unfortunately, very few do it all the way. As mentioned in Anne‘s Quick quide to XHTML about Evan Goer’s test, 89% of the web sites tested didn’t validate and 99% used the incorrect MIME type!
Which leads to the MIME type issue. In a very talked-about piece, Ian Hickson writes that if you use XHTML it should be delivered as application/xhtml+xml (which, surprise, Internet Explorer doesn’t support) to the web browser, otherwise it will be perceived as ‘tag soup’ (however, not everyone agrees that it should be called ‘tag soup’). But what has happened is that people have gone to such length that they use something called content negotiation, which basically boils down to serving XHTML as application/xhtml+xml to those web browsers who support it, and HTML 4 as text/html to those who don’t.
When you deliver XHTML as application/xhtml+xml to a browser that supports it, it won’t even render the page if it’s incorrect, but instead throw an error. Generally, I think this is a good thing that forces the developer to write correct code. Alas, speaking from my point of view, working in projects where Content Management Systems don’t deliver correct XHTML, where the .NET Framework doesn’t deliver correct XHTML etc, serving it as application/xhtml+xml is impossible for me.
Yes, Content Management System manufacturers are getting more aware of this, ASP.NET 2.0 is supposed to deliver XHTML the way it should be delivered, but it’s still a long way ahead in the future.
So what are my (and many other developers’) options? To deliver XHTML that doesn’t validate (although the errors might be minor/make no difference to how it will be rendered) as text/html, or should we deliver plain old HTML?
One point is also that this will not affect the end users, as long as you write valid code in its context, be it XHTML or HTML.
An interesting sidenote to this is that MSN Search serves valid XHTML 1.0 Strict which validates, while Google serves a non-Doctype page which generates 242 errors…
Conclusively, to go back to my initial question: why use XHTML if I only use it for standard HTML? Why go through the hassle if I don’t use any of the XHTML-specific features?
Anne brought up an interesting thing from Mozilla’s Web Author FAQ about how to serve HTML (and the thing that Mozilla, nor any other browser, loads XHTML incrementally, as opposed to HTML), and he comes to the conclusion that one should switch to HTML.
Also, Tommy made the statement a couple of weeks ago that XHTML Is Dead.
And these are two very talented persons that just don’t believe in XHTML anymore, and that saddens me and makes me think:
Are they right? Should I go back to writing HTML?
PS. Let me know what you think! Is XHTML or HTML the way to go? Write a comment and I’ll send you an invitation to use Google’s Gmail service (2 GB inbox(!), POP3 access etc). DS.
I can see a possible advantage of using XHTML if you have dynamically generated pages. Outputting well-formed X(HT)ML is slightly easier than outputting valid HTML, since you don't have to make exceptions for those few element types that cannot have an end tag in HTML. Very minor point, though. 🙂
Content negotiation (and, worse, the much more common content type negotiation) is silly, really. I say that although I do it myself, at the moment. If the content can be converted to — or at least interpreted as — HTML, you could probably use HTML in the first place. If you really want to use XHTML, though, and still cater to old browsers that don't support application/xhtml+xml, it's one way of doing it.
One thing I don't approve of, however, is what you said about the .NET framework not generating well-formed XHTML, forcing you to serve it as text/html. If you cannot guarantee well-formed markup, you must not use X(HT)ML! HTML 4.01 is the most recent standard that is well supported by browsers. There's nothing wrong with using that until real XHTML can replace it. 🙂 In my oh-so-humble opinion, of course.
Tommy,
Thanks for your insightful comment!
The key phrase in your comment is "If you cannot guarantee well-formed markup, you must not use X(HT)ML!".
That's what I'm going for. Unfortunately, usually I can't do that in my day to day work. And even if I could, why use XHTML if I don't make usage of the extra features it offers?
I vote for XHTML even though the page is served with the MIME-type text/html or even if the validation has some errors. Why?
The reason is that the application/webpages we develope needs to be forwardcompatible. A webpage is not rewritten every second year and the merge into right MIME-type when it´s time – will be easier. The developers and companies you work for will also incorporate the understanding of xhtml nature and it will not be a chock for them when it´s time for the change.
First, I'd like to say that I agree that XHTML is a good thing
in the sense that developers need to learn how to code (X)HTML properly
(or should I say strict?).
But I'm not sure if I'd call XHTML 1 forward compatible, since XHTML 2 will NOT be backwards compatible with XHTML 1.
Regarding
sending XHTML as text/html, especially with validating errors, is not
an option for me. If I'd do that, it feels like I'm a fake in my
profession, that I claim to do the right thing, but then I don't go all
the way.
Kind of like trying to do something that is over my head and I can't do it a 100%.
Just to even out the discussion, Tantek is pro-XHTML,
and actually wrote a post a bit more than a year ago, also titled Why
XHTML? (I didn't know about this post before I posted mine).
What to code, what code…
XHTML or HTML?
I understand what you mean, but there will be several years from now until enought amount of browsers will understand XHTML 2.0. As IE is so slow to implement w3c standard, I suppose there will be a gap with about 5 years where we will have IE understanding XHTML documents with the right MIME-type, until XHTML 2.0 is understod.
I don´t think it is "fake" to send XHTML as text/html. There will be a time when we can send the right MIME-type and let us code for the future. It gives the companies and there developers the knowledge about where the Internet is aheading -> XML.
Well, it's a tough question…
For people that feel that way, coding XHTML, using content negotiation etc is the way to go.
But for me, sending (in some cases) invalid XHTML as text/html doesn't sound like a good option.
Sending XHTML as text/html is a temporary workaround for older browsers. If you can't (or don't want to) do content negotiation or, at least, content type negotiation, you can still serve it as text/html to all browsers as long as you follow the compatibility guidelines in Appendix C of the XHTML 1.0 specification.
However … even if you send it as text/html for now, it must still be correct XHTML. You should, at any time, be able to switch the media type over to application/xhtml+xml and everything should still work. If you cannot do that, you are not ready for XHTML, but should stick to HTML.
Using XHTML along with HTML-only practices that require that it be served as text/html is outright silly. I've seen people who use an XHTML doctype, serve it as text/html, and use document.write() etc., and still claim that they are "stricter" than HTML and that they are "future compatible".
I'll say this again: while serving XHTML as text/html may be acceptable during a transitional period, it must still work when served as real XHTML. If not, there is absolutely no point in using an XHTML doctype. None.
Tommy,
I've also read the Appendix C of the XHTML 1.0 specification, and I totally agree with you.
For now, I think I can overlook sending XHTML as text/html as long as I follow above mentioned guidelines.
However, if using XHTML, it has to validate. What's the point otherwise?
To have almost-validating XHTML just for the purpose of using it and for educating other developers is, for me, not acceptable.
Well I'm not trying to start any flame wars here or anyting – but… 😉
I would like to pitch in my two favourite cents for y'all to ponder for a while…
Why not start asking the question the other way around – ie. ask yourselves the question: Why not XHTML – and see where you'll end up when you objectively analyse the answers you get?
I mean – Call upp http://w3.org/TR/html and you get a fresh copy of the XHTML 1.0 recommendation…
Appendix C is alive and kicking and people seems to slowly get the message…
XHTML roughly seems to equal web standards compliance in many corporate minds (i.e. amongst the moneypeople) if you believe some of the growing amount of hype that surrounds each new commercial "CSS-redesign"
Support for "XML features" seems to be growing with each new browser release.
and so on…
Think about it 😉
I recently wrote about it as well. I agreed with the fact that from a technological point of view XHTML isn't very promising these days, but was disagreeing with the advocacy of not using XHTML.
XHTML as a brand serves a 'devine' (if you'd like to call it like that) purpose. It brings people closer to the wild and woolly world of semantics, CSS and improved accessibility.
jarvklo,
Not taken as flaming at all, which I'm not really interested in. I prefer a mature discussion and argumenting without getting an overly heated discussion.
> ask yourselves the question: Why not XHTML
Well, that's the question, isn't it…? 🙂
I needed to sum it up and get some knowing people to comment it, to get a perspective of it!
> XHTML roughly seems to equal web standards compliance in many corporate minds
Oh, definitely! I've noticed this seems to spread more and more too.
jeroen,
I just read your post about XHTML and the thing that got to me was the last paragraph:"You and me know how to write good markup in HTML4. However, the inexperienced authors often do not…"
I
think that is a very important point, because if we were to avoid XHTML
and code everything in HTML 4 it would probably open up a floodgate of
nasty HTML, since more things would pass the validation.
So, to sum all of this up:
While
we might not really take advantage of everything XHTML has to offer,
while we might not always serve it as application/xhtml+xml, as long as
we follow the Appendix C HTML Compatibility guidelines
when serving it as text/html and make sure our code validates, it's
better from a semantic, correct coding, future XML thinking and
business standpoint.
Is this the general consensus?
Why not XHTML?
Because of SHORTTAG YES (http://www.w3.org/TR/REC-html40/sgml/sgmldecl.html)
The fact that browsers did not implement it is a poor excuse.
I've always been strongly against serving content as application/xhtml+xml on a business site. The margin for error is too big and the price of errors is not justifiable.
Personally,
I prefer XHTML. I try to get my code to validate as much as possible,
but if it fails to validate 100% I know why it is so, and I just move
on—I don't get stuck on it.
>Why not XHTML
Really the question is why not xhtml served as html.
Because it is no better in any way whatsoever than HTML 4 coded as described in this article . Anything about "temporary", "forward-compatible", "better standards", "better structured", etc., is an excuse or a lie.
Because it breaks many basic javascripts.
Because it is apparently slower to display in Mozilla.
Because it has a few annoying restrictions (target and such).
Because I personally can't figure out how to get my editor (homesite+) to do xhtml tags unless the page I'm working on actually has the doctype on it, which usually isn't the case with dynamic sites.
The only reason to use xhtml served as xhtml is if it is displayed faster than html 4, but no one to my knowledge has yet demonstrated that to be the case. But I still would not use xhtml served as xhtml because one error shuts down your website.
I use XHTML simply because then any ol' HTML and XML parser can read my files/website. There's more and more XML parsers out there and it's relatively easy for someone to make a new one.
If I made HTML pages, it would automatically be unreadable by every XML parser out there. Whereas XHTML (tho it's non-proper HTML) is actually readable by a huge majority of HTML parsers because they're all so soft on errors.
I cannot and will not count on an XML parser to be soft on errors. It would be silly to.
So the question I answer to myself is… do I want to cut out a load of modern day parsers (and future ones) that could crawl my site or do I just want to limit myself to a select group of parsers?
It's similar to browser checking or object checking. Which is smarter? Object checking. Why? Because otherwise you're always updating, to keep up with the changes.
Milan,
Good to see you here!
One important thing you mention in your article is:
"ASP.NET isn’t ready yet to produce markup that can be served as XML with the application/xhtml+xml content type."
And this is a pretty big issue, lots of people develop with the .NET Framework (I was musing a little about this in XHTML and its value. The comments are in Swedish, I'm afraid).
But
with how to serve XHTML aside, what you mention is a big question:
whether it's ok or not to serve XHTML with a few (minor) validation
errors, if you know about them.If you write XHTML and serve it as
text/html, should you automatically be able to switch to serving it as
application/xhtml+xml and it will work (as Tommy thinks, stated above),
or is it ok to have minor validation errors until .NET/your Content
Management System is ready for it, but still deliver XHTML?
> The only reason to use xhtml served as xhtml is if it is displayed faster than html 4, but no one to my knowledge has yet demonstrated that to be the case. But I still would not use xhtml served as xhtml because one error shuts down your website.
One reason might be that you want to be so strict about your code that it has to validate, that it shouldn't be allowed to be rendered if it's not valid.
> So the question I answer to myself is… do I want to cut out a load of modern day parsers (and future ones) that could crawl my site or do I just want to limit myself to a select group of parsers?
Of course you want to be as future compatible as possible, but it might also be a business decision. If you have a web site, intranet etc and your target audience will only use web browsers on a computer (PC, mac and so on), taking the extra time to deliver XHTML the right way may not be economically ok within your project.
> It's similar to browser checking or object checking. Which is smarter? Object checking. Why? Because otherwise you're always updating, to keep up with the changes.
Object checking is definitely the way you want to go, but there are always cases where you need to cater to browser specific bugs as well (for instance, where it claims to support something according to object checking, but then doesn't/has buggy support for it).
"Why not XHTML"
Unless you can guarantee well-formed markup, you must not use XHTML. It doesn't have to be valid, necessarily, but it absolutely must be well-formed.
As Rimantas said, the fact that HTML specifies SHORTTAG YES should be a good reason to stay away from XHTML-P (XHTML-pretend, served as text/html) as well.
I'm astonished when people say that they serve their "XHTML" as text/html, because the error handling is too strict when served as application/xhtml+xml. If you produce sloppy code that doesn't even pass a simple well-formedness check, you are definitely not ready to use X(HT)ML.
Why are people so hell-bent on using XHTML markup, but so reluctant to fulfill all the requirements?
You should have a FxCop tool for best practice analyze of UI coding! 🙂
Tommy,
> If you produce sloppy code that doesn't even pass a simple well-formedness check, you are definitely not ready to use X(HT)ML.
I agree that you preferably shouldn't use XHTML if you can't have it well-formed.
However, like you mentioned "It doesn't have to be valid…", does that mean that you think it's ok to serve a XHTML page as text/html (following above-mentioned Appendix C guidelines, of course) with minor validation errors such as a name attribute on a FORM tag, an input type="hidden" and a language attribute on a script tag (these examples are the most common automatically generated from the .NET Framework)?
> Why are people so hell-bent on using XHTML markup, but so reluctant to fulfill all the requirements?
This is just my perception, but I don't think people are intentionally reluctant to fulfill the requirements, I think that circumstances they can't control might do that.
But they still feel that the advantages of using XHTML outweighs minor validation errors (that doesn't affect the well-formedness), and that it is ok for some refactoring to take place if/when, later on, switching to serving it as application/xhtml+xml.
Also, it might be important from a business point of view: "XHTML is what is getting companies to become aware of Web Standards. Not HTML." from Faruk Ates The case for XHTML.
Robert,
I think that sums it up very well! Not sure if it is the general consensus, but it is my consensus. 😉
As I described in my original entry — I'll never drop XHTML as a brand, even though I am barely/not using XHTML's technological advantages at all.
Perhaps XHTML as the brand is decieving and all, but right now it seems to be the lowest level of entry to 'the other side' for the lesser informed authors. They all know HTML (sort of)..
As we know an XHTML document must be a well-formed XML document but not necessarily Valid.
For a brief period of time, i.e. a couple of days I had about three occurrences of some files I had edited that were XHTML served as application/xhtml+xml that were well-formed though not validated – as I forgot – which was semi-embarrassing even though obviously they displayed correctly.
Why quite a few people don't make use of the eXtensibility is because even if they did for the general public who uses MS Explorer you end up having to compromise.
From a practical point of view: what's the difference? I mean, i learned how to build sites from sites like alistapart and zeldmans book dwws. I know how to use css and seperate content from presentation. The only thing I knew about doctypes was that that was the stuff that goes at the top of the page, so-to-speak. Only lately it seems everybody is screaming it's soo bad and evil to put an xhtml-doctype (served as text) at the top op your pages. But the only thing I know is that it doesn't make any difference for my websites if I put an html or xhtml type up there. The only thing I must do if i would like to change the xhtml to html is get rid of the closing slashes in the img and br tags, isn't it? So, I understand xhtml served as text isn't real xhtml, but for a 'normal' (quotes!) website, does it matter?
Well, that's what the whole discussion here is about. :-)Is it worth it? What are the advantages of XHTML over HTML etc?
Doctypes
matter in the sense that they trigger different rendering modes in web
browsers: a strict HTML 4, strict XHTML 1.0 or XHTML 1.1 doctype
triggers strict rendering, XHTML 1.0 Transitional triggers Almost
Standards Mode in Mozilla and the other ones (or lack of) triggers
Quirks mode.Read more about that here.
XHTML
is a little more than just closing every tag, it comes to allowed
attributes etc (and, of course, the possibility for other
usage/extensions such as namespaces, MathML and so on).
There's an excellent article about developing with web standards over at 456bereastreet.com.
Robert, yes I understand it's a bit more then just closing tags! (ok, my comment was a little oversimplified 😉 What I was trying to say is that I don't know any different than to code in xhtml. If I wanted to change the doctype to html, I would have to go to (w3)school again to learn how to code properly in html, so-to-speak. Or could I just change my xhtml-strict for html-strict without touching my code? And then, what would be the difference?
The rendering you mention is indeed something I have experienced. With websites I made I noticed that my css worked best if I used the xhtml1.0 strict type.
But, this is an interesting discussion, and as I am no expert on this area, very educative.
I can understand the question: "is it worth it, what are the advantages of xhtml over html?"
But for me, and maybe for a lot of others, the question is also: is it worth the effort to change back xhtml to html?
Matthijs,
I didn't want to come off as condescending, just maybe over-explanatory. 🙂
You raise some interesting questions in your comment:
> Or could I just change my xhtml-strict for html-strict without touching my code?
I may go out on a limb here, but to achieve that, all you (should) have to do is to remove the '/' closing of tags, as for such tags as LINK, META, BR etc.
Remove the namespaces in the HTML element.
This assumes that you've only used XHTML as normal HTML for layout purposes.
> is it worth the effort to change back xhtml to html?
This situation is a bit different, it's normally teaching how to do it the other way around! 🙂
However, from my point of view, as long as your XHTML validates, is according to the above-mentioned Appendix C and works fine for you, I see no need to switching back just for the sake of it.
But if it doesn't validate or if you have other problems, switching back to strict HTML 4 and doing what I mentioned in the answer above should do the trick.
> But, this is an interesting discussion, and as I am no expert on this area, very educative.
Thank you, I hope it's a giving topic and discussion!
Also, send me an e-mail at robnyman@gmail.com so I can send you an invitation to Gmail, as promised in the post.
One of the advantages of validated mark-up is that you're not relying on browser error correction. If you send XHTML as text/html (ensuring that the code will be parsed as HTML rather than as XHTML) you eliminate that advantage, you're sending invalid HTML (since valid XHTML is *not* valid HTML) to browsers and thus are relying on their error correction to sort it out.
You could send the XHTML as application/xhtml+xml but that has its own problems (lack of incremental loading in Gecko browsers is a pretty major one).
So I'd say there is no real world advantage to XHTML but plenty of disadvantages.
> does that mean that you think it's ok to serve…
I don't think I'd use the word "OK", but at least it's "acceptable". As Robert Wellock said, the only requirement for XML is that it's well-formed. Validation is optional. Of course, you lose the right to be upset if things don't work if you don't have a valid document. 🙂
> I don't think people are intentionally reluctant to fulfill the requirements…
There are quite a few who complain that Mozilla et al throw up the Yellow Screen of Death just because they've forgotten to close one of their nested TABLEs, or because they can't be bothered to encode ampersands properly in their URLs. So they send it as text/html and think that they are still using XHTML and are really future compatible. 🙂
> From a practical point of view: what's the difference?
Matthijs, there are some major differences between HTML and XHTML served as application/xhtml+xml. The latter enforces well-formedness requirements; it requires the right XML namespace for the root element; tags, attributes and CSS selectors become case-sensitive; you cannot hide script code or CSS rules within SGML comments anymore; you must use DOM functions (the namespace-aware versions, like createElementNS) instead of document.write() or document.myElement.innerHTML.
XHTML may look a lot like HTML, but it's really XML with some built-in semantics that browsers are familiar with. Don't be fooled by the similarities; they are very different beasts. Also, with properly-served XHTML you can use XML features like incorporating markup from other XML namespaces (e.g. SVG or MathML).
Robert, this has been an awesome discussion so far! I appreciate insightful comments.
I'm a very pragmatic person. I write code each and every day. To me the question of whether to engage in content negotiation boils down to the question: "Is it going to affect my business?" I'm not trying to be selfish here, really. I'm trying to be reasonable. I'm a very meticulous person, but I have my sane limits.
My preference is XHTML 1.0 served as text/html.
I choose XHTML because it introduces at least a little bit of discipline to this HTML chaos. I'd choose a strongly-typed language over a loosely-typed one any day of the week. XHTML is somewhat closer to this paradigm than plain vanilla HTML with a very lax spec.
I also choose the text/html MIME type because the true XML ones aren't supported that well. User clients (browsers) can't deal with even slight parsing slips in a nice enough way. This is where I see pragmatism: your business gets hurt… for a noble cause of code purity?
Psssttt, Anne, feel free to disagree. 🙂 I know you do, but I develop enterprise software and there's no way in hell all 100% elements in a large product close or nest properly. That's just the circle of life.
Oh well – I still don't get it…
Yes – I know the academiae.
Yes – I know all the implications of sending XHTML as text/html to ancient browsers.
Yes – I am fully aware of the SGML versus XML implications.
Yes – I know all of the above, et cetera, et cetera, and I've heard the reasoning for not doing XHTML over and over again ad nauseum
But I still don't see how dropping the habit of using validating XHTML served as whatever MIME-type that is deemed appropriate by the W3C (which IMHO includes text/html following the guidelines in Appendix C and the (infamous?) media type note) in favour of HTML will help the web evolve… :p
Mojo Jojo,
I agree that it is a shame that most developers don't/can't take advantage of sending XHTML as application/xhtml+xml, to ensure that it is well-formed, but I totally understand the business reasons why they don't. Who dares to take the risk that a page won't render at all if someone adds something invalid to it? And, of course, we have the incremental loading thing…
But I think it's a bit too harsh to say that "So I'd say there is no real world advantage to XHTML but plenty of disadvantages".
The advantages, to me, are mentioned above with helping the web to evolve, to educate programmers in coding as strict as possible etc.
Not to downplay these two, but what major disadvantages do you see except for lack of incremental loading and being regarded as tag soup when sent as text/html?
(And as I wrote to Matthijs, send me an e-mail at robnyman@gmail.com so I can send you an invitation to Gmail, if you're interested.)
Tommy,
I think it's good that you clarified the difference between being well-formed and validating. Does that mean that, in such a case I mentioned above with those errors, you might yourself deliver something with such validation errors in one of your projects? Or would you without a question go for strict HTML 4 in such a case (sorry for just throwing questions back at you every time you comment :-))?
> or because they can't be bothered to encode ampersands
I really hope that this problem doesn't originate in lazy developers, but instead a CMS, commenting function on a web site or similar that delivers such code.
Also, thanks for explaining even more to Matthijs about the differences.
Milan,
I think you're the one whose situation is closest to mine. If it were solely up to me, I'd code perfectly well-formed and valid strict XHTML delivered as application/xhtml+xml.
However, circumstances (depending on what project it is) pose problems to me such as the validating errors in the .NET Framework that you discuss in your article, CMS systems might spit out weird code and so on.
And, from a business point of view when it comes to serving XHTML as application/xhtml+xml, as I wrote above to Mojo Jojo: "Who dares to take the risk that a page won't render at all if someone adds something invalid to it?".
> Robert, this has been an awesome discussion so far!
I bow my head in gratitude for your nice comment!
Jarvklo,
I share your opinion that XHTML has ignited a spark for the web to evolve, which is great! But the price for evolving is too high if the code isn't even well-formed (as in, would break if served as application/xhtml+xml).
To sum it up, there seem to be two camps (and then I don't mean the obvious pro- and con XHTML ones):
One camp consists of people that are leaning more towards being purists and wants to serve XHTML correctly and have it well-formed and validating, no matter the cost. If one can't live up to that, one shouldn't use XHTML.
The other camp comes more from a practical business perspective (with this, not saying that the first camp is all about theory).They want coding to evolve and be as strict as possible, but given (most of) the tools available on the market they're aware that serving it as application/xhtml+xml is not an option for them, that things might contain validation errors (but hopefully not well-formedness errors).
I'm not interested in having a heated debate where people fight for their particular standpoint. How do we make these two camps meet? Is it even possible? I want to reach a middle-ground, what's acceptable, where can we set the bar so it suits the majority?
Is it, for the time being, serving XHTML as text/html (according to Appendix C), perhaps having validation errors of smaller significance (such as invalid attributes) but keeping it well-formed?
I think it's really important that we, instead of whining about it, try to find some common grounds, for the sake of the web's future.
Chiming in with a newbie's point of view if that is ok 🙂 When I first began making websites a few years ago, I used WYSIWYG editors and never really got to grips with correct html, doctypes or anything like that. If the site displayed in IE, that was all I knew or cared about. Last year I started to learn about CSS and web standards, and understood that this required the use of XHTML. I then built my site using XHTML, and actually learned how to code properly. I am now reading many articles questioning the use of XHTML not served as XML, but it must be said that I expect there are quite a few newbies like me who only began serving acceptable web pages because we learned XHTML. To go "back" to HTML4 is not an option for us as we would have to learn it afresh. You really wouldnt want to see the sort of websites we used to build before….As someone once said, "The road to hell is paved with nested tables and spacer gifs" Our sites certainly qualified for that description!
Jewel,
I'm interested in hearing everyone's view (even though I don't regard you as a newbie)!
Good on you for learning how to code correctly! And judging by your web site, you've come a long way.
My personal opinion is as I said to Matthijs:
"…as long as your XHTML validates, is according to the above-mentioned Appendix C and works fine for you, I see no need to switching back just for the sake of it.".
What you mention is interesting, because I've heard a lot of people that got into correct coding through XHTML, and then started using CSS more, separating looks from HTML and so on like kind of a bundle with learning how to do things right.
And this is important, because it opens up the eyes of developers of how to actually do things the way they're supposed to be done.
Well, although I have learned an enormous amount in the last 12 months, I still feel like a newbie in the blogging world (or blogosphere as I have heard it called). I am however, beginning to feel confident enough to start joining in by adding comments here and there, so that is progress isnt it?
Thanks for a very interesting discussion.
Why XHTML?
I agree with Milan that I brings order to chaos. Just think where the web might be had we required well-formed XHTML from the beginning. I would bet that browsers would be a lot further along, with slimmer code-bases not needing all of their quirks-mode conditionals.
It is sad that we are allowed Appendix C. It rewards lazy attitudes (to write invalid code) that have plagued the web forever. That said, content-negotiation becomes a necessary evil, at least for a few more years. However, this shouldn't harm anything.
My dear friends…
THE HORSE IS DEAD.
Jewel,
Feeling ready to take part by commenting is definitely progress! 🙂
> Thanks for a very interesting discussion.
Thank you for reading it and participating in it!
Daniel,
It would've been an interesting situation if the Mozilla family, IE 6 and Safari, for instance, only had supported well-formed and validating XHTML served as application/xhtml+xml.
How the market would've had to change their products, how developers would've had to code correctly and so on.
A Brave New World!
First of all, I'm sorry but I only have more questions than answers here.
Mojo Jojo said:
"If you send XHTML as text/html (ensuring that the code will be parsed as HTML rather than as XHTML) you eliminate that advantage, you're sending invalid HTML (since valid XHTML is *not* valid HTML) to browsers and thus are relying on their error correction to sort it out"
To get things clear: does this mean the w3validator is nonsense? That I shouldn't have to bother to validate my webpages (xhtml served as text), as it doesn't matter anyway? I might be a bit confused here…
@Tommy, thanks for your explanation. It's getting clearer bit by bit. However, could someone fill in the gap here: what is the practical difference between placing a xhtml strict or html strict doctype at the top of my webpages? (that is, assuming the allready mentioned differences in coding are dealt with). For example: what if I downloaded a copy of wordpress and use it for a weblog. Should I bother to change the template to html?
I'm not trying to go against the arguments used against serving xhtml as text here, please let that be clear. I'm just trying to learn things and make a point from a practical point of view. That is, I want to make websites and make sure they are coded as best as possible, seperating content, presentation and behavior, being accessible, etc etc. I think in this discussion one must not lose sight of the fact (?) that still a lot (most?) of webdesigners/agencies haven't even heard of doctypes, let alone use them. If I look around at what code is produced for websites even by big companies…
I agree with Robert here, that it's important to find some common grounds, some consensus and bring the message out there, to improve the web.
@Robert
Some other disadvantages of XHMTL would be: the need to implement content negotiation, missing features such as document.write() (though it could be argued that losing document.write() is an advantage…), newbie confusion with things like name attributes and background-color styles on the body element, case-sensitivity (try validating this page :)), etc.
Perhaps the phrase "no real world advantages" was going a little far, as you point out (and Jewel confirmed) there are valid "marketing" reasons for jumping on the XML "bandwagon". Perhaps I should modify it to say there are "no real world advantages to individual web masters/designers/developers/etc". If the XHTML blurb encourages more people to embrace standards then I can live with it.
@Matthijs
In one sense yes, you're validating against an XHTML doctype but telling browsers to treat your code as HTML, what the validator says could be considered irrelevant. However, you should still validate your pages even if you send XHTML as text/html. Doing so will massively increase the chances of browsers correctly understanding your page (after all, HTML and XHTML while different are still fairly similar), it will mean that your pages won't break if they're ever sent with the correct MIME type (for example imagine if the next version of Apache were to automatically do XHTML content negotation by default) and it will catch any silly mark-up mistakes you make.
Matthijs,
The validator is not nonsense, you definitely should make sure that your code validates, for the reasons Mojo Jojo mentions above.
> what is the practical difference between placing a xhtml strict or html strict doctype at the top of my webpages…
Basically, the practical difference (if you're only using XHTML as HTML, i.e. none of the extra functionaliy it offers) is non-existent. Both of them will trigger the standards mode layout. The difference of the content, however, is that XHTML served as text/html is regarded as tag soup by the web browsers, but accepted by them (due to their error correction, as Mojo Jojo states).
> …wordpress and use it for a weblog. Should I bother to change the template to html?
I know nothing about the code that WordPress generates so I'll leave this question to someone else. But to me, if it generates valid XHTML, I see no need to recode it to HTML.
> webdesigners/agencies haven't even heard of doctypes, let alone use them
This, to me, is an even bigger reason to get people to write correct code, be it strict HTML 4 or XHTML. Sorry for the cliché now, but the web will only be as good as we developers make it. There's a huge difference between doing it correctly and doing it so it might, hopefully work, if one is lucky.
We need to spread the knowledge how to do things right. And agree what is right enough. 🙂
Mojo Jojo,
Regarding the disadvantages you mention:
– Content negotiation:
The question is if this is necessary, or if we can be content with sending it as text/html to all web browsers (to avoid the incremental loading problem etc), for the moment.
– Newbie confusion with things like background-color styles on the body element, case-sensitivity
The other way around, I see this as a reason to use it, to learn people how to code properly!
– try validating this page 🙂
I know… 🙁
I had some minor errors in the template I use, but they should be corrected now. The Blogger commenting functionality, for some reason, generates upper-case tags and allows people to use deprecated elements. It saddens me, but is something that I can't affect for now.
> If the XHTML blurb encourages more people to embrace standards then I can live with it.
That's the hope!
Wow, this debate is really raging on, huh? The poor horse must be mincemeat by now 🙂
"But I still don't see how […] will help the web evolve…"
It won't. But I still haven't seen a satisfactory explanation of how using an XHTML doctype on old-skool tag soup that would crash and burn when attempted to serve it as real XHTML will help the web evolve, either. 😉
Robert: Would I serve invalid, but well-formed XHTML? I don't know, to be perfectly honest. It would be an indication that something is not quite right somewhere in the publishing process. I think I'd start with attempting to rectify the problem, i.e. remove the invalid stuff. But if all else failed, yeah, I might consider that.
"Last year I started to learn about CSS and web standards, and understood that this required the use of XHTML."
jewel: I'm sorry to hear that you were lied to. Web standards and CSS does in no way whatsoever require the use of XHTML. CSS works perfectly well with HTML, since it was designed for just that. XHTML came along a few years later.
Many people seem to think that HTML must be a horrid soup of uppercase tags, omitted end tags, and presentational markup. They also seem to believe that XHTML somehow prevents this, even when sent as text/html. XHTML 1.0 is a reformulation of HTML 4.01 as an XML application. It contains nothing more, nothing less than HTML 4.01. It's not more semantic. It's a little bit more strict, as it requires well-formedness while HTML allows some end tags to be omitted, but only when served as real XHTML.
XHTML served as text/html is, as has been mentioned before in this discussion, nothing more than badly written HTML. You can take any old tag soup HTML document from 1995 and slap an XHTML doctype on it, and it will look exactly the same.
"what is the practical difference between placing a xhtml strict or html strict doctype at the top of my webpages?"
Matthijs: The doctype declaration affects validation (and in many modern browsers also the rendering mode). Using an XHTML doctype means it should be validated as XHTML, so the W3C validator is not wrong. However, it's not the doctype declaration but the media type (a.k.a. content type or MIME type) that determines how a user agent should interpret the document. A media type of text/html requires a user agent to interpret it as HTML. The doctype declaration has absolutely nothing to do with it.
If you validate your XHTML, you make sure that your markup adheres to the syntactical rules of XHTML. When you serve that as text/html, the user agent interprets it as HTML and will have to rely on its error handling to fix the things that differ between the two.
Separation between structure, presentation and behaviour is something to strive for, definitely. It has nothing, however, to do with XHTML vs HTML. It has a lot to do with Strict vs Transitional DTD, though.
I know some people think I'm a sad old reactionary who wants evolution to stop with HTML 4.01. That is not quite true. I would love to see XHTML come to its full potential, but few of its contemporary proponents are probably prepared for the changes that would incur.
Personally, I think it's much more important, for the evolution of the web as we know it, to convince people to switch from a Transitional DTD to a Strict DTD. Whether they use HTML 4.01 Strict or XHTML 1.0 Strict is of far lesser importance, although I'll stand by my earlier statement: if you use an XHTML doctype declaration, the document must work if sent as application/xhtml+xml. Even if you serve it as text/html due to the lack of browser support.
Tommy,
> Wow, this debate is really raging on, huh? The poor horse must be mincemeat by now 🙂
Well, I guess… 🙂
I just hope that we (all of us) will at least get closer to each other and understand that we face totally different situations and circumstances.
> …But if all else failed, yeah, I might consider that
I think this is the case for many developers who aren't lazy and try to get it to be correct, but face circumstances that they can't control. Of course every developing environment (e.g. .NET Framework), CMS etc should be able to delvier valid strict XHTML. Unfortunately, this is not the case, hence things might not be valid even if the developer had the best intentions.
> jewel: I'm sorry to hear that you were lied to
There's no connection, but it certainly didn't harm coders and their learning that an XHTML hype seemed to coincide/get blended with a separation/CSS hype.
> Many people seem to think that HTML must be a horrid soup of uppercase tags, omitted end tags, and presentational markup.
> XHTML… It's a little bit more strict
But don't you think that using HTML opens up for more sloppiness in the coding, especially when many developers work on the same code and not all developers are that experienced?
Then all they can rely on is the validation, where they can get away with more bad habits in HTML.
It's easier to teach people XHTML in that sense that it has to be well-formed, that every tag has to be closed, as opposed to HTML where most tags have to be closed but there are exceptions to the rule, which will most probably lead to that developers start getting sloppy about closing tags and eventually stop closing some of the tags that have to be closed.
> You can take any old tag soup HTML document from 1995 and slap an XHTML doctype on it, and it will look exactly the same.
True, but I think/hope people don't realize this and try to do it! 🙂
> I know some people think I'm a sad old reactionary who wants evolution to stop with HTML 4.01…
I don't think so! I think it's good that you aim for the best and valid code possible, but (as written above) I just want to bring up more practical scenarios where one might not have full control etc, but really see an advantage with it anyway.
> to convince people to switch from a Transitional DTD to a Strict DTD
This is the least we have to do! This, together with the separation of content, presentation and behavior, is the most important things we have to do and inform others about. But XHTML is on a close second place… 🙂
> if you use an XHTML doctype declaration, the document must work if sent as application/xhtml+xml
I agree.
To sum it up, I think I have to say my current standpoint is this:
The most desirable is, of course, to write well-formed and valid XHTML and deliver it with the XHTML MIME type.
If using the XHTML MIME type isn't an option (for whatever the reason, except lazy developers), one can either do content negotiation or serve it as text/html to all web browsers. Still ok, for now, since the current web browsers' error handling have no problems with it.
And, in a worst-case scenario, if it's well-formed but has some minor validation errors (but it would still work when sent with the XHTML MIME type), it is ok.
So, conclusively, I think the lowest I can go to use XHTML and get some of the benefits/avoidance of problems mentioned above is:
Served as text/html, minor validation errors (such as an incorrect attribute) but still well-formed.
Tommy, you've said it well.
I completely agree that a Strict DTD is the way to go. If you write XHTML it is easily converted to HTML. Personally, I write strict XHTML 1.1, and do content-negotiation and convert to HTML on-the-fly as necessary (I've even thought of converting my utf-8 data to latin-1, but I'm holding out).
This may seem like an unneeded extra step, but it assures that I'm doing the right thing by all browsers.
This is why I hate Appendix C. We should teach people that the ONLY way to do XHTML is as application/xhtml+xml and promote content-negotiation/conversion.
There's really no way to enforce this (old browsers will still try to render), but allowing Appendix C muddies the water.
Daniel,
As stated above, I agree a 100% about going with strict.
But regarding your hate for Appendix C, is it mainly because you don't want to deliver tag soup (i.e. XHTML as text/html) or that you think developers will be too lazy and take the easy way out?
> it certainly didn't harm coders and their learning that an XHTML hype seemed to coincide/get blended with a separation/CSS hype
Maybe it didn't harm the coders, but it did irreparable harm to XHTML as a concept. 🙁
> But don't you think that using HTML opens up for more sloppiness in the coding
I'm sure that sloppy developers will use it as an excuse for sloppy markup. I don't argue with that, but I want to point out that you can write HTML 4.01 that is virtually indistiguishable from Appendix-C-style XHTML 1.0 (minus a few slash characters). Just because HTML allows some shortcuts, for historical reasons, doesn't mean that you must or even should be sloppy.
>> You can take any old tag soup HTML document from 1995 and slap an XHTML doctype on it, and it will look exactly the same.
> True, but I think/hope people don't realize this and try to do it! 🙂
Just take a look at any so-called XHTML site served as text/html out there. Like http://www.spv.se/ for instance. Look at that markup and tell me how it helps the web to evolve. Tell me how that is stricter than HTML. Tell me how XHTML really forces developers to separate structure from presentation and behaviour. Tell me how it is more future-proof than HTML. XHTML is no panacea. It can be abused just like the HTML it is, as long as it's served as text/html. And if people get away with something easy, they will use it rather than doing it the right way if that's harder. Unfortunately they are not exactly unique. I'd guess that 99.9% of all purported XHTML sites on the web are like that. That's why I wrote the 'XHTML is dead' article a while back. (In that I vowed to stay out of this sort of discussions, too, but somehow I still find myself getting dragged into them. :))
Daniel: Thanks. I use the same sort of content negotiation on my blog, at the moment. The next incarnation will probably use only HTML 4.01 Strict, though. I don't use SVG or MathML or anything else that requires XHTML, so using it is just plain silly. There, I've admitted it. 🙂
Well..
I had written long a comment here, but I decided against submitting it after a quick preview since I really would like to se Roberts wish for constructively trying to find a middle ground here come true…
So I'll say this instead:
Do You remember how "impossible for commercial use" and "just plain impossible" CSS layouts were considered before sites like the CSS Zen Garden ? – why don't we try to come up with an abundance of positive examples on XHTML "done just right" instead of just fighting the same flame war over and over as soon as someone tries to write something on the current subject ?
Who'll be the first to create a "30 days to a perfectly built and served XHTML 1.0 Strict based site" series ?
Hey good writeup. i wrote an introduction to xhtml and stylesheets myself on my site to bring the beginner in…
http://www.dev-news.com/index.php?p=30
Drew
Tommy,
> Just because HTML allows some shortcuts, for historical reasons, doesn't mean that you must or even should be sloppy.
Of course not. But in most real-life scenarios (at least the ones that I seem to run into), people less skilled in HTML are also involved (read: system developers with lack of respect for/interest in interface code knowledge). In those cases, I believe that giving them the option to code HTML is a bigger risk for getting it more sloppy than telling them to code XHTML and close all tags.
> http://www.spv.se/
It's terrible.
But I think we do agree on the most common denominator: That the XHTML has to be well-formed and, in that, being correct enough to be able to serve it as application/xhtml+xml. Regarding minor validation errors, I'm willing to overlook them if it lives up to the previous sentence.
I still think writing XHTML well-formed (with possible minor validation errors) helps the web to evolve and will be stricter than with HTML.
However, it won't help with this: "Tell me how XHTML really forces developers to separate structure from presentation and behaviour".
> I don't use SVG or MathML or anything else that requires XHTML, so using it is just plain silly. There, I've admitted it. 🙂
I don't agree that the only case where XHTML is motivated is when using features that require XHTML (see above motivation). 🙂
Jarvklo,
Thank you for the respect to keep it on a constructive level.
> Who'll be the first to create a "30 days to a perfectly built and served XHTML 1.0 Strict based site" series?
This would be great! I thought Zeldman's book Designing with Web Standards would be this, but I heard that he unfortunately uses the XHTML Transitional Doctype in his examples… 🙁
Drew,
> Hey good writeup.
Thank you! And thanks for the link.
It's funny, but in a project where you have developers who are "less skilled in HTML", I see things completely opposite to your point of view. Unskilled developers should absolutely not work with XHTML, because even the slightest well-formedness error will kill the page when served properly. Unskilled developers should be educated, but until they are proficient, they should use HTML where the error handling is less draconic.
The notion of allowing the "XHTML" from such developers to be served as text/html only, to avoid the Yellow Screen of Death for well-formedness errors, is something I consider very detrimental to the future of web standards. This is exactly the category that should use application/xhtml+xml, so that their errors are caught quickly.
> Unskilled developers should absolutely not work with XHTML
Unfortunately I don't get to choose all the members and specify their skills in a project group.
> This is exactly the category that should use application/xhtml+xml
Yes, and that's what I'm going for, that would be ideal. But if not using that MIME type (it might be a business decision by the customer, that they don't want to take the risk that their web site doesn't render if someone, for instance, has entered a link in their WYSIWYG tool that contains an ampersand (&) that isn't escaped properly), it's easier to tell them to close each tag, no exceptions, than trying to teach them HTML with its exceptions.
I am currently using WordPress which unfortunately uses a transitional doctype. Any code I write myself, I strive to validate as Strict. However, when I wrote my own html site, the only thing that stopped it being ok with application/xml were a few external javascripts I was using. On a side note, does anyone know if you can modify existing javascripts to not use document.write, and if so, could they point me to any resources on this subject?
@Robert, Since Appendix C allows sending XHTML as tag soup, it effectively allows sending malformed XHTML (browsers aren't treating it as XML). Therefore, as has been pointed out before, many think they are writing valid XHTML, but are truly not.
@Tommy, I agree that I see little reason in my own work to use XHTML. That said, I like the feeling of being forced to write well-formed code.
Personally, I don't see any reason not to use XHTML, especially when I start with a new site. There are many that say Strict HTML is fine. I agree. The bigger problem is that not enough people are writing Strict code.
It seems like you shouldn't have to serve application/xhtml+xml simply because you are coding in XHTML. For situations when you are using say XHTML+MathML, then yes you should serve XHTML as application/xhtml+xml. If you are simply wanting to take advantage of the XML parsing for browsers (you want it to tell you what line of you code has a problem) you can simply serve it as text/xml. In the end though what you do with the code is usually a compromise of what browsers can handle. For instance XML documents require that a character set be declared. Gecko-based browsers will usually not check to make sure your character set is actually what you are using. So you can use ISO-8859-1 characters in your code even though you've specified utf-8 as your character set. Your page will render just fine. Most sites on the internet that specify utf-8 are using illegal characters and relying on the browser to take care of it.
A browser like Safari has limited xml support. It will actually accept XHTML served as application/xhtml+xml or text/xml but doesn't tell a server that it can. There's a good reason for it. It seems like the Safari development team never completed the XML support for Safari. For instance Safari will not execute any scripts in your document served as XML in any flavor. Whether you use the CDATA escape commands (also it seems like none of the Gecko-based browsers care whether the escape commands are present or not). Secondly Gecko-based browsers will give a hint as to where you code is using improper syntax, while Safari just gives a white screen with black lettering stating "XML Parse Error." Nothing else… so there is definatly good reason for Safari not declaring it's XML Parser to the world. An interesting note is Safari is the only browser that warns of improper character set usage. Its XML parser simply leaves out the character in a page if there is say non-XML characters ( , $lquot;, etc.) or ISO-8859-1 characters on a page that declares itself as utf-8.
Another issue is absolutly no browser's xml parser allows for the W3C specification for serving up stylesheets with associated xml files. Safari simply bombs out with its error message while Gecko browsers ignore them altogether. Resulting in a page with no stylesheet applied. An intersting thing is you can use xml declarations for stylesheets with the @import command in Gecko browsers. Gecko browsers seem to be able to parse the @import command regardless of whether or not it's inside of a tag the browser is programmed to recognize. But if you try it with Safari it will just bomb out again as it's xml parser is set to stop as soon as it gets to an unsupported tag whereas Gecko browser will render your page ignoring the unsupported portions.
I am very supportive of Web standards. But simply serving a page up with as xml simply because the W3C says so may not be the best way to go. Too much is reliant on which standards are supported by browsers. W3C recommendations should be followed when possible but too many real-world issues arise when doing code completely to standard specifications It's probably impossible to follow all web standards that are set out due to these issues.
Jewel wrote:
>I am currently using WordPress which unfortunately uses a transitional doctype.
Yeah
that's true – but if you use WP 1.5 with the new default "Kubrik" theme
you can simply exchange the transitional doctype for a strict one and
add a content negotiation script (eg. like the one Tommy wrote) and it just works, application/xhtml+xml and all…
At least it did for me when I converted to WP recently 😉
If you change the theme, however, it is another matter – but I wouldn't
blame WP for that since the themes are responsible for most (if not
all) of the code generated on a WP site nowadays anyway 😉
Oh – and
you'll have wath some of the legacy plugins before you commit to
negotiating content type as well… But again… I wouldn't blame WP
for how third party plugins handle themselves either 😉
Daniel,
Thanks for the reply.
> Therefore, as has been pointed out before, many think they are writing valid XHTML, but are truly not.
> The bigger problem is that not enough people are writing Strict code.
This is definitely a problem, but how do we best educate them?
Sys,
Thanks for a very interesting and multi-faceted comment! It was especially interesting hearing about those features in Safari.
> W3C recommendations should be followed when possible but too many real-world issues arise when doing code completely to standard specifications It's probably impossible to follow all web standards that are set out due to these issues.
Oh yes, there are many, many real-world issues that arise when following the W3C recommendations. However, if using XHTML, I really think people should strive for making it well-formed, while if some automaticlly generated attributes (say, from the .NET Framework) don't validate, isn't the end of the world.
Jarvklo,
Thanks for helping Jewel with the WordPress question.
Jewel,
> modify existing javascripts to not use document.write…
This is just a short example of how to achieve that using the DOM:
var oDiv = document.createElement("div");
var oTextNode = document.createTextNode("This is my text, and I'm Jewel.");
oDiv.appendChild(oTextNode);
and then append the DIV element to where you want it, e.g:
// Last in the document
document.body.appendChild(oDiv);
// Before another element
document.body.insertBefore(oDiv, document.getElementById("anotherElement"));
// As the last child within an element
document.getElementById("rightColumnNewsContainer").appendChild(oDiv);
More information about DOM scripting can be found in the Gecko DOM Reference.
@sys wrote: >…XML documents require that a character set be declared.
I was under the impression that you don't have to explicitly declare if you use utf-8. Am I wrong?
Otherwise, you raise good points. When I do content-negotiation, I don't send application/xhtml+xml to Safari, even though I could. I am glad that they don't claim to support it and give us a half-done implementation.
We've seen lots of half-implemented standards with CSS and HTML (and these probably are less imperative), but its high time browsers start fully supporting standards, or not claim to. When we start dealing with XML, its stricter rules (well-formed, mainly) mean we have to be less forgiving in what code we accept.
@Robert wrote: >This is definitely a problem, but how do we best educate them?
Yeah, that's the tough part. It's possible that my ideas about not having Appendix C would just make XHMTL less accepted. I guess we start by calling developers on their mistakes. If we see an XHTML badge, make sure they are truly XHTML and bug them incessantly if not. Getting more dev tools (DreamWeaver, etc) to be more strict would also be a good thing.
If we approach XHTML as do it right or not at all, rather than its the cool new buzzword, we would be better off. Back to my problem with Appendix C…
To daniel: The W3C recommends always declaring the character
set. The assumption, when this is left undeclared, is performed by the
browser and/or operating system. For instance if character sets aren't
declared in the headers of the document or in a meta tag, a browser say
from Asia would default to utf-8 if they are on a local version of
Windows or Linux. One from East Europe would default to ISO-8859-2.
Here in the U.S. ISO-8859-1 is the default. You can read about W3C's specs here.
I found a post on 456 Brea Street
a while back. Seems like lots of people are trying to use a xml mime
type if they can. The owner of the site Roger Johansson seems to have
run into some trouble with it to as far as cross-browser compatibility
as well. I've also seen from the posts on his site that many people
have said that IE does not parse xml. Well, it's kind of like Safari
actually in that they didn't broadcast this feature. Whereas Safari's
xml parser falls a little short of complete, IE's would be classified
as "has it, just for the sake of having it" if you know what I mean.
You can force IE to parse a page sent with the application/xml
mime-type only. The biggest problem with it is IE parses any xml you
feed it in quirks mode
instead of standard mode. This defeats the whole purpose of using xml
in the first place. I could go on for another page about IE… Oh, and
if anyone here is interested in knowing how to force IE to parse xml
for your own edification I'd be happy to oblige.
I'm not sure if this applies to any of you, but I'll give it a shot.
For those of you that serve XHTML as application/xml to browsers that support it, and HTML 4.01 to browsers that do not: why? Isn't the point of XHTML being backwards compatable that you can serve it as text/html and it will still work? Why not maintain only one verson of your page, and vary only the mime-type?
Daniel,
> If we approach XHTML as do it right or not at all, rather than its the cool new buzzword, we would be better off.
Then let's try! 🙂
Sys,
> You can force IE to parse a page sent with the application/xml mime-type
I see no reason in doing it, escpecially since it triggers the quirks mode. I'd rather use content negotiation or just plainly serve it as text/html to Internet Explorer.
Daniel Worthington,
> and vary only the mime-type…
It's a valid question. Personally, I don't think I see any problem in serving it as application/xhtml+xml to Firefox (and others) and serve it as text/html to IE, while the code will be XHTML-formatted in both cases. I mean, after all, IE has the best error correction of them all (it accepts EVERYTHING) so XHTML regarded as tag soup shouldn't be a problem at all.
IMHO the real reason for xhtml's limited but passionate take-up is that folks are desperate to move forward from HTML1997. Folks tweak and polish their HTML1997, whether expressed in HTML4 or XHTML1, because they are so enthusiastic about the web they want to do something (anything) to move the web forward.
This is both disappointing and encouraging at the same time. Disappointing because folks indulge in pointless markup/mimetype complexity offering no discernible benefits to anyone. Encouraging because this would appear to indicate that when something new and useful does eventually arrive there is a ready-made community gagging to experiment with it and drive adoption.
imho putting perfect (or imperfect) HTML1997 into a more brittle format does not move the web forward. To the user there is no difference unless they get the yellow screen of death. Meanwhile the biggest recent innovation happened outside the W3C/standards community with XmlHttpRequest, a non-standard Microsoft technology, copied by Mozilla, Apple and Opera. The WHAT-WG also appears promising, having recognised that new standards can actually offer new functionality and don't have to be expressed in XML.
Innovation does not mean doing the same thing over and over again in ever more complicated ways. Innovation means doing new things.
Whatever replaces (X)HTML1997 will spread like wildfire across the OldWeb, and discussions like this one will not occur – because it will do something new ("you know, for users!") and the advantages will be blindingly self-evident to everyone. It probably won't use draconian error handling. It certainly will do new things.
In the meantime, I'm off to stick a load of extra slashes in my webpages and replace all my b's and i's with strong's and em's for no apparent reason 😉
Mattur,
> the biggest recent innovation happened outside the W3C/standards community with XmlHttpRequest
Funny you should mention that. I wrote about AJAX today, which that is a part of.
> In the meantime, I'm off to stick a load of extra slashes in my webpages and replace all my b's and i's with strong's and em's for no apparent reason 😉
😀
To Robert: Yeah serving content to IE with content negotiation and serving it as text/html definatly seems like the best way to go since IE goes into standard mode based purely on DocType and presence of xml tags to trigger the rendering mode. So unfortunatly that translates to quirks mode rendering of valid xml. This may be too optimistic, but maybe Microsoft will fix this and actually let IE7 display pages delivered in proper xml mime type and syntax in standards mode.
If your web pages are XHTML, then they're XML. This means you can use all the XML tools to process those pages, and do stuff with them.
Makes no difference to someone browsing to your site on the web, but for crying out loud, the internet isn't just frickin' web browsers. You know how you can re-skin your site easily with CSS? XSLT is a more complicated language, but it allows you to transform your pages into other XML with equivalent ease.
HTML is fine for an old-style website. But XHTML makes your pages more useful as information. Then again, I guess anyone wanting to parse HTML pages could just run yours through HTMLTidy to get XHTML, and they'd be away.
Sorry, rambling. The basic point: XHTML is easier to deal with programmatically, via the wealth of XML tools available.
sys,
> This may be too optimistic, but maybe Microsoft will fix this and actually let IE7 display pages delivered in proper xml mime type and syntax in standards mode.
I do hope that happens. However, then we need to implement an extra check between IE 6 and IE 7 in all our solutions, to distinguish between them…
pauldwaite,
> Sorry, rambling. The basic point: XHTML is easier to deal with programmatically
I agree, and that's one of the many reasons it's appealing to me.
Thanks for the javascript info. will expore that fully when I get more time. I did try validating with a strict doctype, but the validator choked on forms and stuff. Probably my modifications to the Kubrick theme are to blame.:-( This is clearly something I will have to tackle in the summer when college is finished. I always enjoy a challenging summer project 🙂
No problem.
Good luck with the work on your theme!
@ Robert:
I'm not sure whether it'll really work, but it's my effort anyway: proving that creating True XHTML websites even for businesses doesn't have to be a problem, as long as you use content-negotiation to serve non-conforming browsers normal HTML (whether you switch your markup around to be truly HTML with an HTML doctype or not is up to you).
My CMS is doing just that. Ensured well-formed, valid XHTML documents (Transitional sadly because customers still demand to use target="_blank"), sent as <code>application/xhtml+xml</code> to all browsers that support it, and sent as <code>text/html</code> to those that don't.
Faruk,
Good to see you here!
I agree with what you said and think it sounds good.
The only thing I have a problem with (although I understand the issue) is using the Transitional Doctype because of its Almost Standards Mode rendering in Firefox.
Robert,
Hah, thanks! I'd have come here earlier if I hadn't been so ridiculously behind on my weblogs. See, my CMS isn't entirely finished yet, and right now, virtually all my time is spent on finishing it. It's annoying, because it's keeping me from being very up to date every so often, but ohwell. Eventually I'll catch up (and get something more worthwhile done with my site, *mutters at self*) 🙂
Yeah, the Almost Standards Mode-aspect isn't great, but sadly I have no way of working around it. I'm looking into using a Javascript-approach to work around it so that I can make all the sites XHTML Strict, but for the time being that's not finished yet (and also, lower priority than finishing the missing features on the CMS itself…).
Faruk,
I don't know what the JavaScript-approach will consist of (like using the rel-attribute and an onload script?), but if you require JavaScript of the user, won't you, most likely, get accessibility issues then?
Robert,
Nah, I'm talking solely on finding an alternative to <code>target="_blank"</code>, one that works without requiring that attribute, and one I can parse in- and out of documents easily.
A javascript approach would have the only downside that if javascript is disabled, the link opens in the current window. The <code>target="_blank"</code>-approach has a much bigger downside, in that IE-users can't really do anything easily to make it NOT open in a new window. So if you want that link to open in your current window, you need to manually copy the shortcut and paste it into your address bar. That's an accessibility issue for the vast majority of people, namely everyone that uses Internet Explorer and can see.
So, to cut my irrelevant rant short(er :/), my idea will most likely be a very accessible approach that allows the use of XHTML Strict.
I should write an article about it once doing it, and see if ALA / Sitepoint care to publish it 🙂
Faruk,
Sounds like a good ambition!
Preferably, one would like to convince the customer that opening a new window isn't a necessity.
However, if that fails, the solution you're striving for should be a good alternative. A new window for those who use web browsers that support/have JavaScript activated, and just linking to the correct page for those who don't.
Sorry to be late to the game, but no one's mentioned this concept yet. It seems that XHTML sites by their very nature are incredibly easy to parse, right? So then Feedburner et al shouldn't really need a separate RSS page to determine what is new on my site.
Aggregators could determine the XPATH into each site's article nodes and directly extract new content without the intermediate RSS step (which of course, generates XML!) Alternatively, XHTML web sites could publish in META tags the XPATH needed to extract article content from that specific site.
RSS seems to be a crutch for the XHTML-challenged.
Carl,
Better late than never. 🙂
To me, I see much easier re-using and parsing of the code if it's valid, well-formed XHTML.
However, the world throws us obstacles all the time, like WYSIWYG tools, "features" in .NET etc.
But at least we need to have the ambition and vision to do it right and not give in.
Apologies all around.
In re-reading my previous post I see that in my haste my comments could be inflamatory on a number of levels and to a plethora of people, so here are my apologies and restatements in a more civil manner.
First of all, I'll retract my "no one's mentioned this" claim. This concept WAS mentioned amongst the many people participating, pauldwaite most notably. He raised the point that XHTML pages are easier to deal with. I simply added an example of an internet app that takes advantage of XML now and applied it to XHTML sites in general.
Next, my final statement in the previous post could be interpreted as insulting to many individuals and I extend my most sincere apologies to anyone who may have interpreted my statement as an insult to any individual or collective peoples. If I could amend my final statement it would read…
RSS seems to be an intermediate step towards an XHTML-prevalent internet.
Carl,
No problem at all (at least not to me).
But thanks for trying to keep it at a reasonable level and as a balanced discussion, instead of flaming away.
I really appreciate serious discussions.
I want to be able to generate populated forms via XSLT, and you can't run plain HTML through an XSLT engine without it puking on you. I also use XSLT to generate my ASP.NET controls, so I want to be able to generate them in one pass, save the markup off to the state or a file, and then when the user hits something in the Search box populate the already generated markup with values via another transform. It won't work if I have unclosed tags. I haven't found a way around this yet other than just replacing all the dirty tags I know that ASP.NET generates with my own parser. Which of course means I might as well just regenerate the entire page, eating up my processing time. I rather dislike this aspect of ASP.NET.
dave,
Sounds like a valid reason, if you want to put it through an XSLT. When it comes to ASP.NET and valid code, you can read my post How to generate valid XHTML with .NET.
[…] et ‘bra användning av XHTML’ Skrivet 2005-04-09 av jarvklo Efter ännu en av alla dessa tidvis ganska intressanta debatter om huruvida XHTML är “bra” el […]
And 18 months later, this post is still highly relevant to readers. Glad I could read it, see some other views, and reinforce my existing opinion.
Romerican,
Yes, this discussion never seems to go out of fashion. I wrote another post later on, HTML or XHTML?, that also might be of interest to you.
Man, thanks a lot,
In my country Jordan most IT people think the way you titled above:
“Yes, we know what we do, we code XHTMLâ€Â
Thanks for your thoughts, I was evaluating to convert to XHTML, and you helped me making my decision
Stick to HTML. 🙂
[…] Harmful that about every web developer read and quoted, and one of my first blog posts ever, Why XHTML?, was written at that time as […]
[…] Spartanicus – No to XHTML W3C – XHTML 1.0 -What is XHTML? WaSP – HTML Versus XHTML NYPL – Online Style Guide – XHTML Benefits Molly Holzschlag – XHTML 1.0: Marking up a new dawn IBM – XHTML 1.0: Marking up a new dawn – Molly Holzschlag Webmaster World – HTML & Browsers forum – Why most of us should NOT use XHTML Anne van Kesteren – XHTML versus HTML Anne van Kesteren – Quick Guide to XHTML Anne van Kesteren – XHTML is invalid HTML W3C – XForms 1.0 FAQ A List Apart – Rated XHTML – Peter-Paul Koch Wikipedia – HTML_5 456 Berea St. – The Perils of Using XHTML Properly – Roger Johansson Wikipedia – XHTML WaSP – The Benefits of XHTML modularisation WSG – Ten questions for Anne van Kesteren Robert’s Talk – Why XHTML? – Robert Nyman […]
[…] Spartanicus – No to XHTML W3C – XHTML 1.0 -What is XHTML? WaSP – HTML Versus XHTML NYPL – Online Style Guide – XHTML Benefits Molly Holzschlag – XHTML 1.0: Marking up a new dawn IBM – XHTML 1.0: Marking up a new dawn – Molly Holzschlag Webmaster World – HTML & Browsers forum – Why most of us should NOT use XHTML Anne van Kesteren – XHTML versus HTML Anne van Kesteren – Quick Guide to XHTML Anne van Kesteren – XHTML is invalid HTML W3C – XForms 1.0 FAQ A List Apart – Rated XHTML – Peter-Paul Koch Wikipedia – HTML_5 456 Berea St. – The Perils of Using XHTML Properly – Roger Johansson Wikipedia – XHTML WaSP – The Benefits of XHTML modularisation WSG – Ten questions for Anne van Kesteren Robert’s Talk – Why XHTML? – Robert Nyman […]
Robert first off let me say hi and thanks. This one page has answered alot of questions and has shown me I am not alone. Now im not a very good writer i never usually respond to things i read on the net but i had to tell someone my story as it might help out someone as your origional post helped me.
Now before i start let me just say i dont beleive in religion and i don't beleive in the athiests views i have my own personal beleifs that i have just now discovered.
I was at a party one night when i was confronted with an athiest we got to talking about my religion and as i joke i told him i was an "Agnostic Theist Athiest" and when he questioned me on this i told him i dont wholly beleive in a christian god and sometimes when the mood takes me i don't beleive in a god at all. He asked me why and i could not answer him, he told me my problem was i had a lack of faith and i couldn't see the truth, nothing happens after we die. I reject this idea, i personally am terrified of death but not because of nothingness after we die its something diffrent it's the thought of this life as being pointless. If we were solely created to live then why not just give us some basic survival skills and send us out into the world, why ponder, why create. Art is meaningless to our existence why create it then? Love is meaningless, why love, we don't need to love to mate so why? for awhile i have despaired at these questions as it makes my existence here meaningless, as it makes all of our's pointless and i just can't buy it. So i beleive that there is a god to some degree i beleive we were created theres just far too much evidence not to agree. Imagine nothingness, most people think of a terrible blackness but the truth is nothingness is much less than that and imagine that's at one point all our universe was. What created the first thing? people theorise it was a "Big Bang" but then what created this big bang? again something cant just come from nothing, its impossible.
Look at free will, conciousness, personality, spirituality. We are an inquisitive species by nature but why? what's the point if there truly is nothing out there? i reject that notion whole heartidly, Ill never know if there is a creator but to me it makes sense. To me it gives some comfort.
I really still am confused in what i beleive and being 22 i thought i was too young to really worry about it to the point i thought something was wrong with me. It is very comforting to see people even younger than me question there morality. Truly though don't ever be scared of death, no one can ever say what happens after we die, science tells us nothing but science has been wrong before it's based alot on beleif a narrow beleif that all we see is all we have. Look around your world and never be afraid to question what is and why it is. If we all sit around waiting on the inevitable then on our deathbed we will look back at this time as wasted, live it and love it and be sure to squeeze every single minute of pleasure out of our lives theres nothing wrong with being afraid, but don't let that fear rule your life. I had so much more to say on this subject but i don't want to get all preachy. Remeber though is all else fails just think of life as being in the doctors waiting room when your sure theres bad news to be told. You can sit around fidgiting and waiting for that door to open or you can kick back, open a magazine and enjoy the wait. Who knows maybe when it's all said and done there will have been nothing to worry about the whole time.