When did people stop caring about
Remember a couple of years ago, when serving XHTML with a
text/html MIME type was the worst you could do if you were serious about your trade?
Ian Hixie wrote his Sending XHTML as text/html Considered 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 well.
But what happened then? People seemed to stop caring, and in this current day, no one seems to write about it. Also, the web is full of so many web sites with XHTML served as
text/html instead of the proper
application/xhtml+xml that it feels like not even a googol can describe it.
When did people stop taking this into account? Why isn’t anyone pointing this out to unaware colleagues anymore?
I think its because I don't agree with Hixie in the first place. Not having time to revisit his article I remember seeing it as the pedantic ramblings of someone who spent too much time thinking of geekery and little of it living the good life. I still really wonder how delivering XHTML is really really wrong and 'breaks the web' and yes I have had people in the past flame me with horrid emails regarding this matter. Dare mention XHTML in forums on that score.
To put that all in context – about 99% of the web is actually junk without DTDs or anything else and someone rants wildly about XHTML delivered as HTML breaks the web?
Step one in getting an idea to stick would have to be education is 1000 times more effective than simply attacking people from a pedestal (such as happened in those instances Robert). Remember in those days, only a couple of years ago, there were also big names supporting the "lock out IE users" idea. I notice the passionate campaign against sites which don't deliver content without the www seems to have faded away too – a recent search for reference found barely a squeak in that direction (maybe its a little bother but nothing serious was the consensus – yet on the day…)
I also teach XHTML and CSS to graphic design students at the Certificate 4 level (industry standard level). Why? XHTML offers a stricter set of rules that people can follow so its easier to teach in some ways. Also, its undeniable as your post alludes to, that many commercial platforms are delivering content as XHTML served as HTML. Teaching my students HTML would put them at a disadvantage given they are most likely to seek employment here on a project that uses XHTML as HTML.
Now that poses an interesting question about whether XHTML is the dead one or HTML 5? There are a couple of problems with grass roots movements and one of them is that some key influencers may not always be right about their opinions on the day (such as me here it might be said). Many of these things are probably highly debatable such as the value of HTML 5 or whether XHTML should have been pursued and supported.
I have always felt funny about how people who at least take the time to deliver some decent content which is valid and hopefully semantic were trolled on this subject. How to drive people away from web standards 101.
So in long I think we just moved on and recognised the fight wasn't against our factional selves but hopefully against the real bad practice of not even using DTDs etc.
Sorry if this sounds flamey, feel free to pull this comment if you want but its how I feel. Live and let live on this one I say. After all that quoting Hixie really wasn't listened to and that should say something in itself
HTML 5 Apathetic – now there's a discussion… 🙂
If you ask me, the fact that the IE team passed on supporting that for XHTML didn't help the case at all. We can look into http header <code>Accept</code> and spit the correct mime type for our document, if supported. But…
As more people became aware of this issue, more started going back to HTML4 Strict. Just as long as it's strict, people seem to find it comfortable markup.
I also believe there's a factor of "la-la-la-i'm-not-listening-la-la-la". I think we can all relate to the elegance of having XML mixed with our XHTML, it makes things cleaner, easier to parse, harder to end up with tag-soup.
The problem is that all you need is an unescaped entity, an unclosed tag and BOOM! There goes your website! (you can use tidy but not everyone is willing to go that extra mile)
I'm glad you mention this… even though you might be preaching to the choir here, I agree it's useful to keep the discussion alive. We need to be welcoming the people who only now are waking up to webstandards. Well done, Robert. 🙂
I guess because the XHTML specification says it's OK to send it as text/html as long as you follow the guidelines in appendix C?
Also, if you build web sites for other people, you don't want to end up in a situation where their lack of knowledge puts you in a neverending maintenance position. â€œAll we did was add a link and the page went blank!â€
… I guess 🙂
Oh, great! I wrote a long comment but it seems to have been eaten by your blog software. 🙁
I personally can't be bothered anymore to use this MIME type since IE team announced they won't support it, as they believed it would "hold up the web". How was it supposed to happen I have no idea, as it wouldn't be mandatory to use, would it? What is more, I do not really see any benefit of using it as in opposed to <code>text/html</code>. I still have to write the same structured and valid code and I don't use any funky XML voodoo like MathML in my projects…
What is more I found out that any project validates only up to the point of delivering it to the client. No matter how much effort we put into making <abbr title="Content Management System">CMS</abbr> produce valid code, client will always find a way to mess things up, badly. I really, really don't want to spend all my time fixing stuff and explaining what happened ('Our site is down again! Your company sucks!'). Do you?
Great question, simple answer: Because of IE. Real web pages have to fit at least the needs and requirements of the most widespread "browser", and this one does not support application/xhtml+xml. So real world pages have to be in html 4.01, or at most in xhtml 1.0 served as text/html, which makes all special xml advantages void.
For me personally i've found a way to deal with that with my own pages: I create them out of a simple html-like xml file via xsl, outputting a html 4.01 version as well as a xhtml 1.1 version, and serving them with both the correct mime type via automatic content negotiation, defaulting to html. I'll stick to that because these xml files contain different language versions as well.
For real world pages it would be possible to create correct xhtml 1.1 files and use xsl to automatically translate them into html 4.01 and then serve both. The automatic translation is a prerequisite for that, but since xsl this is no problem. For converting xhtml 1.1 into html 4.01, a minimalistic xsl stylesheet would be sufficient.
Here's my second attempt to comment. I'll omit the techie stuff, since WordPress seems to choke on it. 🙂
XHTML was seriously hyped some years ago. Unsuspecting designers and developers were tricked into believing it was the best thing since sliced bread.
When they realised â€“ after reading Hixie's article â€“ they weren't using XHTML at all, they went into denial. It couldn't be! Everyone knew that XHTML was new and HTML was old (ergo, boring). The fact that the difference was only three months wasn't important; newer is always better.
IE doesn't support XHTML and won't do so in the foreseeable future. That means real XHTML is a marginal product that can be used only by a select few. It's also rather more difficult to handle than HTML â€“ including invalid HTML with XHTML syntax (i.e., XHTML markup served as text/html).
It's much easier to use the XHTML syntax one has struggled to learn and simply ignore the minor issue about MIME types. If I write an XHTML doctype declaration, that means I'm using XHTML, right? What? Who said no? Oh, nevermind.
The Web is full of disinformation about how superior XHTML is. Some even lie outright and claim that those advantages are present even when the markup is served as text/html. I've seen preposterous statements that CSS can only be used with XHTML and that XHTML 1.0 is more semantic than HTML 4.01. (No mean feat, considering they share the same set of element types.)
The whole world seems to be getting more superficial. So-callled reality shows flood the television channels; newspapers mainly write gossip; everone is assumed to have the attention span of a goldfish.
People want rewards and results, but they don't want to have to actually work to get them. Putting up an SEO'ed nonsense page filled with ads leaves much more time for golf than one those boring nine-to-five jobs, right?
Consequentially, most people can't be bothered to learn about the profound differences between HTML and X(HT)ML. If application/xhtml+xml doesn't work in IE, then it's probably nothing to worry about. If my 'XHTML' page looks good in IE6, how can I have done anything wrong?
Krzychu Danek said,
If you don't see that, I'd be interested in learning what benefits you do see of using XHTML over HTML. Very interested.
I think it was IE7's non-support for application/xhtml+xml that pretty much brought on the death – or at least the coma – of this particular movement. Digging back through my memory, the release of IE7 and the stop of blog posts on this topic seem to about coincide.
It is very difficult to justify the whole scripting thing for content type selection, when it really benefits no one.
I still tell everyone I know to use HTML 4.01 Strict, and I will keep doing so until IE has native, proper application/xhtml+xml support.
I stopped serving xhtml to all but IE because my Google Adds didn't show up. I guess it has something to do with document.write.
Not that I make any money of of them … 😉
<blockquote cite="http://www.robertnyman.com/2007/10/02/when-did-people-stop-caring-about-applicationxhtmlxml/#comment-114414">If you donâ€™t see that, Iâ€™d be interested in learning what benefits you do see of using XHTML over HTML. Very interested. None, I am using HTML 4.01 Strict whenever I can (which is not always the case due to some backend systems/libraries I work with which apparently have no option for serving HTML instead of XHTML tags like <code>input</code>, <code>img</code> or <code>meta</code>).
Still, at the end of the day, does it really matter if you choose HTML or XHTML served either as <code>text/html</code> or <code>application/xhtml+xml</code>, as long as you make sure it validates? I say – content's structure is important and should receive most of developers attention, not the markup used to build it or the MIME type it is send with. At least for the users, who have no benefit from choosing one over another…
Oh, and I am talking from a finite time resource point of view – I really cannot afford adding content negotiation for most of the projects I work with, as it essentially provides no extra value except for my self-content.
If you can provide a business case for using <code>application/xhtml+xml</code>, please do.
People stopped talking about it cos it was a storm in a teacup.
No-one running a real life, commercial site could serve it as xml. Not just because IE doesn't support it, but because it would be folly. One single unencoded ampersand, unquoted attribute, incorrectly closed tag and xml is required to fall on its arse and refuse to render. XML is required not to "guess" a users intention, but instead, stop.
Who could possibly justify the risk of a page not rendering because of an inadvertent bit of badly-formed html in a comment, or because one of the web team made a mistake because they were in a hurry to go home for the weekend, or because some third party advertiser's code was badly formed.
And what is the advantage of serving a site as xml?
Tommy asks "Iâ€™d be interested in learning what benefits you do see of using XHTML over HTML."
Simple: I prefer it. I find it aesthetically more pleasing. You may not; that's fine.
I was lucky enough to learn in 2002 – when xhtml was all the fashion, and (more positively) when CSS displaced tables for layout (so I never learned table layout).
I spend many hours, both professionally and personal time, writing code, and prefer xhtml syntax. I find it more satisfying.
I have to say I'm in agreeance with Bruce on this one and I began working with markup at around the same time. In short its because I like it. 🙂
I also don't get what the 'breaking the web' statement was about. How does XHTML served as text/html break the web? I mean, not to labour the point but – wouldn't 99% invalid junk markup on the web break it if anything was going to?
Yes, it matters a lot. The former is invalid HTML, the other is an application of XML. There is a huge difference. The draconian error handling that Bruce mentioned is one.
This seems to be the most common reason. I have no problem with that, as long as the authors know what they're doing. Writing XML-style markup that doesn't work when served as an application of XML, though, that's bad.
I haven't heard that, myself, and I can't imagine how pretend-XHTML could break the web. I think bad pretend-XHTML â€“ the kind that must be served as <code>text/html</code> to work â€“ is harmful, but I don't think it will break the web. Mats Lindblad's comment about Google ads is a good example of where people try to use HTML-only methods like <code>document.write()</code> in an XML application.
W3C specification seems like a voodoo to me from time to time but as far as I can tell it states (http://www.w3.org/TR/xhtml-media-types/#summary) that XHTML 1.0 should be served as <code>application/xhtml+xml</code>, but it may be served as <code>text/html</code> as well. As long as we are talking about about well formed, validating code, <code>text/html</code> MIME type used doesn't make it invalid , it is just not preferable.
Great discussion! I also think that the draconian error handling is something you would never ever want to have in a real-life production environment (more about that in XHTML and error handling). There are ways to get around this, but it's usually too much of a hassle.
Therefore, and for other reasons such as personal preference, I lean to using HTML instead of XHTML when it's just my choice. However, when working with .NET-based projects, it's way too much work to get it to render HTML instead of XHTML (and that goes for accompanying WYSIWYG tools and their likes as well), so then you're usually stuck with XHTML.
At the end of the day, I would still say that my stance in HTML or XHTML? stands. Choose the one you seem fit, be aware of all the different variables, but whatever you choose, use a strict doctype.
Steven, I'd just like to pose one question: when you teach your students XHTML, and your motivation for that seems fair to me, do you also teach them about MIME types? Also, isn't it possible to teach HTML and XHTML parallel to each other, since there really are subtle differences?
XHTML 1.0 served as text/html is not necessarily invalid HTML, as long as it complies with Appendix C. In practice, your markup will be treated as regular HTML.
I know of one content management system that used Tidy to ensure the output is correct XHTML and allows me them to serve it at application/xhtml+xml. It's possible, but nobody really wants to do that. It's just not as accessible as HTML — which may or may not be a good thing.
Personally I'll stick to XHTML 1.0 Appendix C compliant, but if the HTML5/XHTML2.0 thing is a sign of the future, I'll likely fall back to HTML.
PS: Hixie's article is complete bs and uses the assumption of incompetent developers enforced by assuming worst case scenario's to generalize his opinion on XHTML.
@Krzychu: the document you refer to is an informational note. It's not a normative document, and it carries no more formal weight than if you or I were to write the same thing on our respective web sites.
That aside, the note says that you may serve XHTML as <code>text/html</code>, yes. What most people don't seem to understand is that if you do that, you are no longer using XHTML and you cannot use any XML-only benefits. From a user agent's point of view you are using HTML with errors in it. Anything served as <code>text/html</code> has to be parsed and interpreted as HTML, according to RFC 2854.
That's correct, but there'd be some really tough restrictions on it. The character encoding would have to be sent by the web server, and you couldn't use an external style sheet or link to related documents.
Because as soon as you use the NET syntax for a tag in the <code>head</code>, you're in trouble. When parsed as HTML, the NETSC delimiter (the '/') is seen as as NET delimiter, since XML uses an extension of SGML in this respect. In other words, the trailing greater-than sign isn't the end of the <code>meta</code> or <code>link</code> tag, but character data efter the tag.
Since HTML allows certain tags to be omitted, this character data will imply a start tag for the <code>body</code> element. That means any subsequent content in the <code>head</code>, plus the end tag for <code>head</code> and the start tag for <code>body</code> are invalid.
And even this presupposes a Transitional doctype. In a Strict doctype the content model for <code>body</code> doesn't allow <code>#PCDATA</code>, so already the greater-than sign would be invalid.
Fortunately, for all XHTML wannabes (j/k!), all mainstream browsers have parser bugs that let authors get away with this. It's still invalid HTML, though.
Alright, thanks for clearing that up for me. What do you suggest to do then? As I see it now, due to the lack of support for <code>application/xhtml+xml</code> in some browsers (I am referring to <abbr title="Internet Explorer">IE</abbr> of course, but not only – I am sure my Nokia phone default browser would choke on it as well), there is no other solution but to drop the XHTML altogether. It seems there is no way it can be implemented without content negotiation, while still complying to the W3C specification . And I see no point of using content negotiation if I can just choose HTML 4.01 Strict and have the same result.
Actually, now I think about it, I see no real advantage of using XHTML with <code>application/xhtml+xml</code> MIME type (even in browsers that can handle that).
1) Draconian error handling would make my life really miserable in a long run, as clients in most cases do not have the necessary knowledge to edit HTML, and what they really want is Paste from Word functionality.
3) Switching MIME type is one thing, switching stylesheets based on differences between rendering in XHTML and HTML is another.
I have never used an XML authoring tool to work with my XHTML markup so I do not know if it is really worth it.
Tommy, that's completely true, but it needs to be made clear that XHTML as text/html is not invalid HTML by default. Like you explained, the problem is much, much deeper. "Empty elements in SGML, HTML, XML and HTML" is a really good article talking about the different design problems related to empty elements.
We can talk about theoretical scenario's all we want though. Reality is, Appendix C allows many authors to gradually transition to a XHTML environment, whether it's the theory dictates it as invalid or not.
@Krzychu: I think the most honest thing is to use HTML 4.01 (Strict, of course).
If you'd rather use XML syntax, use XHTML 1.0 (Strict) and serve it as <code>text/html</code>. Don't bother with content negotiation, because it's pointless. The important thing, if you choose this path, is to make sure it also works as <code>application/xhtml+xml</code> in compliant browsers. If it doesn't, you should definitely use HTML instead.
This means you mustn't use <code>document.write()</code> with XHTML, even if you serve it as <code>text/html</code>.
An XHTML document may be served as HTML due to the lack of support in Internet Explorer, but that doesn't mean you may rely on HTML-only practices. If you want and/or need to do that, you must use HTML.
As if there aren't incompetent or even average developers. As HTML 5 points out, instead of wicked strict rules, we should have standardized error handling. Like you pointed out, it's far from obligatory, and could be tedious for some, to validate your code before publishing.
From my personal point of view it's easy to answer your question Robert.
The use of XHTML sent as application/xhtml+xml IMHO requires two stable and reliable things:
Browsers that supports the XML based MIME-type consistently and Tools that can consistently and reliably produce valid XHTML at all times.
None of these "foundations" are widespread enough to make a noticable difference in "XHTMLs favour" on the web today.
IMHO "proper" XHTML might very likely have caught on and spread to the mainstream if MS had added support for it five or six years ago when the hype actually *was* strong 😉
That didn't happen – now "everything" is seemingly moving towards text/html (look for example at the latest draft of XHTML 1.1 Second Edition – It now states clearly that text/html is an acceptable MIME type for XHTML 1.1 delivery… Same thing for XHTML MP / Basic. Same thing for HTML5… text/html is all the rage right now 😉 )
For me there's nothing strange that the effect of this (call it "text/html hype" if you will 😉 ) is a decrease of the practical *usefulness* of application/xhtml+xml. I still don't agree that its *pointless* though – but all things considering there is not much momentum pushing the use of it forward at the moment. That momentum is very much a fact in the "text/html part of the world" instead.
.. and in the end HTML5 will probably "take over" and in that context application/xhtml+xml might IMHO very likely end up being a "transitional practice" as some details looks for the moment… (but that's not the topic here, so I'll drop that line of thought)
So there it is. My answer…
* No solid and reliable support.
*The development momentum and web hype is focused on moving away from it.
When that started happening (IMHO this coincides with when HTML5 started gaining *real* public momentum) seems to me to be the turning point for application/xhtml+xml.
(On a humorus side note I find it a bit amusing in a weird way (and rather sad) that the "mother of crappy code generation" – MSWord – nowadays actually uses an XML based file format that inherently is dependent of the "draconian error handling of XML" every time it saves or reads a Word document, while we as a community (please note the generalistic intent of this comment and the strongly expressed absence of finger pointing here – I don't always manage it either 😉 ) still seems to have problems with the concept of being able to actually deliver 100% guaranteed correct and valid code – be it XML based or not 😉 )
Robert, in answer to your question not quite yet but they are nearly ready to understand that.
In context, my students are graphic design and animation certificate 4 which means they transition into their diploma year in February. I have 13 thursdays allocated to teaching them web design (I was invited in by the previous head of school rather than by application) as traditionally the previous students had all been taught DreamWeaver WYSIWYG and technical tricks in this timeslot.
This group, quite young and keen to learn, are being taught best practice web design from the start. Paul Boag's video the business case for web standards is a really good day 1 intro to the concepts. So my main focus throughout is to give them the tools to be able to create and recognise good design over crap tag soup. They accept validation as an important element. They also have to accept I am not going to spoon feed them every XHTML / CSS trick they could otherwise pick up from a decent tutorial.
So… I'm getting to the answer slowly sorry… I work them through the basics of XHTML and CSS over the first six weeks with a drizzle of everything important constantly raining on them during the day via discussion etc. They learn by developing themselves a small practical portfolio site so they can understand the benefits of best practice. I also very much labour accessibility and user centred design principles until they seem very full of new ideas and go home for the day… 🙂
At the moment they are involved in a 'soon to be real case' look at a large public sector redesign where they are pitching some design ideas (now understanding the technical constraints). This also introduces them to the complex world of compromise and complex information and diverse users as opposed to a six page portfolio.
We have about 5 weeks left of the course and I expect to sit them down in the second last week or so and put a lot of this into technical context. These are graphic designers not necessarily coders so much of my mission is to fill the gap between programmers and designers in the market – 2 groups which need to be talking the same language.
I'd like programming courses to take this opportunity to consider teaching a bit about gestalt principles, fitts law and the effects of perception etc in relation to design principles like the divine proportion. Anyway you get what I mean.
They are smart and curious kids and have the ability now to very quickly get up to speed with the basic syntax and structure of problem solving in that environment. Previous students really didn't cover usability, accessibility or web standards at all so I think its a big bonus to the industry these guys have the bridging skills to take into the work environment instead of DW on Photoshop. I made them all hand code from the very first day as well which is imperitive (but which many web design components don't seem to care about).
So the short answer is yes but not quite yet as I don't want to confuse the issue at this point. Not quite yet. Because it is complicated in some ways about how you put that advice forward – I want them to have all the knowledge to make that decision for themselves. After all they will be the people working with code in years to come when we're even beyond those technologies, its their transition.
I'm not sure if I'll be renewed for the teaching position next year as they now have a different head of school unfortunately who may not be web standards focused. I'm also looking for full time corporate work in Tasmania or mainland Australia from late november on so may not be available.
But teaching is rewarding. Its nice to know someone isn't going to be bashing their head in a design team trying to get one of these guys to understand these concepts. The world is a better place when that happens for us all. 🙂
While its tempting to spend more time on the pure coding aspects I think there is a lot more to this than technical ability in markup. A whole lot more. I want to generate creative thinkers who also possess technically correct foundations for a future career in this business – or at least understand it in context.
… and I'm also trying to work out how, in the time left and considering they don't have any idea about php, to give them a short sharp practical intro through a WordPress theme redesign…
which is where I'm hoping things will end up.
The use of XHTML sent as application/xhtml+xml IMHO requires two stable and reliable things:
Browsers that supports the XML based MIME-type consistently and Tools that can consistently and reliably produce valid XHTML at all times.
Absolutely. And who dares to have such strict error handling when you can't rely on the tools?
Word and XML is interesting, and a bit ironic. 🙂
Thank you very much for your reply. It wasn't meant to question what you have chosen to teach them, as you surely understood, but rather out of curiosity. Standardistas can breathe down your neck with advice how things should be done, but in teaching as well with the "real" world of delivering projects, one has to be realistic.
I think your approach sounds just fine, and that it's giving your students a ground as solid as possible in that time frame. My only wish I that you rather got two full years with them; imagine what you could do then! 🙂
Charles, the point I tried to make was that by using the existence of 'incompetent or average developers' or other worst case scenario's as a base for making the point of XHTML being harmful, then one needs to be fair and consider all other new technology harmful. Correct use of new technology is done through education, especially when you're dealing with complicated things such as markup languages. As such, one needs to factor in the simple fact that mistakes will be made. I think HTML's history is a perfect example of that.
It's not the right way to go about it. The draconian error handling on the other hand is a perfect argument, but it's still an argument applying to XHTML's error handling, not the use of XHTML of on its own.
My point exactly. I for one sure don't when I work for a client (mainly due to lacking support for it in modern CMS:es) – and I'm pro XHTML anyway 😉 I'm still convinced that the reason lies in the tols/browsers (lack of) XHTML support though – not in XHTML itself 😉
Imagine if you will a world where MS actually *did* come through with application/xhtml+xml support in MSIE back in, say, 2002 or so?
Then go on to imagine what eg. WordPress (as just one example among all the tools currently around that produced XTML from the start that has been introduced since then) might have had in terms of reliable "application/xhtml+xml"-support if that had happened (Development of WordPress started in 2003)…
Especially in the light of that back then so many of us were craving "proper XHTML" support and just waiting for widespread browser support before starting to deploy it…
Think about it 😉
substitute "XTML" with "XHTML" in the previous post
Robert, I'd be scared to go to work if I had them for two years – they'd pretty soon know a lot more than I do about web design.
If you can inspire someone's interest and feed them information they grow faster than I actually expected. Of course some experience will take them a lot further when they actually hit the workforce.
Some of the leaders in the battle taught some newbies like me… then they got tired and dropped out. Hi Tommy! How was your R&R? Nice to see you on the front lines again… sort of.
So we cocky young ones took up the flag and battle scared we stand today, weary and thinking of quiting. Some like Tommy still pop up once in a while, but we are handing it over to the next generation we taught to use HTML or XML XHTML.
But in the end there always seems to millions of newbies comming in. We are the bullwork they crash upon and chip away at us… some we convert or are open enough to listen… but back in the masses are second tier spies passing the tag soup either intentionally or religeously. More blogs and forums teaching it wrong then right. Too many outdated books being bought because they are old and cheap…and wrong.
I was crest fallen when Tommy dropped out. We have had comunications, but he was a hole in the deffenses.
At killersites.com we still get people thinking XHTML is replacing HTML and better than HTML. I explain and I think I win more often then I loose… but you get tired of reeating the same old mantra to the same old excuses and those who just do not get it.
Everything we can write has been written. Tommy wrote and i linked to it, I wote in my blog and Killersites forum and people read and maybe believe… but it has been written so often what is the reason of writing more and just repeating yourself?
I think the forces of standards, usability and accessibility and the basic "why not be different and do it right?" crowd have simply grown weary. Whay is this even an issue still in 2007? Because there is more bad info out there then good.
Would this be a good time to point out that the much cited Appendix C is non-normative? I agree by the way that it doesn't really matter much what you use though. As long as you realize that you're not using XML when you're sending it as text/html all should be fine.
<blockquote cite="">Also, the web is full of so many web sites with XHTML served as text/html instead of the proper application/xhtml+XML that it feels like not even a googol can describe it.
Is this not easy fixed on the server-side.
<blockquote cite="">As long as you realize that youâ€™re not using XML when youâ€™re sending it as text/html all should be fine.
When I need to use some xml I just need to add the right header. It is so easy!
To use a phrase from Mark Pilgrim: you must new here.
<blockquote cite="Anne van Kesteren">Would this be a good time to point out that the much cited Appendix C is non-normative?IMHO it absolutely would, if you at the same time point out that it is – in reality and common practice – *the* reliable "bag of tricks" you can use to bypass HTML error handling / parsing rules and make an HTML parser accept XHTML as if it were HTML without stumbling over its error handling.
Normative or not. It works 😉
I'm with LSW – Why this is still an issue in 2007 ? – Probably because there still more bad info than good out there – plus a very loud set of advocates for text/html (which – in itself is not a bad thing, since that movement has a lot of momentum and whatever comes out of it still looks mor promising than threatening if you ask me 😉 )
<blockquote cite="">To use a phrase from Mark Pilgrim: you must new here.`
Are we gonna quote computer geeks now…
I am talking about serving xml as xml in IE, i am not talking about XHTML and IE issues when using XML in a XHTML.
Good question. I've also wondered about it: It seems like everyone (that is, browser developers and the web developers) didn't care enugh when XHTML was new, and when no web developer seemed to adopt the technology the browser developers count it out. And when IE6 was released on this conditions, it was too late to stop caring about it since the world's popular web browser couldn't handle <code>application/xhtml+xml</code>.
If we are lucky, this will change as Firefox and others which supprt the type is taking market share.
At work and on sparetime, I serve my sites as <code>application/xhtml+xml</code> if the client support it (I exam HTTP_ACCEPT on the server side). Clients which do not support it get my documents as <code>text/html</code>.
By doing so, I am ready for judgement day when all browsers comes with support for real XHTML.
Another approach on it (sorry if this is mentioned before) is that the web2.0 philosophy, where user input is more important than ever, make it harder for developers. It is not nice that a not wellformed blog comment can and will crash a whole page. This is probably one of the things that fears front developers not fully familiar to validation and standards to work with it.
Well, I used to be agnostic about the issue. However, one experienced designer recently asked me to diagnose what seemed to be a CSS problem. The document validated as XHTML strict. However, the markup had a "self-closing" DIV in it – < div /> – that browsers saw as an opening DIV only. A subtle error that an HTML DOCTYPE would have avoided.
I think we need to be aware of such problems, particularly from the point of teaching web design. The subject is difficult enough to teach; having to point out XHTML subtleties like this may well confuse beginners.
just out of curiosity, forgive me for being naive about this – but when is a self-closing div useful?
i would have spanked the person responsible with a little paddle I keep behind the cupboard (tongue in cheek)… 🙂
but i am curious?
I already did. 😉
Overwhelmingly interesting! Thanks for commenting, people!
Is this not easy fixed on the server-side.
Well, yes and no. It could be, but there's a risk since there are some many different ways to combine your mark-up, so it has to be fairly advanced. What I mean is that it can be fixed but some of the expected output might be lost.
Also, it's a matter of performance. You wouldn't want to parse your every web page before it's being served, unless extremely necessary, which kind of leads to the point: is using XHTML necessary in thhat case then, if you can't trust the input, to at least some degree?
no takers on the explanation for using a self closing div?
For me the most significant advantage of xhtml over html is the xml namespaces. This allows me to include not only xhtml, but svg, rdf, owl and all those useful xml formats directly and still have a valid document. For example it is possible to include a full rdf representation of a creative commons licence directly into an xhtml document. So within an xhtml document such a license is valid content. Included into html as comment just includes a comment, nothing more.
OK, now that I answered to the original actual question I can add myself to the discussion at hand.
Self closing DIV, no idea, seems like wasted space and copde to me. Maybe being used for spacing? But either way, does not seem like a normal practice so thumbs up for catching it.
@ Siegfried – the point here is that you are using XHTML for what it is meant to be used for, when XML based languages are included. 99% of web sites using nothing like these languages.
@ reader – Again I have written this and argued it for years at Killersites and what it finally came down to is pointing it out, explaining it, and in most cases the designer old or new will understand and go to HTML. The rest choose to stay with XHTML Tag Soup which is fine with me as well.
The point being that the designer is making an informed choice. They understand what they are doing and choose to serve Tag Soup. The problem is that far to many people use XHTML Tag Soup because they do not know better, I certainly didn't till Tommy and Redux set me straight.
Once people realize that it should be XML, they find it to difficult to mess with or deal with real XML just to have their site break constantly by their mistakes or users.
I have found that explaining that XHTML is XML and meant to be served as XML and is only really needed when using SVG or MathML (or per Siegfried, a few more). Otherwise HTML is just fine. Most agree that HTML is easier and the correct language and change.
But we do have to many old books and new sortweare making XHTML tag soup the default and people simply do not know better.
I have always thought the real "Harm" in tag soup is that blind use of it by people who do not understand. It is keeping people dumb because they think it is real XHTML casue IE shows the page just fine.
@Steven: The self-closing DIV was an error. The point is, it validated, but browsers treated it as an opening DIV.
The point being that the error would have been discovered sooner had the DOCTYPE been HTML. It took a bit of explanation to the beginner as to why wrong markup validated. I'm not sure she ever really "got it".
Glad to hear it was a mistake…
Took me a moment to understand why it would validate too, but now I see the point… interesting, again, good catch, I doubt I would have caught that.
[…] FÃ¼r eine Seite, deren einziger Zweck die visuelle PrÃ¤sentation ist, ist HTML 3.2 genau richtig.Robert NymanWebdesignPermalinkIch habe bis auf Weiteres vor Allem aufgrund der Rechtssprechung davon Abstand […]
Indeed i do consider "xhtml" tag soup much worse than html. Xhtml offers many possibilities currently rarely known and as such offers access to a much wider space than html will ever be. But misusing xhtml establishes a wrong understanding of it. A misunderstanding that leads to thinking, xhtml is just a more complicated and less supported version of html, which it is definitely not.
So indeed if you use tag soup you should definitely use html. You should use xhtml if you at least plan to make use of the xml possibilities. If you're sure you'll never use all this xml, then better stick to html.
The main problem, I think, is that XHTML has been 'marketed' as HTML that looks like XML.
The truth is that XHTML1 is an application of XML that happens to share the same set of element types and attributes as HTML4.
I don't mean to sound Ã©litist or rude, but those who do not understand the difference really shouldn't try to use XHTML (even serving it as <code>text/html</code>).
Somehow, even though I speak German, that last bit above Tommy doesn't really make any sense.
For those who do not:
"For a web page whos only reason is visual presentation, then HTML 3.2 is the right choice. Robert Nyman Webdesign Permalink. I have distanced myself from the rest due to copyright issues."
I personally would like to know what year this quote is from, it would explain at least the reference to HTML 3.2.
Is it any wonder why application/XHTML+XML is not widespread?
Because if you try to move toward true XHTML — try to advance the core vision — try expanding the internet's semantic possibilities — and also try to accommodate 80% of the internet's user agents that don't support it, then you get elitists attacking you — accusing you of serving up pretend xhtml and telling you that you don't understand and that you were tricked into thinking it was better and that the w3c workaround is not normative even though Google won't index your site unless you serve it up with text/html.
Is it any wonder?
@Carl: are you saying that XHTML served as <code>text/html</code> isn't pretend-XHTML? If so, please explain how it can be real XHTML.
Also, please point to where the note about XHTML and MIME types is declared as normative.
I'm not ashamed to admit that I'm wrong, but I'd like some hard evidence before making such an admission. 🙂
Tommy, who elected you sheriff of the Web? Instead of telling people what not to do, why don't you spend a bit more time teaching people about the options available to them and how to use each option correctly. Writing articles entitled "XHTML is dead" is not education – it's propaganda! Shame on you.
Then read more Christine, Tommy has written much on what options and how to do things right. Between his blog, articles and forums he has been doing much of what you suggest. One article, especialy one articles title is hardly something to judge by.
If he is spouting only propaganda, then so is likely most of those writing here and all the bigger names in web design standards.
I guess I did come across as Ã©litist and rude after all. 🙁
Believe me, I am trying to describe and explain. The 'XHTML is dead' article isn't propaganda â€“ if you read it you will see that it attempts to explain why XHTML will never work as intended and why there is no real point in using it for the large majority of authors.
I've written other posts on my blog (and elsewhere) where I try to explain the fundamental differences between HTML and XHTML that many people are unaware of.
I've written long posts on SitePoint Forums, like the XHTML vs HTML FAQ, which was actually voted 'Most Helpful Thread of the Year' (2006) by the forum members. So I do try to help.
Why don't I spend even more time on this? In part because I don't have the time to spend; in part because very few people care to listen.
That trackback seemed to be from one of my articles. Unfortunately one that got messed up somehow. Don't know how.
Tommy, my issue is not with you not spending more time teaching, my issue is with your interpretation of the specs and your bias in your teachings. All your articles steer people away from XHTML and towards HTML.
I will say this, be careful what you wish for. Tommy, you and others who criticized XHTML have succeeded in influencing W3C to resurrect HTML, with all its faults. Now the <code>alt</code> attribute is optional and a slew of other accessibility features are on the chopping board. This has set accessibility back at least 10 years. Well done!!!
Christine, you don't really believe that my opinions influence W3C, do you?
And what are the faults in HTML that don't exist in XHTML? They are identical, content wise. It's all a matter of syntax. The only realy difference is that XHTML (real, not pretend) can include elements from other XML namespaces, but the real-world applications of that are scarce since the semantics of those namespaces are unknown to user agents.
First of all, the <code>alt</code> attribute is not optional. There are rumours that this stupidity will occur in HTML5 (and XHTML5), but that's many years into the future. In current specs the attribute is required.
Although I think the proposal is extremely stupid, I don't agree that it will set accessibility back 10 years. Why? Because the <code>alt</code> attribute is required in today's standards, yet a lot of people omit it. Even worse, most of those who don't omit it use it incorrectly.
I've been practicing accessible web design and development for five years. I'm writing about it on my blog and I'm giving lectures to anyone who wants to listen. I've also been very critical against the HTML5 working group because of their disregard for semantics and accessibility. Your saying 'Well done' to me for their ignorance doesn't make sense.
And since XHTML5 is also being developed by the same people, the <code>alt</code> attribute will be optional in the next version of XHTML, too. Well done, Christine. 😉
Yes, I do. Your opinions influenced hundreds of people who then go on to influences hundreds more. Which then gives fuel to people like Ian and Anne. It's called the Butterfly Effect.
This is not a rumor. The current draft of HTML5 has the alt attribute optional.
3 years is not that far away. Browser vendors are already implementing some features in HTML5 while HTML5 is still in draft stage. But once the spec reaches Candidate Recommendation a year from now, it will be very hard to change anything. Here is the schedule:
2008 Q2: Last Call Working Draft
2008 Q3: Candidate Recommendation
2010 Q2: Proposed Recommendation
2010 Q3: Recommendation
This is exactly the problem I have with your teachings. You only look at the technical side of things. There is a social side to this that you are missing. XHTML has a culture around it where people try to write better markup, they try to learn how elements are supposed to be used. People try harder when they use XHTML. I can tell you that if the next markup language was called XHTML 1.2 instead of HTML5, then there would not be a debate about the <code>alt</code> attribute.
When you attack XHTML, you are not attacking the technical merits of XHTML, you are killing the culture around XHTML which is part of the same culture that fueled the Web standards movement and Web accessibility. Please, look at the big picture.
That's the point: it's a draft. No-one knows what it will contain when (if?) it becomes a W3C recommendation. And since Microsoft still don't implement all of HTML4, I think there's no immediate danger.
Besides, this only applies to people who know enough to validate their markup. If they're that clued in, there's a good chance that they'll understand the importance of text equivalents, too. At least if we keep reminding them.
When it comes to markup, yes, I do. I don't think the choice of markup should be emotional. Emotions come into design and into the content, but markup is engineering. Both sides are equally important.
Do you have any objective proof to support that statement, Christine? Because I've seen plenty of evidence to the contrary. People believe that XHTML is a new version of HTML and they keep abusing it the way HTML has been (and still is) abused.
First of all, I'm not 'attacking' XHTML at all. If you look at my blog, using an XHTML-compliant browser, you'll see that I currently use XHTML. That may change if I ever find the time to rewrite the system, but right now it uses silly content negotiation.
What I'm trying to do is to teach people that there is a major difference between HTML and XHTML, so that they don't believe you can just go on as before after turning of CapsLock and sprinkling a few slashes throughout the markup.
I'm not even saying that it's bad to write XHTML markup and then serve it as <code>text/html</code>. That's fine. Pointless (from a technical perspective), but fine. As long as it still works when served as real XHTML! And that's where 99% of the authors fail, thus writing 'XHTML' that must be served and parsed as tag soup.
The reason many people believe that XHTML is synonymous to web standards is because people lie to them and say that XHTML markup is more semantic, more strict and whatnot (without, of course, mentioning a word about MIME types).
I prefer to tell people that you can write equally standards-compliant, strict and accessible markup using HTML 4.01. I also like to tell people that XHTML is far more difficult than they may have been led to believe. Then they can make an informed choice â€“ not one based on lies and propaganda.
Do you think it's better to keep lying to people and say that XHTML is more semantic or more strict? That it will be parsed faster even if served as <code>text/html</code>? What good will that do anyone?
Tommy, I bet you're the kind of guy who enjoys telling children there is no Santa Clause. 🙁
Tommy, you seem to be overly concerned with how the web works today. Who cares if today people are writing invalid XHTML and serving it as <code>text/html</code>? Who cares if today people are writing valid XHTML and serving it as <code>application/xhtml+xml</code>? Really, today, who cares?
XHTML 1.x is a transitional spec. Think of it as practice for an XML based web. You, Anne, Ian and other XHTML haters are getting all worked up over something that was always meant to be temporary.
The big picture is what will replace XHTML 1.x and how do we get there. So, what kind of web do you want to have 10 years from now? That is what is important. That is what is worth fighting for. Social and technological change does not happen over night. You need to have a long-term view.
Every time you and others put down XHTML, you are voting for HTML (and the culture around HTML). And W3C is listening. So you helped influence the future direction markup is taking – HTML5. So I am back to my original comment – well done Tommy. But you can sleep well at night because you were "honest" in your teachings.
You seem very quick to judge someone you've never even met, Christine. No, I wouldn't dream of depriving a child of Santa. I might, however, consider an adult believing in Santa Clause to be a bit odd.
You're not really listening to me, are you, Christine? If you read the 'XHTML is dead' article, you'll see that worries for the future is what it's all about. People relying on HTML-only practices in their purported XHTML today is making it more and more difficult to switch over to a working, real XHTML tomorrow.
And please stop calling me an XHTML hater. I'm not. I just want people to use it properly.
XML is not suited for web pages. It's a format for data storage and transmission. The draconian error handling means the author must guarantee well-formedness. In conjunction with 'Web 2.0' â€“ user-supplied content â€“ it's an equation that's hard to balance, unless today's authoring tools and CMSs become a lot better.
The funny thing is that 99.9% of the XHTML proponents aren't using XHTML at all. They're using invalid HTML, thinking that they are cooler than the rest. So unless you are serving your pages as <code>application/xhtml+xml</code>, don't disparage HTML, because that's what you are using.
Checkpoint 11.1 in WCAG 1.0 says that we should use the latest version of W3C technologies that are supported. For any public-facing website today, and for the foreseeable future, that means HTML 4.01.
Unless you need to mix in elements from another XML namespace, XHTML does not offer anything over HTML. It's not more semantic and it's not more strict. It's only a lot more difficult.
You seem to believe that HTML means tag soup. Valid HTML is just as strict as valid XHTML. The syntax rules are different, but neither one is stricter than the other.
Christine, instead of spreading FUD about how bad HTML is, why don't you try a little honesty in your XHTML preachings?
You're right in 1 important point: People generally think of xhtml just as the newer version of html and continue to abuse it. This is (besides namespaces) one of the points for which i consider serving xhtml as text/html dangerous. As long as you don't change the basic thinking, there is no need, no pressure, to stop abusing html. Unfortunately the IE is another very big showstopper here. So i think the current awful behaviour will not change within the next few years.
But the current abusing of (x)html is no argument against xhtml or html. It's just a fact. It is illegal to conclude xhtml worse than html because with html it is easier to abuse markup. O.k., fact is, it is easier. But fact is, too, that continuing to abuse markup will lead to nowhere and is absolutely not desireable.
So what Christine wrote about this xhtml culture, it is small but existing. The majority of xhtml coders still abuse markup like at the times of html 3.2. You won't change this, and i won't change this either. But there indeed is a minority of coders that got the vision and understanding of a better web. Timbl's vision of the semantic web is just the tip of the iceberg. It is the way to go. And it's not helpful pretending xhtml worse than html because in xhtml it is harder (or maybe in future impossible) to abuse it. The future is not html 5.0. This will just be the next step, but it will not lead very much further. The future is xhtml 2.0, massively combined with rdf and other xml. This will enable far more than current mashups and will move the web away from single pages just meant for visual rendering to a general data and information storage combineable to anything you want. The future will be a web page assembled by the client on the fly out of machine-understandable xml data. A prerequisite for this is a completely new thinking about what the web is and how to publish information on the web.
Of course this contradics current advertising practice. Since advertising is an important part of the web we'll see such pages for quite some time.
Christine… those who write it wrong today will continue to write it wrong tomorrow because that is the way they always have done it and to do otherwise means relearning it AND admiting they were wrong, something many developers have a problem with.
As far as a Transitional spec… who cares, what matters if what is happing today. XML may not be the big language everyone always told us it would be. But to write it right, means thousands of broken web sites and writing it wrong today means trying to teach these people to do it right years down the road.
It sounds like you are actually suggesting that we either teach or allow people to write it wrong. Where is the logic of allowing people to do something wrong today based on tomorrow. Will it be easier to teach them to do it right later after years of doing it wrong?
HTML is a current standard and 20 years from now we may not have either language, we do not know. If there is no XHTML language invlved then there is no reason to use XHTML so long as HTML is still a standard. It means nothing if it is HTML 4.01, HTML 5 or HTML 9.
"Long live Python, it will revolutionize the web" – My Python teacher in Potsdam Germany, 2000. In 8 years I have seen 4 Job openings list Python, 3 in Germany and one in the US. Seems to me that XML is not as far as it was expected to be at this point.
That's true, but only for real XHTML. Pretend-XHTML is nothing but badly written HTML, as far as user agents are concerned, which means it's just as 'easy to abuse' as honest HTML.
In fact I'd say it's much easier to abuse XHTML (when serving it as <code>text/html</code>) because there will be no feedback from user agents (or the validator) telling you when you make serious mistakes, like using <code>document.write()</code> or assuming an implicit <code>tbody</code> in a table.
Tommy, I know that nothing I say will change your mind. So I will withdraw from his conversation. Feel free to have the last word.
Robert, maybe you can have a post on "the culture of HTML versus XHTML". Maybe it can help determine if people who use XHTML try harder. The keyword being: "try". And if XHTML supporter were in charge of the next markup language, would they take web accessibility more seriously than the HTML5 people? Would XHTML people follow cow paths or make new paths? I think it would make for an interesting discussion.
By the way Robert, I love your photos. You have a lovely family.
As you've probably noticed, I decided not to get too involved in tis discussion. Not that it's not interesting, but rather that other people say very good things that are about the same as I would.
So, great discussion, and thanks for contributing!
Thank you! 🙂
<blockquote cite="Tommy Olsson">I might, however, consider an adult believing in Santa Clause to be a bit odd.
Damn, you've crushed my beliefs I thought it was rather normal myself…
Really it is about time "certain browser vendors" caught-up and started supporting HTML 4.01 correctly.
People haven't stopped caring it is just that most have tired of flogging a dead horse.
Christine, let's agree to disagree, eh?
I'm not looking to get in the last word, but I'd like to point out that the HTML5 working group is also creating the next version of XHTML â€“ XHTML5. So no matter if HTML or XHTML will prevail, it will still be a blow to accessibility.
That has nothing to do with HTML vs XHTML. It's to do with the working group's disregard for people's needs and with their incomprehensible decision to base the future markup languages on how earlier versions have been used by people who couldn't possibly care less about semantics, standards or accessibility.
I personally think that's a much more important battle to fight than whether or not you should sprinkle a few slashes throughout your markup. At least it seems as if you and I could fight side by side in that battle. 🙂
What's a wet-behind-the-ears youngster like yourself doing on a blog for grown-ups anyway, Robert? 😉
Besides, you're from Yorkshire, which means you cannot be considered normal in any known sense of the word. 😀
I've recently started learning how to code a web page and bought a book called 'Build Your Own web Site The Right Way Using HTML & CSS', published by sitepoint.
It was recommended to me as being a good text to learn how to code according to W3C standards and to avoid picking up bad habits (which is why I wasn't recommended one of those Bible/24 hour type books).
However, the author uses DTD XHTML 1.0 Strict and publishes the content as text/html in his examples.
I've read a few articles, posts and FAQs including Tommy Olsson's 'XHTML vs HTML FAQ' and I thought that perhaps I should use HTML 4.01 Strict as text/html.
So my question is, can I continue to use this book and just use DTD HTML 4.01 Strict as text/html (as HTML 4.01 and XHTML 1.0 are quite similar from what I understand)?
Sorry for the noob question, but I'm learning a lot!
Without really knowing anything about the book's content, I think you would be fairly safe off using HTML 4.01 Strict. Unless they use any examples that actually requires XML format to work, that is.
Most likely, though, it's just a matter of semantics since many tutorials use XHTML served as <code>text/html</code>. A great way to learn, however, is to write HTML 4, and then switch it to XHTML (basically by just adding closing slashes on single elements such as <code>img</code>, <ocde>input</code> etc) and serve it as <code>application/xhtml+xml</code>.
This way you will learn the differences, where things break etc.
Thanks for the advice Robert!
I suspect you're right, it is semantics as I've seen a lot of similar DTD XHTML 1.0 as text/html tutorials all over the place.
Also, I'll be sure to check your blog regularly as I'm sure I could learn a lot from it (I actually found a link to it from a discussion on XHTML vs HTML on the killersites.com forum).
Actually xhtml CAN be served to Internet Explorer by using a .xsl stylesheet above your doctype and serving it as application/xml. Your webpages will throw an xml error in IE as well if it is not well formed. See my article on how to serve xhtml as xml to Internet Explorer to see why.