75 comments

• RSS feed for comments on this post
• RSS feed for comments on all posts

• Steven Clark
  October 2nd, 2007 at 23:48

  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…

• André Luís
  October 3rd, 2007 at 2:00

  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 Accept 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.

• Erik
  October 3rd, 2007 at 4:08

  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

• Tommy Olsson
  October 3rd, 2007 at 7:32

  Oh, great! I wrote a long comment but it seems to have been eaten by your blog software.

• Krzychu Danek
  October 3rd, 2007 at 9:17

  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 text/html. 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 CMS 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?

• Siegfried
  October 3rd, 2007 at 11:23

  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.

• Tommy Olsson
  October 3rd, 2007 at 12:30

  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,

  What is more, I do not really see any benefit of using it as in opposed to text/html.

  If you don’t see that, I’d be interested in learning what benefits you do see of using XHTML over HTML. Very interested.

• Sebastian Redl
  October 3rd, 2007 at 12:55

  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.

• Mats Lindblad
  October 3rd, 2007 at 13:31

  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 …

• Krzychu Danek
  October 3rd, 2007 at 15:49

  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 input, img or meta).
  Still, at the end of the day, does it really matter if you choose HTML or XHTML served either as text/html or application/xhtml+XML, 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 application/xhtml+XML, please do.

• bruce
  October 3rd, 2007 at 21:00

  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?

• bruce
  October 3rd, 2007 at 21:06

  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.

• Steven Clark
  October 3rd, 2007 at 23:09

  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?

• Tommy Olsson
  October 4th, 2007 at 7:14

  Still, at the end of the day, does it really matter if you choose HTML or XHTML served either as text/html or application/xhtml+XML, as long as you make sure it validates?

  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.

  Simple: I prefer it. I find it aesthetically more pleasing.

  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 also don’t get what the ‘breaking the web’ statement was about. How does XHTML served as text/html break the web?

  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 text/html 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 document.write() in an XML application.

• Krzychu Danek
  October 4th, 2007 at 9:30

  Yes, it matters a lot. The former is invalid HTML, the other is an application of XML. There is a huge difference.

  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 application/xhtml+XML, but it may be served as text/html as well. As long as we are talking about about well formed, validating code, text/html MIME type used doesn’t make it invalid , it is just not preferable.
  What is more I don’t think that document.write() is a good example of misunderstanding XHTML. It’s a good example of misunderstanding how JavaScript works with XML. You can’t blame the markup for writing bad scripts.

• Robert Nyman - author
  October 4th, 2007 at 9:37

  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?

• Jeroen Mulder
  October 4th, 2007 at 11:41

  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.

• Tommy Olsson
  October 4th, 2007 at 14:13

  @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 text/html, 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 text/html has to be parsed and interpreted as HTML, according to RFC 2854.

  1.0 served as text/html is not necessarily invalid HTML, as long as it complies with Appendix C.

  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 head, 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 meta or link 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 body element. That means any subsequent content in the head, plus the end tag for head and the start tag for body are invalid.

  And even this presupposes a Transitional doctype. In a Strict doctype the content model for body doesn’t allow #PCDATA, 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.

• Krzychu Danek
  October 4th, 2007 at 15:38

  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 application/xhtml+XML in some browsers (I am referring to IE 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 application/xhtml+XML 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.
  2) It would be impossible to place some advertisements based on JavaScript document.write()
  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.

• Jeroen Mulder
  October 4th, 2007 at 15:51

  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.

• Tommy Olsson
  October 4th, 2007 at 18:51

  @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 text/html. 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 application/xhtml+XML in compliant browsers. If it doesn’t, you should definitely use HTML instead.

  This means you mustn’t use document.write() with XHTML, even if you serve it as text/html.

  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.

• charles
  October 4th, 2007 at 21:37

  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.

  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.

• Jarvklo
  October 4th, 2007 at 21:52

  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.

  Cheers

  (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 )

• Steven Clark
  October 4th, 2007 at 23:23

  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.

• Steven Clark
  October 4th, 2007 at 23:29

  … 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.

• Robert Nyman - author
  October 5th, 2007 at 9:00

  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.

  Steven,

  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!

• Jeroen Mulder
  October 5th, 2007 at 9:35

  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.

  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.

• Jarvklo
  October 5th, 2007 at 10:19

  Absolutely. And who dares to have such strict error handling when you can’t rely on the tools?

  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

• Jarvklo
  October 5th, 2007 at 13:00

  Ooops!
  substitute “XTML” with “XHTML” in the previous post
  :r

• Steven Clark
  October 5th, 2007 at 13:13

  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.

• LSW
  October 6th, 2007 at 1:27

  Shell Shock

  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.

• Anne van Kesteren
  October 6th, 2007 at 11:15

  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.

• Johan
  October 6th, 2007 at 23:35

  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.

• Johan
  October 6th, 2007 at 23:36

  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!

• Anne van Kesteren
  October 7th, 2007 at 11:19

  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.

• Jarvklo
  October 7th, 2007 at 12:19

  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 )
  Cheers

• JOhan
  October 7th, 2007 at 12:30

  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.

• madr
  October 7th, 2007 at 16:39

  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 application/xhtml+XML.

  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 application/xhtml+XML if the client support it (I exam HTTP_ACCEPT on the server side). Clients which do not support it get my documents as text/html.

  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.

• David Hucklesby
  October 7th, 2007 at 22:23

  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.

• Steven Clark
  October 7th, 2007 at 22:54

  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?

• Tommy Olsson
  October 8th, 2007 at 8:58

  Would this be a good time to point out that the much cited Appendix C is non-normative?

  I already did.

• Robert Nyman - author
  October 8th, 2007 at 9:48

  Overwhelmingly interesting! Thanks for commenting, people!

  Johan,

  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?

• Steven Clark
  October 8th, 2007 at 11:23

  no takers on the explanation for using a self closing div?

  going… going…

• Siegfried
  October 8th, 2007 at 15:29

  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.

• LSW
  October 8th, 2007 at 20:06

  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.

• David Hucklesby
  October 8th, 2007 at 20:54

  @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”.

• LSW
  October 8th, 2007 at 21:21

  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.

• Siegfried
  October 9th, 2007 at 10:05

  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.

• HTML? Welche Version?
  October 9th, 2007 at 10:23

  […] 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 […]

• Tommy Olsson
  October 9th, 2007 at 10:27

  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 text/html).

• LSW
  October 9th, 2007 at 18:54

  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.

• Carl Camera
  October 9th, 2007 at 20:08

  Hey Robert.

  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?

• Tommy Olsson
  October 10th, 2007 at 18:31

  @Carl: are you saying that XHTML served as text/html 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.

• Christine
  October 10th, 2007 at 23:22

  Tommy wrote:

  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 text/html).

  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.

• LSW
  October 10th, 2007 at 23:50

  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.

• Tommy Olsson
  October 11th, 2007 at 7:43

  Tommy, who elected you sheriff of the Web?

  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.

• Siegfried
  October 11th, 2007 at 14:31

  That trackback seemed to be from one of my articles. Unfortunately one that got messed up somehow. Don’t know how.

• Christine
  October 11th, 2007 at 18:39

  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 alt 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!!!

• Tommy Olsson
  October 12th, 2007 at 7:33

  Tommy, you and others who criticized XHTML have succeeded in influencing W3C to resurrect HTML, with all its faults.

  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.

  Now the alt 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!!!

  First of all, the alt 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 alt 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 alt attribute will be optional in the next version of XHTML, too. Well done, Christine.

• Christine
  October 12th, 2007 at 18:34

  Tommy wrote:

  you don’t really believe that my opinions influence W3C, do you?

  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.

  Tommy wrote:

  First of all, the alt attribute is not optional. There are rumours that this stupidity will occur in HTML5

  This is not a rumor. The current draft of HTML5 has the alt attribute optional.

  Tommy wrote:

  but that’s many years into the future.

  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

  Tommy wrote:

  And what are the faults in HTML that don’t exist in XHTML?

  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 alt 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.

• Tommy Olsson
  October 13th, 2007 at 20:45

  This is not a rumor. The current draft of HTML5 has the alt attribute optional.

  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.

  This is exactly the problem I have with your teachings. You only look at the technical side of things.

  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.

  XHTML has a culture around it where people try to write better markup, they try to learn how elements are supposed to be used.

  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.

  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.

  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 text/html. 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 text/html? What good will that do anyone?

• Christine
  October 14th, 2007 at 2:12

  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 text/html? Who cares if today people are writing valid XHTML and serving it as application/xhtml+XML? 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.

• Tommy Olsson
  October 15th, 2007 at 7:42

  Tommy, I bet you’re the kind of guy who enjoys telling children there is no Santa Clause.

  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.

  Tommy, you seem to be overly concerned with how the web works today.

  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 ju