In defense of web developers

It has only been a few days but I am already sick of the “XHTML is bullshit, man!” crowd using the cessation of XHTML 2.0 activity to condescend to—or even childishly glory in the “folly” of—web developers who build with XHTML 1.0, a stable W3C recommendation for nearly ten years, and one that will continue to work indefinitely.

A coterie of well-informed codemeisters, from ppk to Ian Hickson, has always had legit beefs with XHTML, the most persuasive of which was Hickson’s:

It is suggested that HTML delivered as text/html is broken and XHTML delivered as text/xml is risky, so authors intending their work for public consumption should stick to HTML 4.01, and authors who wish to use XHTML should deliver their markup as application/xhtml+xml.

This problem always struck me as more theoretical than real, but I pointed it out in every edition of Designing With Web Standards and left it to the reader to decide. When I wrote the first edition of the book, some versions of Mozilla and IE would go into Quirksmode in the presence of HTML 4, breaking CSS layouts. To me, that was a worse problem than whatever was supposed to be scary or bad about using well-formed XHTML syntax while delivering it as HTML all browsers could support.

The opportunity to rethink markup

The social benefit of rethinking markup sealed the deal. XHTML’s introduction in 2000, and its emphasis on rules of construction, gave web standards evangelists like me a platform on which to hook a program of semantic markup replacing the bloated and unsustainable tag soup of the day. The web is better for this and always will be, and there is much still to do, as many people who create websites still have not heard the call.

A few who became disenchanted with XHTML early retreated to HTML 4, and as browsers stopped going into Quirksmode in its presence, valid, structural HTML 4 became a reasonable option again. But both HTML 4 and XHTML 1 were document languages, not transactional languages. They were all noun, and almost no verb. So Ian Hickson, XHTML’s biggest critic, fathered HTML 5, an action-oriented toddler specification that won’t reach adulthood until 2022, although some of it can be used today.

And guess what? HTML 5 is as controversial today as XHTML was in 2000, and there are just as many people who worry that a specification of which they don’t entirely approve is being shoved down their throats by an “uncaring elite.” Only this time, instead of the W3C, the “uncaring elite” is Mr Hickson, with W3C rubber stamp, and input from browser makers, including his employer.

XHTML not dead

All of this is to say that XHTML is not dead (XHTML 2 is dead, thank goodness), and HTML 5 is not here yet. Between now and 2022, we have plenty of time to learn about HTML 5 and contribute to the discussion—and browser makers have 13 years to get it right. Which is also to say all of us—not just those who long ago retreated to HTML 4, or who became fans of HTML 5 before it could even say “Mama”—are entitled to be pleased that standard markup activity will now have a single focus, rather than a dual one (with XHTML 2 the dog spec that no one was willing to mercy-kill until now).

Entitled to be pleased is not the same as entitled to gloat and name call. As DN put it in comment-44126:

What is really rather aggravating is how many people are using this news as a stick with which to beat any developer or freelancer who’s had the audacity to study up on and use XHTML in good faith–or even, much to the horror of the Smug Knowbetters, admire XHTML’s intelligible markup structure–for the brand-new-minted sin of doing the most with XHTML that’s possible. The ‘unofficial Q&A’ is ripe with that kind of condescension. …[D]on’t pin users (front-end developers are merely users of specifications) with Microsoft’s failure to support the correct MIME type.

Read more

  • Web Fonts, HTML 5 Roundup: Worthwhile reading on the hot new web font proposals, and on HTML 5/CSS 3 basics, plus a demo of advanced HTML 5 trickery. — 20 July 2009
  • HTML 5: Nav Ambiguity Resolved. An e-mail from Chairman Hickson resolves an ambiguity in the nav element of HTML 5. What does that mean in English? Glad you asked! — 13 July 2009
  • Web Standards Secret Sauce: Even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. Thanks largely to the success of the iPhone, Webkit, in the form of Safari, has been a surprising force for good on the web, raising people’s expectations about what a web browser can and should do, and what a web page should look like. — 12 July 2009
  • XHTML DOA WTF: The web’s future isn’t what the web’s past cracked it up to be. — 2 July 2009

[tags]HTML, HTML5, W3C, WTF, XHTML, XML[/tags]

249 thoughts on “In defense of web developers

  1. Nowt wrong with XHTML 1. I used it (with a transitional DOCTYPE) until I had an experimental HTML 5 redesign. For other “consumer” sites I have, I continue to use XHTML 1.

    I thought XHTML 2 spec was a blind alley because it was completely unimplementable, although philosophically pure. I’m not sorry to see it go.

    And you can still use XHTML 5, or make polyglot documents to serve as XML to modern browsers, and as HTML to less adept ones.

  2. I don’t think I’ll write markup for the rest of my life!
    on 2022 I’ll have people writing markup for me :D

    LOL

    XHTML FTW!!!

  3. It struck me too that over the last few days XHTML had become the target of much critique. How could we ever have been so stupid to adopt it as our preferred syntax?

    For me it was always a more personal choice: I simply loved the more strict nature of XHTML. And switching from HTML to XHTML was the perfect catharsis to leave behind not only the old syntax, but more important the old habits and practices of building a webpage.

    Say nothing but good of the dead? Not so for XHTML apparently.

  4. See, to me this is still an excuse. It has nothing to do with IE not supporting the proper mime-type. So what if it did? The majority of people up in arms about it only ever needed text/html. They used XHTML to ‘enforce strict standards’ – as if you couldn’t do the same in HTML4. I am still waiting for an example of someone truly using XHTML for a purpose other than text/html, and I haven’t been able to find it. I am genuinely interested to see examples of people using it.

    It’s not about beating people with a stick, it’s about the frustration of everyone blindly following ‘web standards’ without understanding the decisions they made. Many made the decision because _you_ were the founding father of web standards, and that’s fine – I did the same in the beginning but then did research and chose to stay with HTML4 Strict. I just wish the people using XHTML had a more intelligent response than ‘Oh, it’s IE’s fault’ or ‘It makes my code valid’. These aren’t real reasons – I am more interested in the meat of the issue for all of these people complaining about XHTML2 being dead: when were you really needing anything other than a mimetype of text/html?

  5. While I have been playing with HTML5 , and I am currently building a website with it. (the demographic allows html5) I agree that some people are going overboard. The flood of tweets claiming XHTML was dead because it was dropped by the W3C was amusing to say the least. It appears that many people are under the misconception that this meant ALL XHTML. It seems that some do not know what version of XHTML they are using.

    Nice write up. Curious, what is your take on HTML5?

  6. Once again you have given form to multiple amorphous critiques and complaints. I wish I had something intelligle to contribute, but at least I look forward to being able to follow the discussion, now that I have a clearer sense of the players. Thank you.

  7. My biggest concern with most people who jumped on the XHTML bandwagon did so without fully understanding the implications of their choices. They loved whatever perceived strictness the syntax offered but still lived in a fault-tolerant world of HTML. Most people who have their sites running as XHTML normally did so in a way that would break every page on their entire site had it actually been served up using the stricter and more proper mime type. Those who extolled the virtues of XHTML1 seemed to do so at the expense of HTML4 as if it was some hideous beast to be shunned.

    I went back to HTML4.01 Strict a long time ago because I saw no perceived benefits to using XHTML. Now, however, I believe you make an excellent point: it taught a generation of developers what good code should or could look like. It was something that was always possible in HTML4 but XHTML1 helped train people to be more thoughtful and careful with their code. And in that sense, I think it was a success.

  8. It is obvious that we front end developers will have to stick with XHTML untill we get the green light from people like you Jeffrey.
    Now as we all know the all IE thing is just a matter of time untill IE 7 reach the same status has ie 6 has now because we will have 60% of people with IE 7 on their machines and this won’t support any HTML5(my guess).
    Anyway we will need to keep sensible and stick with XHTML.

    thanks for nice post

  9. I fall into that camp of developers who appreciates web standards, but doesn’t spend all day pouring over w3c specs. It seems to me the best thing we’ve gained from xhtml & CSS is a more stable DOM and the ability to separate style from structure in a meaningful way. I don’t know how anyone can argue, with a straight face, that the more semantic and strict structure of xhtml is a bad thing. Especially if you go back and look at the tag soup of early 90’s websites.

    Guess I’m a little confused about the argument between xhtml 2 and html 5. Like, I don’t see why we can’t create semantic documents in html5… is the argument simply that because html does allow a more loose structure, that it’s pushing things backwards?

  10. Wow, don’t I feel an idiot for reading books and websites and trying to keep up with the best practices of the day. What’s the point of that, eh?

    Maybe I’ll go back to writing tag-soup webpages in HTML4 and throw out everything I’ve taken on board about code clarity, semantics and separation of content from presentation.

    … because in 2022 something new will be along, my existing websites will continue to work, and I’ll have some new tools at my disposal.

    ( THIRTEEN FRICKIN’ YEARS?!?!? )

    Yessir, back to tables and font tags for me.

    *facepalm*

  11. Just because something new has come about, doesn’t mean that the old is bad and those who worked on the old were sinners. Quite frankly, I don’t yet fully grasp what is so terrifically great about html5, I prefer my Xhtml.

  12. Very well said.

    I’m one of those web developers who uses XHTML1. Yes, I know the issues surrounding text/html v. text/xml however as a developer I like the strictness of the syntax and can see the value of that alone.

    With regard to HTML5, finding out what is happening and contributing to that where appropriate is of course very important, as is starting to try out things that currently work in browsers where you can. However, I build websites and applications today, so am mostly concerned with what works right now. XHTML1 is still a perfectly valid choice, as is HTML4.01. I would maintain that the most important thing is that you validate to a Strict DOCTYPE. XHTML or HTML at this point is really just personal choice – or might be dictated by the site you are working on or some other application you are integrating with.

    XHTML is not dead nor is using it wrong. It remains a valid choice until we can start to use HTML5. To state otherwise is confusing to many people and can actually put people off working to standards at all, as any research just finds a bunch of infighting and name-calling rather than clear explanations as to how we should approach things today.

  13. You read my mind, Jeffrey. I just wrote about this. I agree that Henri’s condescending tone does him no favours.

    Deliberately conflating XHTML syntax with XHTML 2, the dead spec, just to wallow in a moment’s gloating, isn’t very endearing.

    To be fair to Hixie, unlike Henri and Mark Pilgrim, he hasn’t been sowing deliberate seeds of confusion since the XHTML 2 announcement (though, in the past, he has been responsible for a lot of XHTML FUD by using the word “tag soup” when he means “HTML”). I’m sure he has more important things to do, like working on HTML5 …something we should all be doing because it’s not going to take until 2022, it’s going to be done in 2012.

  14. The W3C should stop writing new specifications, not only do they take so damn long, but they take years longer before they’re fully supported to a level where web professionals can use them.

    XHTML 1 works, leave it be. Go improve SVG, X3D, SMIL, or anything you want – but if it ain’t broke, don’t fix it – because fixing it WILL break it.

  15. I completely agree with your stance. xHTML is xtendible, that’s what makes it so great. Everyone is ready to jump off the bandwagon and go to HTML 5 when it’s not even out yet. Yea there’s neat things you can do with it. But not every browser will be able to see those neat tricks. I do hope that HTML 5 will take hold and will work but let’s not fault a perfectly good coding system just because there is a new kid in town.

    -Seth Goldstein
    Goldstein Media LLC
    http://www.goldsteinmedia.com
    http://www.twitter.com/sethgoldstein

  16. The whole text/html vs. text.xml debate strikes me as similar to debating whether a tomato is a fruit or vegetable. Science has one view, the government another, but at the end of the day it is food. It nourishes and provides sustenance.

    In the right hands can become a delicious sauce, but in the wrong hands it is a messy weapon. Either way, ask any man, woman or child on the street if a tomato is fruit or vegetable and they might humor you by joining the debate, but in the end won’t give up eating them if their view is different from yours.

  17. Jeffrey, you make some excellent points.

    I think what we really have to consider is that you should use whichever doctype is right for the job, whethere that be HTML 4.01, xHTML 1.x or HTML 5.

    xHTML is by no means dead and still exists as xHTML5 as Bruce pointed out the other day. – http://html5doctor.com/html-5-xml-xhtml-5/

    You’re also right to point out that HTML 5 is controversial, there are many revisions to go through, but the point should be that we can all get involved (although as you pointed out in your last post the language can be hard to interpret.)

    We also have to remember that HTML 5 is huge, and contains lots of API’s, local storage etc. You can start using parts of it it today and I’d actively enourage people to do so. As Molly recently pointed out at @media ‘Implementation trumps specification’ and how many people are using CSS2.1?

    Snook also makes an excellent point about XHTML teaching good markup practices.

  18. …although some of it [HTML 5] can be used today.

    While there are cases – mostly dependent on the target audience of your project – where HTML 5 is a legitimate choice, I haven’t had the opportunity to use it responsibly. I base these decisions on what’s best for my client, not for my curiosity… XHTML has given me a solid option for responsible development for the past few years, knowing that the sites I’ve built for my clients will last beyond their immediate needs.

    Looking forward to finding an HTML 5 opportunity and digging in more.

  19. Now there’s a thorny topic. I really wrestled with how to approach this when writing the HTML reference for SitePoint (the HTML vs XHTML page is here) and have had to justify my choice numerous times, mainly because I used XHTML for my beginners HTML/CSS book.

    The question was asked by readers who learned from the “Why recommend XHTML?”, having been scalded afterwards for using evil XHTML. “Why did lloydi teach me bad habits?” they appeared to be asking, and the answer was somewhere between “It (XHTML1) teaches good coding practice early on for newbie web developers” and “SitePoint preferred it because, from a marketing point of view, XHTML appears to be the newer/better option”. Of course, it’s not quite that straightforward for the latter point!

    The difficulty I have now is that having recommended XHTML in the beginners book, I’ve since reworked accessify.com …. in HTML 4.01. Yes, I’m one of those people! But that said, it’s not because I want to be all militant about it or make a protest that ‘XHTML sucks’ or anything like that. For me it was a case of simply accepting that there was nothing *wrong* with HTML4 in that scenario and, hey, it might stop a few people getting on my back about incorrectly served XHTML!

    Overall, I still believe that it is better to teach XHTML syntax rather than HTML, so that beginners learn *rules* rather than (arguably lazy) shortcuts. With that approach comes caveats and a modicum of explanation. I certainly would not want to beat a newcomer over the head with the finer details lest it put them off. The religious wars that we can get into don’t make for an easy introduction to writing good markup!

    As for HTML5, sure it’s not perfect. Some of it is a marked improvement, some of it is a step back (in my opinion), but I would not automatically admonish someone for using that over HTML4 or XHTML1, or any other choice from that list. It is personal preference, and as long as you’re not misusing the markup (this goes for all language choices!), using good semantics, validating your work and so, then fair play to you.

  20. It’s a common misconception (or perhaps a deliberate blind assumption in some cases) that all users of XHTML are pro-draconian error handling (stopping displaying a page if an error is found). That somehow strict authoring rules have to be paired with strict parsing rules and impractical error handling. And it’s with glee that they point out to those using XHTML that there is no benefit to what they’re doing because browsers treat XHTML served as text/html as the dreaded tag soup.

    Chef’s secret: tag soup is made of 100% pure HTML.

    What they mean when they say that there’s no benefit to serving XHTML documents as text/html is that browsers deal with the pages in the same way as when HTML is served as text/html. There’s no measurable difference.

    All the while, those of us authoring using XHTML gain the benefits of a simpler, more consistent and predictable syntax, with no downsides when the page is presented to a browser. It doesn’t sound like such a misinformed, misguided choice to me.

  21. @Jonathan Snook – “it taught a generation of developers what good code should or could look like.”

    Exactly. I have stuck with XHTML 1.0 Strict (even serving it as—gasp—text/html) primarily because of its unrelenting rigor. This rigor forces us developers and designers to write well-formed code, and helps to establish good habits. HTML 4.01, on the other hand, has been a slight mess of inconsistent tag closings and lenient validation. This not only allows for mistakes, it condones them. This, of course, is not an issue for those of us who are intent on precise code, but it presents a problem of establishing bad habits for those who are not.

    While I imagine at this point in my career I could switch to HTML 4.01 with no trouble and maintain the well-formed code I am used to with XHTML 1.0, it’s become comfortable to stay with what I know, and what forces me to be good. Call it trading laziness for obsession.

  22. XHTML 2 was actually the better spec. The problem, though, is that better doesn’t always win.

    I wish people wouldn’t use such statements as “implementation trumps specification”. This implies that the web will always be in a position of catch up, rather than being based, equally, on forward thinking and planning. Today’s web: Hamsters on a wheel.

    I’ve used XHTML, yes served as application/xhtml+xml for those browsers that can handle it, and text/html for those that can’t, for years now. With this I’ve been able to incorporate SVG and RDFa into my web pages, and didn’t need a committee to give me the okee dokee to do so.

    XHTML is so marvelously extensible. And yes, it will be around for years to come, either as XHTML 1.1, or XHTML 5, or whatever the future brings. In fact, as we mature as developers (and our tools improve) I look for increased interest in XHTML.

  23. Amen. As many before me have said, it took XHTML to really get our code out of the gutter and make it meaningful. Sure, its true that HTML can be written every bit a semantically and validly as XHTML, but it does make it relatively easy to get sloppy (again).

    Having played a bit with HTML5, I can honestly say I am less apprehensive than I was originally, but I am still concerned with where its focus is and somewhat baffled by the “problems” it is attempting to solve. Sure, I’d love more semantics, but many of the new elements aren’t really providing something completely new, they are simply re-branding older elements.

    Anyway, I’m planning to continue playing with HTML5 on certain projects, but our team will likely stick with XHTML1 Strict for some time to come. Maybe it’s just my OCD, but I prefer it when every tag is closed.

  24. @Shelly, what I’m getting at (and I’m sure Molly is the same) is that we don’t have to 2022 as everyone is saying, CSS2.1 and CSS3 are being used way before specs are finalised and HTML 5 goes to final to final call in October this year.

  25. …So, I have an illuminating story.

    Last winter I was contracted to write an increasingly-behind-deadline book and before I made it even five hundred words into the draft manuscript, my decision to do all of the inline markup examples in XHTML 1.0 Transitional was approved by all involved… notwithstanding the book’s title.

    That decision is explained to a faretheewell, and in the manuscript I castigate Internet Explorer at length for choking on application/xhtml+xml.

    What detractors seem to forget is that most of us prefer to reduce the minutiae that invade our day-to-day lives, not increase it. Compared to its SGML-derived neighbor, XHTML is incrementally cleaner, more predictable, and more regular, making it easier to read source markup and enforce good work habits. Why make one’s job any harder than it needs to be?

    (…Or maybe I just care about things being not-irregular because of the full year’s worth of language studies I was enrolled in as a student. But I digress.)

    If a lead dev comes to me in a fit of religious fervor and declares that I need to deliver my markup as HTML 4.01 Strict, I can do that. I just prefer not to.

    Meanwhile, at the end of it all, the basic fact is that most people don’t give a dam. They stick to what they know, and that’s that.

    So why the guilt trip? We respect your choice. Why can’t you respect ours?

  26. Another load of bullshit again. It is amazing to see how web developers “enjoy more strict code” without even realizing that this code is treated by the browsers as broken HTML. Did you see those red slashes when you do view source in FF3.5? Do you know that they mean?
    And if you cannot write good code in HTML4.01 no XHTML will ever help you. What you get is only misleading sense of using “superior” or “more strict” standard when in reality if you are sending it as text/html none of that strictness comes into play. Try to send it as it supposed to be sent and you WILL be surprised by the strictness in places you did not it exists.
    As for those “who’s had the audacity to study up on and use XHTML” — sadly for most of them this study ended with learning few trivial syntax rules. Tell them about MIME types and you will get blank stares and “huh?”. I was one of them once.
    I won’t even comment “HTML5 won’t be ready till 2022″ nonsense.
    Oh, by the way, you can use HTML5 today. Even with the same syntax you so like for your XHTML. It is valid in HTML5. HTML5 is not based on SGML, so it does not even clash with SGML’s SHORT TAG YES. Had this SGML feature ever been implemented we won’t have these pointless debates now.

  27. Sure, its true that HTML can be written every bit a semantically and validly as XHTML, but it does make it relatively easy to get sloppy (again).

    See, I’d buy this argument if you’re serving XHTML with the correct mime type. But if you’re serving it as text/html (which everyone does), then XHTML makes it precisely as “easy to get sloppy” as HTML 4.01. Because the browser is treating it exactly the same way.

    I find the complaints about Henri Sivonen’s post a bit ironic. Sivonen calls it “marketing XHTML.” Zeldman says the main benefit of XHTML was that it “gave web standards evangelists like me a platform on which to hook a program of semantic markup”. Sounds like 100% agreement to me.

  28. Can someone give me a real-world reason why the MIME type issue is such a problem? I’ve been using XHTML 1 for a couple years now, and haven’t seen any problems. Is this strictly a purist debate?

    I chose to switch to XHTML 1 (from HTML 4, if I bothered to declare a DOCTYPE–shudder) because it offered the most rigid standard. And, because Zeldman and a lot of others said so. When you’re an infant, you simply trust your parents. If I’d tried to dive in to MIME types and all the pros and cons of all the specs, I might’ve just blown it all off again and gone back to designing table layouts for IE6.

    Now that I’m an awkward junior-higher, I’m grateful that XHTML2’s death is giving me a chance to learn more about these specs. But, in the mean time, for me it’s XHTML 1 until I find a convincing reason why I need to switch to HTML 5.

  29. XHTML 2 never really got off the deck did it? While HTML 5 seems to be getting more solid over the past year or so. To be honest, I’ll work with what’s usable right now, XHTML 1 works fine, and then I’ll gradually get comfortable with other spec(s) when they become more established and complete.

    Jeremy: 2012…that soon?!! ;)

  30. Rimantas, thanks so much for grouping those of us with a clue (i.e., most of the people in the thread!) with those who don’t. Also thanks for proposing that we’re going to stay away from HTML 5 in droves. I can’t say that I care for being asked to learn a completely new namespace and all of its zillion rules, but hey, I’ve done it thrice in my life already, why not again? In point of fact, I’m looking forward to ditching object and discovering what canvas can do. Yummy.

    As for the MIME type issue: if Microsoft ever gets the desired traction and actually supports application/xhtml+xml, it will be possible to add arbitrary elements (with styles) to an otherwise run-of-the-mill Web document, without the need to muck about with transformation — ergo, “eXtensible.” For reasons that Mark Pilgrim pointed out and Zeldman tweeted recently, it’ll be hell to implement on properties that include user-generated content, but there it’ll be.

  31. I don’t grasp a few things…
    Who actually extends xhtml? Answer: nobody.
    Who praises the “increased strictness” of xhtml? Mostly, people who chooses 1.0 transitional (the same transitional doctype which permits horrors like the dreaded font tag!): at this rate, it makes much more sense talking about “strict vs transtional”, rather than “html vs xhtml”.
    I don’t even want to get started about people who think semantics it’s an exclusive property of a given doctype, and not something that only human beings are responsible for.

  32. My website is XHTML (served as application/xhtml+xml on supported browsers) and as more HTML5 features are implemented by browsers I will start using them as they become available.

    XHTML 1 is identical to HTML 4 and is still supported in HTML5, and will grow along with it into XHTML5.

    XHTML 2.0 has (unfortunately) always been a mostly academic exercise and very few web developers have ever used it, so dropping the XHTML 2.0 specification has no impact on any web developer. All the people who comment otherwise are wrong, XHTML still exists and will remain to exist in HTML5.

    In HTML5, an XHTML5 page has to be served as application/xhtml+xml. However HTML5 has several explicit provisions that allow you to serve an XHTML5 source document as text/html. End tag slashes and the namespace declaration are allowed and not invalid. In that case however, it should be called HTML5.

    So of course in practice this allows us XHTML developers to do exactly the same as we did with XHTML 1, except that now if I really want to be precise, I have to say ‘my website is XHTML, and HTML in Internet Explorer’.

    ~Laurens

  33. I remember when I started using CSS for layouts, everyone was shocked. They were saying “Tables are bulletproof, why fix something that isn’t broken?”. I believed in CSS even though my design were broken – literally – in IE, I stuck with it. Here we are now, using CSS for things that would have never been possible with tables, building stuff quicker than ever before because of CSS.

    The reason why I’m eager to move to HTML5 is because Firefox 3.5 and Safari 4 support it quiet well. As far as IE goes, I don’t use tags it doesn’t understand, I implement them as classes.

    As front-end developers, I think we need to do our bit to get rid of abominations such as IE. We can display upgrade your browsers banners on websites or (god forbid) redirect to a “this website does not support your browser” pages, but what if we build features for websites that work only in proper browsers such as Firefox and Safari? Give our visitors a real incentive to upgrade. I think more people would if this was the case.

    That’s why I use HTML5, because it enables me to do things in browsers that will add a real value to websites. If Google is taking notice, we should. Those people live to make the web a better place. Follow the leader closely, observe, mimic, then overtake – just as when you’re bike racing someone : ).

  34. I’m with Jonathan Snook – I believe XHTML was important to define rules of construction, but I see no reason to use it today, because you do *can* write HTML 4 with lowercase tags and attributes and quoted attribute values, writting good, valid code.

  35. Who actually extends xhtml? Answer: nobody.

    The “X” doesn’t refer to extending HTML; it refers to the X in XML — the ability to create new markup languages based on the XML rulebook.

    Basing documents on XML allows you to parse and manipulate polyglot documents (more than one markup language per document). For example, it is entirely reasonable for an engineer to create a document that contains (X)HTML explanations, SVG diagrams, and MathML equations.

    Similarly, a business document might want to include XForms with XHTML. (And yes, there’s a Firefox extension to handle exactly such a case.)

    I’ve often thought that a “modular browser” would be quite nice; the core handles XHTML, and other “foreign” namespaces are handled by plugin or extension modules. Older browsers or browsers without the modules would simply ignore the foreign elements. But then again, what do I know.

  36. @ Robert E. Stockpile:

    Transitional carries the stigma of accepting functionally deprecated elements (which is actually isn’t so bad, considering the whole user-generated content thing), but…

    Transitional also eschews some of the more byzantine requirements of Strict. As someone who has been rudely hit over the head by those same byzantine requirements more than once, I can say that Transitional’s nice when you want to just roll up your sleeves and get to work without dealing with a ton of hassles.

  37. Well put. While it’s great that we can use some of HTML5 features today in forward-thinking browsers, XHTML is still suitable for most web pages – given the current state of browsers in use and their support. Nobody is going to throw XHTML support out of the window.

    It’s good to care about standards, but some people really need to be more pragmatic.

  38. Going back and re-reading some of Rated XHTML:

    In practice, the following rules have been added to HTML for writing XHTML:

    Make sure all your tags are lower case.
    Close all your tags. In the case of tags that don’t have a closing tag, like
    <IMG> or <BR>, add a slash to the end of the tag: <img />, <br />.

    Nest tags correctly. No more <B><P>text</B></P>, but <p><b>text</b></p>.
    Put quotes around all attribute values. No more <P ALIGN=center> but <p align="center">.

    reminds me how AWESOME that was. At that time, and still for some developers out there today – it was a whole new way of structuring your code. And when followed, made working in a team of developers sooooo much easier. Sure, in an ideal world, maybe you work at a company where people know whatever the latest best practices are and you have developed an internal syntax of how to write clean, legible code, so when passing off to another coworker, they know your JavaScript variables will be camel case and your tabs in your CSS are set to 4 and you are using all lowercase for your HTML tags. But most of my earlier jobs were not like that. Everyone wrote their code how they wanted. Comments with ASCII art of middle fingers with a note about IE being the bad guy, were not only fair game – but sometimes even encouraged. Code was a mess to sort through – it was like bad lol speak – but without the laughing.

    So even with the arguments against it, at the very least – it gave structure to a lot of peoples code that was not previously there. And I think that rules. Could there have been another, more purist solution? Maybe – but it wasn’t adapted then and this was.

    And honestly, I got just as excited with possiblilites of the change XHTML2 could bring. Reading http://xhtml.com/en/future/x-html-5-versus-xhtml-2/, as well as a bunch of other well timed HTML5 and XHTML2 articles, prompted a few of us over here to sit down over lunch and talk about how cool things like href’s on ANY element would be and how nested H’s would help ensure proper outlines. XHTML2 was offering something more that an aside element. Did everything seem perfect? No. But XHTML2 was seeming to be the option that would really offer the more useful changes. Just like its predecessor it introduced CodE ThaT didNT LOOK liKE ThIS to a wide audience.

    I hope more of that thinking is continued. Does it have to be in XHTML2? Nope. But if we’re taking the time for all this debate and all this change – I hope the impact is big. Or at least includes navigation lists.

    Or:

    the abridged version

  39. I was one dancing on the grave of XHTML2, because I saw it as a “land grab” by developers, taking a simple markup language away from designers and replacing it with something more like a programming language than anything else. (The last straw for me was when they replaced “img” with “object.” Yes, they put it back again, but that showed me the XHTML2 group was more interested in ideological purity than actually accomplishing anything, which is a fine academic position but lousy when you have to make a living.)

    I see people speaking wistfully of the syntax rules about closing tags and the like in XHTML, and am puzzled; I was writing that way in HTML, before XHTML ever came along; there is nothing in HTML5, and for that matter there was nothing in HTML4 or earlier that prevented you from doing it. As for “empty” elements like img and link, well the concept that some elements didn’t have content and so didn’t need to be closed is no harder to grasp than the concept that a doctype doesn’t need to be closed. (The latter was probably not an issue to anyone, because HTML had already paved that road.)

    I learned at a very early age that “not required” does not equate to “not allowed,” nor even “not a good idea,” so I was closing paragraphs, list items and the like well before XHTML slouched its way to the manger. We were always able to write good markup in HTML, it’s just that good markup technique was seldom taught. That education arrived for some under the guise of XHTML, so for that I’m grateful, but that’s about all I feel for XHTML. Oh, and I suppose there’s also the fact the extra cruft that had to be wrapped around inline scripts encouraged more people to pull scripts out of their XHTML files. OK, so I have two reasons to be grateful for the effect it had. But now it’s time to move on; keep on writing good markup but now just call it what it is and what the user agents have generally treated it as, HTML.

    Oh, and 2022 is the expected date for full implementation of the spec, a state that HTML4 hasn’t even reached yet, so don’t panic over that date. W3C timetable says fall of 2010 for approved recommendation, but that’s probably optimistic by a year or so.

  40. Let’s see: the W3C put its weight behind XHTML. People who cared passionately about doing the right thing as well as serving users negotiated a middle course, pushing developers to code for the future while providing content and services to people in the present (XHTML as text/html). Years later, the W3C decides to reorient itself and put resources where things seem to hold the most promise.

    This is cause for an outburst of back-biting, petty attacks, and sneering condescension? This is reason to imbibe in accusations and jeering mockery of people’s good-faith efforts to build the best web they could? Seriously?

    <sigh />

    Also: Rimantas, thanks for warning us up front. That was downright neighborly of you.

  41. I think you make some valid points here and I agree. XHTML 1 has worked near perfectly for me for years and I’ve no reason to abandon it. I like the clear separation of content and code and the solid foundation that has required years of work to get to this point.

    I’ve been playing with HTML5 for a little while now and while I like the way it resembles the structure of XML and the clarity of the markup, I don’t think it’s even near time to be up in arms about a transition–especially when that transition is projected for arrival 13 years from now. Although I think Jeremy is spot on to say it will be ready in 2012 rather than 2022.

    I see no reason to dig up the foundation that has been set. HTML4 and XHTML1 work and it should be based on the preference of the designer and/or the project at hand. Not what the elitists say or the W3C. Designers should not be easily influenced by what a group says, rather they should be driven by what works for them and what works across the board (with the exception of IE’s quirks of course). The seas have just settled and now we want to rock the boat again? I’m still searching for land.

  42. I’m never worried about anything being stated by the W3C because as history has shown us, they are exponentially slowing down as time passes.

    Earth-peoples, it’s pretty damn simple to make your code look nice. Make your HTML lowercase and your CSS well-organized with comments for grouping. I don’t care if your img tag doesn’t end in “/>” but I do care if your code looks like shit. This is XHTML’s greatest gift to us: the clean, lowercase naming. It made us better.

  43. Aaron Gustafson said:

    “Maybe it’s just my OCD, but I prefer it when every tag is closed.”

    I think this accurately describes why some people have a completely subjective preference for XHTML. Quite simply, it’s the syntax we’ve gotten used to over the years. For those of us who have been using XHTML, we’ve trained ourselves to fervently sniff out and annihilate unclosed tags; it’s painful to imagine writing markup any other way.

    This doesn’t necessarily mean, however, that HTML is inherently untidy or messy, as some people claim — it’s just different. There’s nothing preventing an author from constructing a valid, well-formed HTML document that’s just as “tidy” as an XHTML document.

    (And HTML certainly doesn’t require us to abandon CSS and go back to FONT and TABLE tags.)

    Nate Klaiber’s comment summed it up quite nicely:

    They used XHTML to ‘enforce strict standards’ – as if you couldn’t do the same in HTML4.

    Perhaps what we developers love most about XHTML are the philosophical ideas it’s come to represent: industry standards, developer best practices, valid, well-formed and semantic markup. To many developers the term “XHTML” doesn’t represent a technical specification — it represents a set of ideals. And the natural reaction is hostility towards things which we perceive to challenge those ideals.

    It’s important to realize HTML5 doesn’t threaten the ideals XHTML has come to represent.

    Personally, I’m still unsure what I’ll be using going forward. Most likely I’ll stick to XHTML for current projects because hey, buzzwords pay the bills. I’ll probably start experimenting with HTML5 on my side projects, however.

  44. Thank you for a beautifully clear post on this subject and for dealing with it head-on. As for a comment, Rachel Andrews, Drew, Aaron G. said it best for me. Whenever I’ve asked experts what to use, there’s hemming and hawing (as they think of all the people who will argue with what they are about to say) and then they say their real-life answer which, in my experience, has been HTML 4.01 or XHTML1 Strict.

  45. May I add a bit of personal wisdom to the latest over-heated discussions “XHTML vs. HTML”? :-)

    Three very important points, IMHO:

    First, XHTML 1.0 is not better or worse than HTML 4.01. XHTML is just a bit different ‘flavor’ of the HTML standard. Yes, if you serve XHTML as application/xhtml+xml MIME type, then it is different from HTML, and a lot; but if you serve it as text/html, just like you normally serve HTML 4.01, then there is almost no difference, except for syntax rules.

    I can safely say the same about HTML 4.01: it is not better, or more standards-compliant or stricter than XHTML 1.0. It is almost the same.

    I’ll just add a small //sidenote, before I continue: Developes/coders, who have made their choice to write XHTML 1.0 or HTML 4.01, and their particular choice makes them feel ‘superior’ to the developers who are in the other ‘camp’, are most certainly wrong! So if you write strict XHTML 1.0, this doesn’t mean you are a better developer than your fellow colleague, who prefers to write HTML 4.01 instead of XHTML 1.0. And vice versa!

    This is a matter of personal preference, not the ‘superiority’ of the one or the other HTML standard!

    Second, the biggest (and most important) difference between XHTML 1.0 and HTML 4.01 is actually… syntax. It’s slightly different. Some developers and coders actually prefer it to the HTML 4.01 syntax. Rules are simpler and easier to obey to:

    — all open tags should be closed, incl. paragraphs and list elements inside UL/OL lists (br and img must be ‘self-closed’ with a trailing slash before the end of the tag);
    — all tags are lowercase;
    — all HTML attributes must be in quotes.

    That’s all. Compared to HTML 4.01, the syntax of XHTML 1.0 is a bit more ‘strict’. But it’s also simpler and easier to read. In HTML 4.01, you can leave paragraph and LI tags open; you can use a mix of lowercase and UPPERCASE (which isn’t very pleasing to the eye); you can quote attributes or not quote them or a bit of both; and still, your documents will be perfectly valid!

    Of course, in HTML 4.01, you can also write all tags in lowercase, quote attributes, and close all tags, incl. P and LI tags (but you must not self-close BR and IMG tags, though). But the W3C validator will not detect any mistakes in your HTML 4.01 code, even if you mix lowercase tags with UPPERCASE ones, if you close half of your paragraphs (and leave the other half unclosed) and if you do not quote all of your HTML attributes. (And I, personally, because of that, prefer the XHTML 1.0 syntax, which leaves me less room for unevenness of my code, by enfocing me to close all tags, use only lowercase and quote attributes. It’s a matter of personal coding preference, though, not anything else!)

    And this leads us to the next & last point:

    Three, the HTML 5 standard is something new, good, and will allow us, designers & coders, to have even more freedom. In HTML5, we can use the XHTML-style syntax, if we like to; or we can stick to HTML-style; and both will be perfectly valid!

    Also, HTML 5 is perfectly backwards-compatible, which is good (XHTML 2 wasn’t, and this was bad; this is also one of the reasons why the draft of XHTML 2 died even before the standard reached any maturity).

    For now, I see only one problem with HTML 5, and it prevents me from fully embracing the idea right now (because, yes, you can start coding in HTML 5 now, even if you won’t be able to use all of its potential today — not until all browsers start to support it close to 100%, like they support now HTML 4.01 and XHTML 1.0):

    In HTML 5, you can use XHTML-style strict syntax — close all open tags (including paragraphs and list elements), use lowercase, use quotes for attributes. Or you can use HTML-style syntax, too. The problem is that currently, if you mix both syntax styles in one document, and then try to validate your HTML 5 document, it will validate!

    So if you prefer to write stricter code (for example, close all open tags), there is no way for you to know if you actually succeeded 100%, because running your HTML 5 document through the validator will not show you if you omitted to close a tag somewhere (for example)!

    And you can’t serve your HTML 5 document as XHTML, because this is only possible if you serve it as application/xhtml+xml, which means, Internet Explorer won’t be able to read it; which means, you better don’t do it! :-) (In XHTML 1.0, you could use the stricter syntax style, validate your document as XHTML, and still, serve the document as text/html, so as to please IE.)

    So this is my only concern for now.

    I have made a personal, conscious choice: I prefer the XHTML syntax. I don’t mind serving my html files as text/html. But I like lowercase, closing all of my open tags and use of quotes for attributes.

    I don’t believe that XHTML 1.0 is better than HTML 4.01 or HTML 5.

    But if I prefer to close all of my tags, then please, let me know (via the W3C validator!) when I forgot to close one or two, by mistake. Let me code my way and check if everything is correct in my syntax.

    That’s all I ask. I hope I’ll be able to, one day; until then, I’ll probably continue to write XHTML 1.0 Strict or Transitional, serve my documents as text/html, and validate them as XHTML.

    And now, please, let the stupid war ‘XHTML is better than HTML | HTML is better than XHTML’ go to an end!

    We have more important things to do — like, for example… code our designs & learn new things!

    My $0.02 :)

  46. @ Ben:

    I agree about the user-generated content nightmare, but i still don’t get this one: we wantstrictness, but when it comes to it (the strict doctype), it’s too much to bear, so the trailing slash wins over the font tag? I’m even more confused!

  47. I was in college when the web hit the world.

    What a perfect time to be a part of this explosive new industry.

    My head reels when I step back and think about what is being done through a simple browser.

    But I also feel sick to think that the basics of the whole experience–the markup–isn’t going to have a really new iteration until I am 50 years old.

    FIFTY.

    I won’t be doing this then. Statistically speaking (in the US at least) I’ll probably have changed careers a few times since then.

    So will the large majority of people in this business who seem to deal directly with markup.

    Don’t get me wrong, I see what’s happening. I realize that a move into development has become inevitable if I want to remain in this business.

    But seriously. Are all of the browser makers going to slowly, partially adopt HTML5?

    My CSS stop validating two years ago because of the -webkit &-moz features that are really CSS3.

    So am I to have my HTML stop validating (I’m assuming it will, if not I apologize) because I’m trying to use (and keep track of) which browsers are using certain features of HMTL5? Or use javascript to force browsers to do what I want? (Which, by the way, I’ve been told I should not do..because what if javascript is disabled?)

    Sigh.

    I’m just going to continue to use HTML 4.1 as this is the standard and just ignore all of this crap.

    As far as I can tell it wasn’t even worth my time to ramble on about it.

    So here is what you should take out of this….

    Most of us are not hyper technical and cannot probably join in the debate. But YOUR conversation is confusing the holy hell out of a lot of us. I wish I could tell you how many uninformed conversations I’ve had about this already.

  48. It has only been a few days but I am already sick of the “XHTML is bullshit, man!” crowd using the cessation of XHTML 2.0 activity to condescend to

    I see that you are referring to my post. I didn’t mean to condescend to developers using XHTML. I did mean to poke fun at the use of XHTML as a marketing platform while making it look like a technical thing.

    When I wrote the first edition of the book, some versions of Mozilla and IE would go into Quirksmode in the presence of HTML 4, breaking CSS layouts. To me, that was a worse problem than whatever was supposed to be scary or bad about using well-formed XHTML syntax while delivering it as HTML all browsers could support.

    A few who became disenchanted with XHTML early retreated to HTML 4, and as browsers stopped going into Quirksmode in its presence, valid, structural HTML 4 became a reasonable option again.

    Doctype sniffing has been pretty stable for a long time now for key doctypes.

    Quoting Jeremy Keith:

    To be fair to Hixie, unlike Henri and Mark Pilgrim, he hasn’t been sowing deliberate seeds of confusion since the XHTML 2 announcement

    Where did that come from? I was deliberately trying to unconfuse people.

  49. In my defense above I should have edited it instead of rambling. I am aware that it is HTML 4.01

  50. Michel hit the nail on the head. It strikes me that what’s really needed is some kind of lint tool for validating markup that would allow the author to specify how strict they want the check to be. Currently we’re using strict doctypes to accomplish this but for HTML 5, if we still want that strictness, validators will need to give us that option.

    The good news is that Henri is just the person to give us such a lint tool.

  51. Goodness knows I’m as guilty of diatribes as the next man. That said, I couldn’t agree more that this whole XHTML2 issue seems to have brought the very worst out of the woodwork from several developers who seem intent on using the annoucement to form a pitchfork-wielding mob to bludgen a few of their peers.

    Which is, in my opinion, pretty poor form.

    Good on you for making it clear that it’s not cool to be a jerk.

  52. Henri, the confusion I was referring to was your unnecessary inject of (somewhat snarky) personal opinion into an otherwise level-headed Q&A:

    …but the authors attempt to observe slightly different syntax rules in order to make it seem that they are doing something newer and shinier compared to HTML.

    Thank you for subsequently updating that passage with an apology:

    I apologize to authors who are using XHTML

  53. Very useful (and interesting) conversation, indeed! :-)

    //slightly off-topic: For some reason, I still see this post on your blog only half-rendered in Firefox 3.0.11/WinXP SP3 (see screenshot). The page stays so even after a few ctrl+f5, which is strange… Am I the only one who still sees this page half-broken (you already deleted the problematic UTF-16 pingback, which should have fixed things)? //end off-topic

  54. So… HTML4 will continue to work and XHTML1/1.1 will continue to work, so you can keep doing your thing and ignore HTML5 if you want. HTML5 is new, so we get something new to learn about (everyone likes learning right?). HTML5 is almost completely backward compatible (from an author’s perspective) with both HTML4 and XHTML1, so it’s a very gentle learning curve. HTML5 is much more precise which means better browser support (it’s coming) and better validators with better error messages. HTML5 is still being written, and WhatWG wants your input, so you could even take part.

    C’mon people, doesn’t this all make you just a little bit happy? What’s not to like here? How about a group hug…?

    +1 for strict parsing mode in HTML5 validators

  55. Pingback: Gregarius
  56. Jeffrey, good luck with your surgery today. May you recover quickly.

    Tantek

    P.S. FWIW, my choice is still valid semantic XHTML 1.0, authored according to the Appendix C. HTML Compatibility Guidelines, served as text/html. I stand by my reasons.

  57. The comedic part for me about this whole brouhaha is that most of the time I’ve not even be aware of my coding habits prior to this OK Corral style showdown that the last week has become.

    I had to check my doctypes to see what I was authoring in (I’m not sure what this says about my memory). It turns out that it’s XHTML.

    I learned something today.

    Good luck on your surgery, Jeffrey.

  58. What @Arlen Walker said.

    With a few minor exceptions, and for the vast majority of cases, HTML4 == XHTML1. The elements are all the same, the attributes are almost all the same, the browsers render them almost the same. Sure it’s XML instead of SGML, but in the end, both allow you to write code that is “strict,” “rigorous,” “semantic,” or any of the other adjectives being thrown around in praise of XHTML.

    I currently use both HTML and XHTML at work, and consider them exactly equal, because I could only use the extensible part of XHTML by levaing IE users in the dark.

    Personally I’m looking forward to (X)HTML5 because a) I won’t have to remember the blasted DOCTYPE declarations any more! and b) some of the new elements look potentially interesting, once they’re adopted by all the browsers. Otherwise, I really don’t have any strong feelings about the matter.

  59. Thank you, Zeldman, for this entry! Best of luck with your surgery!

    As I mentioned in my comment for the original entry:
    “Please folks, be kind to your fellow front-end coders, make your mark-up good, modular/extensible, and understandable.”

    Can’t tell you how many times I’ve had to clean up and/or fix someone else’s bad code. Following XHTML1 at least minimizes this.

    Remember folks (from Adactio: adactio.com/journal/1595)
    “XHTML 1.0 is simply a reformulation of HTML 4 with XML syntax:
    * lowercase tag and attribute names,
    * quoted attribute values,
    * mandatory closing tags for p and li elements,
    * a slash at the end of standalone elements like img, br, and meta.”

    There’s really no excuse not to do these things.

    Remember, the browsers all (remember IE?) have to support it (HTML5’s new things) before you really want to use it. Otherwise, messy hacks and work-arounds galore.

    Besides, in a few years, I’m sure everyone will all be up in arms over some other standard again.

  60. Michel: it is a bug in Firefox 3+/Windows. I’d report it myself but I’m in the OR about to have surgery.

  61. The comment you quoted at the end really hit the issue spot on. Developers are just trying to write the most up-to-date code that will give them the fewest problems down the road as specs change and browsers evolve. All this theoretical shadow-boxing is irrelevant when it comes time to write actual code that needs to be consumed by actual users, and so it’s quite silly to judge developers on anything but their ability to make that code work in a lasting fashion.

  62. Maybe some developers feel like they’ve been tricked into thinking that they had to use XHTML in order to use CSS. This is the power of the one (in this case our fearless author) that everyone looks to – his preferences are read as dogma.

    I don’t see the big deal, but maybe that’s because I’m a pragmatist – XHTML “worked” and still does. It also gave us a solid foundation to grow on.

    HTML 5 has some promising features we’ve all been clamoring for. When those are supported to the point of practical use, we’ll start using that.

  63. @Jeremy & @Oli:

    You said it in a much shorter and concise way, than I did! :-)

    +1 for strict parsing mode in HTML5 validators, from me too!

    People who prefer XHTML 1.0 syntax (all tags lowercase; all tags closed, incl. P and LI tags; all attributes in quotes) should be able to not only code in such a way, using HTML 5 (which they now can, actually!), but also to validate against this syntax, without necessarily using application/xhtml+xml (which can lead to a lot of trouble currently).

    People who prefer HTML 4.01 syntax (tags can be lowercase/uppercase; P and LI can be left un-closed; attributes can be in quotes or without) should be able to validate against this (a bit looser) HTML syntax, too, in HTML 5.

    @Henri:

    So, can we have two sorts of W3C validation for HTML 5 documents, then? Two ‘modes’ of validation?

    One for XHTML-style syntax HTML 5 code, and one for HTML-style syntax HTML 5 code? It could be made optional, too! For example, for HTML 5 W3C Validator:
    — default mode: HTML standard, ‘loose’ style — both lowercase/uppercase tags are valid, P and LI tags can be left unclosed, attributes can be quoted or not, etc;
    — ‘strict’ (XHTML-style) mode: all tags should be closed, all tags lowercase, attributes always in quotes, etc.

    The ‘Strict’ mode in HTML5 could be activated for the validator by some kind of additional simple ‘switch’ in the code, like:
    <!DOCTYPE html "Strict">

    …as opposed to the ‘default’ mode which would be triggered by the ‘standard’ HTML 5 doctype:
    <!DOCTYPE html>

    If the Validator checks the document and finds the Strict ‘switch’, then it will enter the mode “Check document as HTML 5 with XHTML-style, stricter syntax”. If it checks the document and finds no such switch, but just the standard HTML 5 doctype, then it will check the document as standard, loose (HTML-style) syntax, like it is doing now…

    Good idea/bad? Possible? Impossible? What do you think?

    I still think that while some authors may mix xhtml-style code with html-style, when validating against HTML 5, a good idea would be to separate those two coding styles, and thus, maybe introduce sort of (optional?) ‘validation mode’… Sounds wise to me.

    I currently code my HTML in XHTML-style, serve it as text/html, and use the XHTML 1.0 doctype. If I continue to code in this way, when HTML 5 is here and widely used & supported, I’d like to be able to continue to validate my new HTML 5 code in the same way, as before. HTML 5 accepts perfectly my way of coding.

    Now only thing remaining is to somehow ‘teach’ the W3C Validator to be able to distinguish between those two syntax styles, which are supported in HTML 5! :-)

  64. I’m not sure if this is possible, but regarding the desire to have an HTML5 validator that checks for conformance to “stricter” XHTML syntax or “looser” HTML syntax (when it comes to quoting attributes, self-closing “void” elements, etc.), here’s a suggestion:

    The head of an HTML5 document, as far as I know, is supposed to begin with a character-encoding meta element, either <meta charset="utf-8" /> or <meta charset="utf-8">. Would it be possible for a validator to switch modes depending on if a trailing slash is present on that meta element? If it’s there, it could go into the “Hey, this looks like someone’s trying to do things according to the XHTML syntax.”

    This isn’t a perfect solution, especially if someone forgets that first trailing slash but wants to follow the “strict” mode. But without having multiple DOCTYPE declarations, I’m not sure how else this would be achieved.

  65. Yes, a bit off-topic, but I am perplexed. I’ve read headers and summury attributes could desappear in html 5.

    What about accessibility?
    Shouldn’t we all question ourselves about this subject too?

    I think that all “people interested in evolving the Web” should consider this aspect.

  66. I can understand the excitement surrounding HTML5. I remember feeling the same way about XHTML. It’s important to remember, however, that we’re all on the same side here. So let’s not go out of our way in attempts to out-Colonel-Kurtz one another.

  67. @ Robert Stockpile:

    Think of it this way: in one tier you have the Transitional document types, in the the other (higher) tier you have the Strict types. (All I will say for Frameset is that I acknowledge its existence.)

    There’s nothing stopping me from declaring a Transitional type but developing to a Strict type (which is my SOP). Content contributors are reasonably happy (with a slight nudge from the server side), I can serve the document as either XML or HTML as needed, and if I inadvertently make a boo-boo, the chances of it gumming up the works are reduced.

    If instead I stick to Strict across the board, user contributions get b0rked by default and a lapse of memory on my part exposes me to the same result. D’oh. Use either flavor of HTML and I lose the extensibility option; the source markup is also less legible.

    …And like Aaron Gustafson, I have just enough OCD going to figure that optional closing tags are more of a bug than a feature (to put it mildly). Get everybody using the same functional definition of well-formedness, and you have one less source of friction between team members.

  68. I code in xHTML1, served as text/html. Snook codes in HTML4 served as text/html.

    We\’re talking about a pair of acronyms, when you get down to it, right?

    Only for a minute there I thought we were discussing politics or religion.

    Jeffrey, it\’s been ages since I\’ve seen you so passionately vocal about our noble profession. It\’s nice to see you in action again.

  69. I hated the tag soup with html…too messy and disorganized. The efficiency and strict nature of xhtml was a welcome change…a relief. I’ll stick with it as long as it continues to work well.

  70. I’m not a developer—I’m a designer—but, as a designer I work with HTML/CSS all the time, and as a Creative Director, I’m in a position to advocate for how technology is adopted on our sites. I consider myself a reasonably well-informed person when it comes to technology, and while I’m not afraid of a technical conversation in the least, I’ve found most of the talk about HTML vs XHTML to be impenetrable. Jeffrey and Jeremy Keith’s posts are the exception, and I think I have a better understanding of the issues now that I’ve read them, but frankly I still feel less than confident in my knowledge of the situation.

    And, reading the above, it seems to me there are a number fundamental areas of confusion: about the language in use (is this merely an issue of syntax, or something else? if so, how are we defining syntax again?), about the intentions of the folks making the decisions, about what it actually means for those who don’t have time to parse all the nitty gritty details, but want some trusted advice about what to expect moving forward. I hope in the coming months the acrimony dies down and someone (or many people) are able to do just that.

  71. Once again, HTML is not “tag soup.” Rather, “tag soup” is the result of sloppy coding. To call HTML “tag soup” is similar to calling beer “murder” because drunk drivers can kill people.

    On another note, I also would love to have an “XHTML syntax” checker incorporated into HTML5 validators. Since multiple DOCTYPEs is probably nonstarter, what about checking to see if the first meta element (most likely <meta charset="utf-8" /> or <meta charset="utf-8">) has the self-closing slash?

  72. Oops. Somehow my browser was showing all of the comments except for my own. Weird! Sorry for double-posting the syntax-validator suggestion.

  73. Yeah ‘cos it’s not like the Web Standards Project used XHTML as a stick with which to beat any developer or freelancer who had the audacity to study up on and reject XHTML in good faith is it? It’s not like WaSP went around telling everyone that HTML was not a web standard is it?

    Oh, hang on a minute. That’s exactly what they did.

    Fame beckoned. Fortunes were made. Millions of hours were wasted on XHTML for no reason whatsoever.

    And now Zeldman &co are peeved because some people are pointing out their central role in this Emperor’s New Clothes debacle…? Come off it.

  74. I write code for paying clients using XHTML Transitional and CSS. Could I do so with HTML? Sure, but I learned XHTML years ago, it’s a part of me now, and it validates with the very body who originally recommended I give it a go. Am I a poor professional because I’m using code that’s not being served as pure XML? Probably. But that’s likely offset by the reality that all my “wrong” code will (hopefully) pay for my daughter’s college education.

    Methinks that craftsmen sometimes spend far too long gazing at their tools and looking for purity in their work, while hacks like me just want stuff to work right.

    Like these damn FrontPage Extensions. Seriously…they’re driving me nuts!

  75. I always use what works.

    Sometimes, feeding recorded midi generated sounds out of your computer into a guitar amp then re-recording that and manipulating wav data back into midi samples after running it through an analog compressor is “what works.” It’s a deadly wrong “by the book” approach, but it works.

    XHTML2 does not exist, but XHTML1 and HTML 3-5 DO exist. And guess what? They all work. In certain situations different DOCTYPEs work better than in others. Some days I build for one web. But most days, I build for everyone’s web.

    Can we all get on creating, being courteous and learning from each other?

    Use what works, work together, and create something beautiful with what works.

    Even serve with text/html, if it works.

  76. Ok, my first comment was a bit too casual. Aside from my strong concerns (below), I am actually looking forward to xhtml5. I’m trying to be open-minded and there will no doubt be some great new tags and functionality.

    Nate, Ben,

    You have some good points; although, there is a practical advantage to using a standard that “requires” syntax rigor, not just “allows” it (I always use xhtml 1.0 strict, not transitional) even if that more strict standard is served as text/html. It’s not just academic. Yes, you CAN code strictly with html4 and sure you can still practice separation of structure, presentation and behavior; but, html still allows you to be more sloppy if you choose to be (making it hard to work with colleagues who are more sloppy). Rigor must be consistently required for all of our code, not just those of us who are obsessed with pure mark-up.

    We need a consistent standard syntax so that we can work with each other’s code seamlessly (that could be my scientist background talking; but, it truly is a beautiful thing when we all speak the same language). This important point seems to be missing from the conversation. It can be a nightmare to work with other developers who prefer html4, mostly because not all html4 code is written the same way. If html4 was predictable, we could get used to it and move on; but, html4 and now html5 allow for too much variation in their syntax.

    I like that xhtml pushes you forward, not backward. I also think the advantage of being xml ready is a good one (e.g. when using RSS, MathML, etc. ).

    I wish we would come up with one strict, robust standard, move on and leave these dualing standards behind us. Just give us something that works well in every way, forces rigor and is as stable as xhtml has been.

    I agree with Kyle, as long as html5 (or whatever we end up with) reinforces industry standards, developer best practices, valid, well-formed and semantic markup, then I’ll be happy. If that ends up being html5, then I’ll switch over to it in a heartbeat. So far, it doesn’t satisfy all of that.

    I also like Jeremy’s idea (and Erik’s expansion) of a variable validation lint tool.

    Also wondering with Lu how accessibility fits in with html5.

    Good post, good conversation. I like Oli’s idea…group hug everyone. :-)

  77. Erik,

    “Once again, HTML is not “tag soup.” Rather, “tag soup” is the result of sloppy coding.”

    Of course, you are correct. Sorry for being unclear. I should have seen this misinterpretation coming a mile away. I MEANT, that tag soup is not allowed in xhtml and it IS allowed with html which means I have to deal with sloppy colleagues who may still use tag soup even if I don’t. We need to ALL be using the same strict syntax. With html, we are not. Just me 2 cents.

  78. Speaking with my “Editor of the XHTML specifications” hat on, I guess I want to say that there are a lot of misconceptions about what the XHTML Family is, what XHTML 2 should have been, and how XHTML works with the XML tool chain to become part of the semantic web.

    One of the advantages of using an XHTML Family language is that it requires adherence to the syntax of the language. Yes, that encourages good code. Yes, that helps reduce surprises when the page is interpreted. Validation is a good thing, and people like Zeldman have done a great job of promoting it.

    The other advantages are less tangible. The story of XML, XHTML, and the Semantic Web is not yet writ. We have years ahead of us where the best choice for some document authors will continue to be XHTML Family languages, extended with other important new or existing grammars. *That’s* the real value of the XHTML Family. Some authors take advantage of this already. More will do so as time goes on.

    For more on this, check out http://bit.ly/1aeBj and the ensuing discussion.

  79. “Bloated and unsustainable tag soup of the day” was a result of poor css knowledge or lack of css implementations in browsers. It has nothing to do with HTML or XHTML.

  80. Year 2022 argument is also an extension of the reality distortion field that XHTML supporters created and believed. In reality, HTML5 is coming faster than you think.

  81. Jeffrey wrote: “it is a bug in Firefox 3+/Windows. I’d report it myself but I’m in the OR about to have surgery.”

    I dunno man, your loyalty to the cause is slippin’ somewhat … you’ve change, dude. You’ve changed!

    ;-)

    OK, seriously once more then … quick recovery and all that, Jeffrey.

  82. I really liked XHTML1 until I found out what IE did to it. I liked it because I can use an XML library to generate the mark-up and I’ll be sure that it’s escaped and nested properly. I can use an XML library to read it and scrape it. I can use an XSD validator to check for stupid mistakes. The page crashes horribly when there is even a small error, instead of the browser double-guessing my intent. I’d rather see nothing than a page with encoding errors, which is probably what would happen if you put text in the wrong encoding in an HTML document. The problem is not the page not rendering because of errors, the problem is the page containing errors. Fail hard and early! I is good when clarity and precision are demanded of me.

    To my programmer mind, it all makes perfect sense. Then of course there’s IE, where my human mind gets a little paranoid and wonders if the people at Microsoft are programmers or not. I’m pretty sure Microsoft aren’t the greatest fans of interoperability, witness Silverlight and their stated dedication to making sure Windows is the best platform to run .NET code.

    I’m also cool with HTML5, for at least all the reasons I liked XHTML — it’s only a shame that I won’t be able to load all HTML5 pages into an XML library, because these weird SGML conventions are still in there (eg not closing some tags). Nobody writes SGML parsers anymore that take a DTD and do the Right Thing from there on.

  83. Pingback: Catix — Defense
  84. Holly, thanks for clarifying. My remark wasn’t directed specifically at your comment, but at the more general (and perjurious) association of HTML-the-syntax with “tag soup” and sloppy markup—especially since there’s certainly poorly-written XHTML floating around the internet, too.

    Both markup camps have their affectations, but it does none of us any good to argue for one by spreading untruths about the other.

    Standards and validation rules can only go so far in promoting best practices, and draconian XML parsers (assuming you’re serving XML and not HTML) can help, albeit harshly, but can cause a ton of problems if you’re dealing with any amount of user-generated content (and that’s is why I prefer serving even XHTML as the more forgiving “text/html,” but that’s another flamewar).

    Which is why it’s just as important to develop in-house rules for and to (kindly, not belligerently) educate others on good ways to do things.

  85. Seems at this stage to be as useful as discussing the use of CSS table layout – as neither will be implemented in ALL currently used browsers for some time to come. Obviously its good to know and understand whats coming in the future but as Jeffrey has correctly pointed out, 2022 is a LONG way in the future. As such I’m not sure why so many people are getting so hot under the collar about this – there certainly seems to be an over-labouring of ‘told you so’s’ from the html4 crowd.

    Personally I use XHTML1.0 Strict as it fosters good practice and discipline and I get more reliable and consistent rendering – does that make me a bad web designer?

    Most of the nay-sayers IMO are relics of the past who never wanted to up their game and improve their skills and desperately needed something to hang the prverbial on in justifying their old-skool table-ridden, poor;y marked up trash which has dogged and amateurised the web profession for years.

  86. WOW I read Pilgrims post. It harkened back to the days of yore when he attacked Dave Winer and XML in general.
    Good Times….I love misinformation and supposition.

    Simply put XHTML is an expresstion. Since a majority of us are not programmers expresstions confuse most.

    HTML is a document format. It outlines and sets guidelines. A pretty handy thing. Since most of us come from other carrier paths this allows us an easy way to apply design to a doc.

    So XHTML or HTML should be a design choice based on application.
    WOW that was easy…

    But really how long do we have to malign XHTML?

    Here is a fun XHTML namespace experiment:

    1)Create an XML doc.
    2)Write HTML markup in your XML doc
    3)Include the namespace in the root or HTML tag
    3a) Save as an XML doc.
    4)launch any browser other than IE and load the doc.
    5)Congratulations, you have just synthesized an expression of HTML via the namespace in a XML document.
    6)Remove the namespae and refresh the doc, watch the fun!

    Gee Mark the namespace works.

    If you understood how this could benefit you then you get what XHTML is for. I wonder though if the day to day information flow on the web actually needs markup that can also be an expression. Human beings just are not that complicated neither is their information.

    @Jeffrey hope you are feeling better.

  87. Wow, great discussion here.

    I wrote about this (The Long Road from XHTML to HTML)sometime ago and I am one of those who danced on top of the corpse of XHTML 2.

    The major complaint I have against XHTML is its unforgiving nature. That works when you are programming, but not when you are letting anyone write HTML (e.g. a site audience). XHTML was framed as a programmer’s paradise, but HTML is one language that targets anyone.

    But, then again, this brings up the question of why validate anyway?

  88. It’s not a surprise that non-programmers don’t understand or care why XHTML matters.

    They prefer “soft” failures that result in everything appearing to work when they make mistakes, even if it only works through a combination of luck, spit, and bubblegum.

    They simply don’t understand how easily their spit-and-bubblegum creations could break in the future, how much effort must be expended to keep them working, and how wasteful this process is when the answer is so mind-blowingly simple and they’re probably doing most of it now anyway: write well-formed mark-up.

    Unfortunately, the “don’t bother to validate” crowd takes this dangerously proud ignorance to a whole new level. It’s time the programmers stand up, defy our stockholm syndrome, and say enough is enough: if you want to write broken HTML, that’s your business, but you’re making our lives inordinately difficult, you’re holding technological progress back while we constantly waste time and money dealing with your broken web sites, and your amazingly willful ignorance is absolutely nothing to be proud of!

  89. @rupert

    The issue is not that designers are writing tag soups, but that HTML is no longer the domain of people with “expertise”. Anyone writes HTML these days and browsers have to support them. Showing a yellow screen of death when an erroneous unicode character shows up in a trackback is not helping anyone.

  90. This is a great bit of discussion here – and informative.

    As with any new thing, I’m interested in learning more about HTML5. I really need more information before I even form an opinion about what is best for me in my situation much less put anything into action. I know I’m not alone in that.

    I hope that everyone tries to remember that a supportive and welcoming community is the strongest thing we can have. Without it, it’s impossible for people to learn and get better at what they do. So please, be excellent to each other :-)

    PS – Hope you are feeling better soon Mr. Zeldman!

  91. @Divya

    Invalid unicode code points in a trackback is something that should be handled by the software (written by programmers) that handles trackbacks.

    Anyone writing HTML these days already has to conform to a wide, odd variety of existing, occasionally arbitrary rules or their HTML simply will not work — often in surprising and very unexpected ways. Using tags correctly is hardly a significant burden, since, by and large, they already do — their pages simply wouldn’t work at all otherwise.

  92. @Divya

    What bothers me most about the “why bother with (xhtml, validating, safety glasses)” crowd is that there seems to be this ridiculous impression we’re just trying to tighten up standards because we’re silly nerds who think technical rigor is more important than democratized publishing, et al.

    The reality is simply that browsers have to jump through tremendous hoops to deal with broken HTML, a truly enormous, astounding quantity of money is spent jumping through these hoops, the end result will never be perfect, and the only advantage it actually gives to the democratized publisher is the ability to ignore remarkably simple errors until they bite them in the butt sometime later.

    In return, us programmers wind up have an incredibly difficult time writing *any* code to work with HTML because it’s so mind boggling messy trying to actually parse real-world content successfully.

    So we find ourselves with HTML4-infatuated individuals telling XHTML to get stuffed, and then even going so far as to take an audacious “why bother validating at all” position — the programmers will just keep working harder to clean up after us and keep the leaky ship afloat.

  93. @Rupert I am in no way condoning tag soup generation. But I do not understand why a page should validate to the most minute level of not putting a < div > in an &li; li > or < a >

    The idea of the yellow screen of death is good for programmers and bad for people in the business of publishing online and for browsers. My only complaint is there has to be a graceful error handling which neither XHTML 1 nor 2 have tried to offer.

  94. Just so I’m clear… we all know the difference between ‘well-formed’ and ‘valid’, right?

    One’s choices of XML schema and content type are orthogonal to one’s desire to close tags correctly, and indent markup nicely.

  95. This is already a better discussion! Mark one for reasoned discourse. Thanks, Mr. Zeldman. (May you heal quickly.)

    About testing for XHTML-style markup in HTML5: using contextual clues instead of expressly declaring your intent wouldn’t be very stable or transparent (it’s literally not marked up for it). Right now your page will survive a badly formed meta tag unscathed, and that’s a godsend, especially for hand-crafted pages. Start sniffing for trailing slashes to decide how to interperet the page–you see where that’s headed. Probably not catastrophe, but likely trouble.

    Nevertheless, declaring your mode of markup is a great idea! Count me as another yea vote for that.

  96. So, can we have two sorts of W3C validation for HTML 5 documents, then? Two ‘modes’ of validation?

    – ’strict’ (XHTML-style) mode: all tags should be closed,

    Optional reporting of implied tags is a planned feature for Validator.nu. As a matter of policy, I don’t promise when I’m going to implement it, because people wouldn’t like it if I failed to deliver on a promised deadline.

    all tags lowercase,

    I suspect you don’t really want that for SVG elements. The problem is that by the time the parser decides whether something is an SVG element, the information about the original case has already been lost. (And changing this would be undesirable in an implementation that is also used is setting where performance matters.) I’m not saying never, but I say no for now.

    attributes always in quotes, etc.

    Recent changes to what constitutes a parse error should make the validator catch the cases where unquoted attributes actually cause harm. I’m going to wait and see how that works out. Right now I’m more interested in developing good diagnostics for authors using /> immediately after an unquoted attribute, because those don’t mix well. (The slash becomes part of the attribute value for compatibility with existing browsers.)

    The ‘Strict’ mode in HTML5 could be activated for the validator by some kind of additional simple ’switch’ in the code, like:
    <!DOCTYPE html "Strict">
    …as opposed to the ‘default’ mode which would be triggered by the ’standard’ HTML 5 doctype:
    <!DOCTYPE html>

    That particular switch isn’t workable due to legacy doctype sniffing. <!DOCTYPE html SYSTEM "about:strict"> wouldn’t have that problem. However, I’m following the RELAX NG wisdom of not putting validator directives in the input document, so I intend to implement a checkbox in the UI instead.

  97. A wise Budd once told me just do the best you can—write the best code you are capable of—and everything will be fine. It doesn’t really matter what standard we use, as long as we do our best the web will be fine.

    A theoretical HTML5 validator could offer levels of validation, like WCAG’s graded levels. This could also check if you’re using HTML-style or XHTML-style elements, or mixing them (“warning!” :). This way we wouldn’t need a switch.

    All the best to @Zeldman for a speedy recovery!

  98. I’m glad to be an XHTML 1.0 user and proponent, and honestly am quite dismayed that people would celebrate and use HTML 4.01 as an alternative.

    Also, I have no problem whatsoever serving up my XHTML 1.0 as text/html, but look forward to the day when I can safely serve up xml.

    My hope is that (x)HTML 5 will be more forward looking with regards to semantic markup, it seems a bit restricted to me.

  99. Jeff, I know this is off-topic, but I have to turn off all styles in order to see the bottom half of the comments section, and to add my own comment.
    You probably already know about this.
    (Using Win XP FF3.0.11)

    J

  100. Personally I use XHTML1.0 Strict as it fosters good practice and discipline and I get more reliable and consistent rendering – does that make me a bad web designer?

    Most of the nay-sayers IMO are relics of the past who never wanted to up their game and improve their skills and desperately needed something to hang the prverbial on in justifying their old-skool table-ridden, poor;y marked up trash which has dogged and amateurised the web profession for years.

    Oh boy… last time i checked, 2003 was over some six years ago…
    Sadly, it appears that “doctype neutrality” is still an utopian wish.

    Again and again and again: what html OR xhtml have to do with table layouts? Are table layouts nonexistent in websites coded in xhtml 1.0 Strict? Who chooses to code a table layout? the doctype or you?
    It appears the answer is only one…

  101. @Michelle and @Jenny:

    Yes, it is a bug in Firefox 3/3.5 that needs to be reported.

    Firefox 3.0/3.5 (Windows only) cuts
    this valid web page’s content in half
    (and perhaps others as well).

    The page’s content is valid (UTF-8) as is its markup. Two top-notch developers besides me have investigated: Code-brother-in-arms Noel Jackson and Nikolay Bachisyski, both top people at WordPress. Their findings:

    * The DOM loads properly.
    * There isn’t an (X)HTML parsing problem.
    * Disabling JavaScript makes no difference.
    * Disabling CSS enables the page’s content to display in Firefox, as you discovered.
    * But turning CSS back on cuts the page in half again.
    * So is there a problem with the CSS? No.
    * Even when (CSS-3-related) validation warnings (including our favorite CSS 3 rounded corner technique optimized just for Mozilla) is “fixed” in (that is, temporarily removed from) the CSS file, the page is still cut in half in Win FF3/3.5.

    In short, the content is fine, swell, standards-compliant, everything web content should be——but good old Firefox 3.0/3.5/Windows one of the web’s best browsers, cannot parse it without choking. A sad situation indeed

    The wise http://www.twitter.com/optimiced claims that Firefox will stop gamauching itself with a single, simple change to oneline of my site’s CSS:

      The added style below can be simply changed in:  
    wp-content/themes/zeldman-v2/style.css?0707090641
        on line 94, change:  overflow: auto;
        to:                  overflow: visible;
      And that's all! :-)
    

    I’ll try it as soon as I’m a bit better (still in early recovery from surgery yesterday).

    His full comment available for your and my perusal at http://www.optimiced.com/web/2009/zeldman/style-fix.css.

    Awesome fellow that he is, he shares credit for the fix:

    @zeldman btw, the idea wasn’t mine: http://bit.ly/ZIkLV, I just made full tests later: http://bit.ly/n8r0X / http://bit.ly/dPSlU
    38 minutes ago from web in reply to supernovia

    Noel Jackson, Nikolay Bachisyski, and I still call the pointless abrupt page cut-off in Firefox (and no other browser) a bug in Firefox. Perhaps one of our Firefox-loving fearless readers will report it before I do? Gracias amigos, all!

  102. I’ve always found the discussion between html and xhtml quite moot. Sure, the true purpose of xhtml was never used, but is there a good reason to choose html 4 above xhtml 1. I assume you don’t really win much either, and xhtml at least gives you better validation, allowing you to write cleaner code more easily.

    You could of course argue that xhtml isn’t cleaner, but I’d gladly disagree and leave it at that. That’s always been my reason for using xhtml, so my html validator picks the right errors for me.

    Apart for some theoretical discussion, I don’t think people shouldn’t care too much, I’m quite surprised to see actual rivalry going on between both sides. You’d wonder if there weren’t more important problems to discuss huh.

    (oh, and what the hell did you do to the contact form Jeffrey. The labels are underneath the inputs now, except for the captcha question? At least in Opera they are, and in FF3.5 it didn’t even show up, the page stopped about halfway through the comments. New site, new bugs huh).

  103. (oh, and what the hell did you do to the contact form Jeffrey. The labels are underneath the inputs now, except for the captcha question? At least in Opera they are, and in FF3.5 it didn’t even show up, the page stopped about halfway through the comments. New site, new bugs huh).

    Kindly read my comment to Michelle and Jenny. The new layout and markup, standards-compliant in every way, causes Firefox 3.0/3.5 in Windows to swallow its own vomit while reciting the Lord’s Prayer backwards roasting virgins.

    As soon as I’m up to it (soon!), I’ll try the (needless except for Firefox) CSS workaround Michel suggested and test to be sure it doesn’t harm other browsers.

    Thanks for writing and caring.

  104. Just as an FYI, the page weirdness happens with any Gecko browser on my Linux box (Ubuntu 9.04 with Firefox, Epiphany).

    But back to the point, I really couldn’t care less what the markup language I use is called. As long as it makes sense, it’s just another set of rules to learn. HTML5 looks pretty interesting and I can’t wait to play with it properly.

    What I can’t get my head around, however, is how this is some kind of victory for one group over another. I must have missed the memo that split the web developers from the platform programmers in to 2 opposing factions. I didn’t even get a flag to wave.

    P.S. I hope you’re on the mend, Jeffrey.
    P.P.S. Your comment form doesn’t seem to like email addresses at .info domains.

  105. @Henri:

    So it looks like some of the ideas that we discuss here can be implemented in the future versions of the Validator.nu (and the W3C Validator, too?)? This sounds promising! :)

    Basically in HTML 5, I think that we somehow need to be able to differentiate between the two syntax styles: XHTML, and HTML. [Note: XHTML 5 is a whole other story, I now mean only HTML5 served as text/html.] HTML 5 allows both syntax styles. But we should be able to differentiate between them and check our documents accordingly.

    As to my idea for a ‘switch’ — on second thought, I realised that you are totally right, and that a simple checkbox (or dropdown list) on the validator page will be the perfect solution. Like: “Select syntax style: a) auto-detect, b) xhtml-style, c) html-style”.

    I think this needs more discussion, but I like how the ideas start to emerge and take shape…

  106. @Zeldman:

    Try to implement this simple fix in your CSS, when you can. As to the Firefox bug itself, I’ve never seen anything more strange, I think… :)

    @Jackie:

    Can you check please, if the test page (in which I have applied the fix, which supposedly fixed this annoying Firefox weirdness) is displaying correctly on your side, in Firefox (Linux)? Thanks in advance!

    Cheers,
    –Michel,
    alias the Wise Awesome Fellow:-D

  107. @Henri, adding a checkbox to the validator UI (when you get the chance) is probably the best way to go, without abandoning the nice, clean (and wonderfully agnostic) <!DOCTYPE html>.

    My musings on looking for the trailing slash on the first meta element were an admittedly problematic attempt to figure out how to automate HTML5 validation according to a “strict” XHTML syntax.

    Oh, and I’m sure we’re all glad you’ve made it out of surgery, Jeffrey, and hoping you recover well.

  108. I don’t eat meat, and back when I was living with my brother, who does, I got him to try a particular brand of vegetarian burger. He was surprised, saying it tasted just like beef, so what was the point? Why don’t I just eat beef? I pointed out that, because it tasted like beef but wasn’t, I was more than happy to eat the burger that didn’t contain beef. Neither of us were ever going to agree with each other, or make each other switch our ways, but neither did it matter.

    Which is maybe a silly analogy, but we shouldn’t be suspicious of variance of perspective, and we shouldn’t construe an argument as being had when people fall on different sides of the same fence.

    And I think a lint tool that would allow you to define a stricter subset of HTML5 to code to is an awesome idea.

  109. Back from hospital although still mostly resting on surgeon’s and nurse’s orders (and ’cause I don’t feel so hot, and won’t for days).

    However, could not help noticing and responding to this tweet.

    Ian Hickson, prime mover behind HTML 5, thinks this post is anti-HTML5. He tweets:

    @zeldman The WHATWG/HTML5 effort has done more to reach out to Web developers than any other spec work I know of. Why the negativity?

    Hixie, sorry if you read it that way. Are you sure you read it?

    This post is not anti-HTML 5, nor has bulk of A List Apart coverage been anti-HTML 5, nor will it be. On ALA, we’ve run one Intro to HTML 5, one critique of the way semantics are handled in HTML 5, and plan to run many more articles on uses of HTML 5, including some that raise concerns. That’s only fair.

    Back to this post. If you actually read it, its targets are people with poor social skills who use the cessation of HTML 2 activity to ridicule developers who have used XHTML 1.0. Mark Whatsisname goes so far as to write doggerel ridiculing me for having recommended XHTML 1.0 to readers of my book, ALA, and The Web Standards Project. (And apparently also to Mark. But later, when he changed his mind about using XHTML 1.0, he became bitter about it, for reasons that make sense to him, perhaps, but not to me.)

    I don’t mind interest in HTML 5—I strongly encourage that interest (while also reminder readers that XHTML 1.0 is a stable spec that can be used indefinitely if it meets their needs.)

    Eric Meyer and I used HTML 5 (or the parts that are safe to use in modern browsers) in our redesign of An Event Apart, the site of our conference that teaches good practices in web design. Hardly the sign of HTLM 5 haters to use HTML 5 to program their web design conference best practices site.

    Indeed, Eric Meyer and I have repeatedly asked you, Ian Hickson, to speak for us about HTML 5 at An Event Apart. Our emails went unanswered. It’s understable; you’re busy.

    Krista Stevens, Erin Kissane, Carolyn Woods and I have also asked you to write about HTML 5 for A List Apart. You haven’t answered these emails either. Again, you’re busy, and I understand. I can’t answer every mail I get, either. Even when the person writing to me is doing so in hopes I can provide educational benefit to others.

    I didn’t write this post to take you task for ignoring our good-faith letters trying to get you to help us explain to the community the principles behind HTML 5. I would not do that. I’m not like Mark Whatsisname. I don’t write bullshit about people because they don’t answer my emails, or because they have a different opinion about HTML than I do. Only childish chronologically-adult grownups with poor social skills do such things, and only an industry like ours would find jobs for people with bad business and social skills. Presumably Mark is so talented at whatever he does, that his lousy behavior as a quasi-journalist and human being doesn’t matter to his employers or his small cult following of readers, some of whom may share his poor social skils, and wish they too had the balls to write Mad Magazine-style parodies about colleagues with whom they disagree.

    That’s not me. Personal attacks are not kind or wise. Back in the day, I’ve attacked Netscape and Microsoft for failing to support standards, but that was about the web, not about individual developers employed by Netscape or Microsoft. And I’ve since called attention to problems in Firefox, Opera, and Safari in the interest of helping their engineers do a better job of supporting standards. I respect the engineers and even—horrors—the marketing people behind these companies, and I believe, if rightly persuaded, they can get behind the goal of a better web for all.

    I think you are doing the same thing I’m doing, only at a much higher level, by creating a spec that will help browsers do what they ought to do. For that I salute you, and as I’ve indicated, I and several other people I respect have reached out to you in hopes of hearing directly from you about your goals and dreams for HTML 5, and ways (beyond your own site) to reach out for designer, developer, and “UX person” input.

    Since you dislike my post, I can only conclude that you objected to this section of it:

    And guess what? HTML 5 is as controversial today as XHTML was in 2000, and there are just as many people who worry that a specification of which they don’t entirely approve is being shoved down their throats by an uncaring elite. Only this time, instead of the W3C, the uncaring elite is Mr Hickson, with W3C rubber stamp, and input from browser makers, including his employer.

    There I was not stating my opinion, but rephrasing (for those who haven’t investigated these issues) the beefs I’ve heard from people who have concerns about HTML 5 and your role in it.

    Without you, it wouldn’t be happening, and this is something you can mainly be proud of.

    But you as a person are far harder to reach than I am, and this may account for some of the negativity some people feel, which I summarized in that paragraph of my post.

    The main point was to parallel the fact that HTML 5 has as many detractors today as XHTML 1.0 did on its introduction, and I raised this point to try to stifle some of the gleeful asshats who were too busy lording their “superior” knowledge of standards over their fellow developers to stop and think—and maybe try to educate and help, instead of putting down their colleagues.

    Now back to my sickbed.

    Hope this helps explain my post.

    Would love to hear your thoughts here.

  110. Well said – I was surprised by Ian’s tweet as well as most of the negativity came from the comments, not from your post.

    Get well!

    s/HTLM/HTML
    s/attached/attacked

  111. My tweet was about http://twitter.com/zeldman/status/2532060700 — not about this article.

    Hixie: That was me at my worst, and for that I apologize. In my (very weak) defense, I was coming off narcotics, having had surgery the night before.

    I guess I can be an asshat too. I am sorry.

    The narcotics have since worn off, and I’d love to chat with you at any time (well, once I recover from surgery, which should be in about five days).

  112. I can’t find any e-mails in my archives about A List Apart or An Event Apart. What e-mail address did you send those e-mails to? The only e-mails I have from Eric in the past few years are from a thread I initiated, which was quite friendly. I can’t find any e-mails at all from you, Krista Stevens, Erin Kissane, or Carolyn Woods.

    These archives go back to 2005 or so; was this before then?

  113. Apology completely accepted; I didn’t have the context, just saw your tweet when I woke up! I hope you’re recovering well.

    I’m sorry that we failed to connect by e-mail; it’s my intention to reply to all the e-mails I receive, but I really can’t find any trace of e-mails about the events you mentioned.

    (I have to admit that I generally try to avoid traveling, so I haven’t done many talks at any conferences in recent years. The spec work is taking a lot of my time, so I’ve been letting other people in the HTML5 community take up the slack in terms of giving presentations. I even turned down the request from Google that I present at Google I/O and the request from Apple that I present at WWDC! I’m ramping up to last call for HTML5 in October, but maybe after that my schedule will be more flexible.)

  114. Well said, Jeffrey!

    For now, I just continue to read this ongoing discussion & sharing of ideas with more and more interest! :-)

  115. A humble suggestion. Rather than play out a public argument, wouldn’t it be more productive for Ian and Jeffrey to get together and do a Q&A special for ALA on HTML5?

    God knows that many of the comments on this and other articles – which I think in part accounts for some of the emotion rising over all this – tells me that we, collectively, as designers and developers need it.

    I’d love it, and sure I’m not the only one.

    Get well soon Jeffrey – one for the to-do list when you’re back, maybe?

  116. A humble suggestion. Rather than play out a public argument, wouldn’t it be more productive for Ian and Jeffrey to get together and do a Q&A special for ALA on HTML5?

    I have no argument with Ian, public or private.

    Ian, if you could DM your working email address to me on Twitter (I’m at twitter.com/zeldman), I’d be glad to be resume this in a few days when I’m in better shape.

    Thanks for your consideration.

  117. Presumably Mark is so talented at whatever he does, that his lousy behavior as a quasi-journalist and human being doesn’t matter to his employers or his small cult following of readers, some of whom may share his poor social skils, and wish they too had the balls to write Mad Magazine-style parodies about colleagues with whom they disagree.

    Dear Zeldman, i think insulting and belittling readers of other blogs for the sole purpose of attacking the author is really bad taste, and offensive to people who want to f… read blogs, who don’t necessarily side with one or another, and want to be left out of this bickering. As an abitual reader of your blog, Mark Pilgrim’s blog, and [insert random standardista‘s name here]’s blog, i dont’ feel particularly good about this one.

  118. ll i use html for now is HTML for is email campaigns.

    XHTML has a offered a steady and strict platform for years. While HTML 5 seems a great step forward in simplification it also seems to dumb it down …

    Plus with 2022 being time when its a viable option, im not going to use it for a while. Don’t even get me started on CSS3 …

  119. Dear readers, please also see Adactio’s Misunderstanding markup, wherein the wonderful Jeremy Keith clears up common misunderstandings using clear, simple, straightforward language, without attitude or condescension.

    I can’t resist quoting the opening in hopes of whetting your appetite for the rest. (It’s a short read and well worth your time):

    The W3C announced last week that the XHTML 2 Working Group will wrap up at the end of this year. This should have been a straightforward, welcome announcement. Instead it has confused a lot of people who believe that it heralds the end of XHTML—see, for example, the comments on Zeldman’s blog post.

    This confusion is understandable given the lamentable names that have been assigned to different technologies. This isn’t the first time this has happened…

    JavaScript sounds like it has something to do with Java. It doesn’t. Apart from some superficial syntactical similarities, they have nothing in common. Java is to JavaScript as ham is to hamster.

    DHTML sounds like it has something to do with HTML. It doesn’t. DHTML is a catch-all term to describe the action of updating the CSS properties of HTML elements using JavaScript. I have my own catch-all term for the combination of HTML, CSS, and JavaScript; I call it web development.

    And so to XHTML 2. You’d be forgiven for thinking it has something to do with XHTML 1.0 or XHTML 1.1. It doesn’t.

    XHTML 1.0 is simply a reformulation of HTML 4 with XML syntax:

    * lowercase tag and attribute names,
    * quoted attribute values,
    * mandatory closing tags for p and li elements,
    * a slash at the end of standalone elements like img, br, and meta.

    Jeremy is the kind of doer/teacher I love.

  120. @Robert E. Stockpile ,

    I wrote my initial post in response to a news flash, expecting to see a mixture of wise, informed comments and comments by some folks who were confused and needed more information.

    Information needs revealed in the latter sort of comments would help guide my research. What research, you may ask?

    Not only do I need to learn more myself as web designer/developer, and not only do I wish to be sure that my colleagues are abreast of the latest developments, but, along with ALA’s editors, I’m always seeking useful HTML 5 content for A List Apart—and what better way is there to learn what’s useful than to throw out an open-ended post about HTML 5 and see what you collect?

    Additionally, Eric Meyer and I, as co-founders and content mavens of An Event Apart, are always attempting to learn what our audience knows and doesn’t know. Again, I hoped to learn as much from the comments of the confused as I would learn from the comments of the informed.

    What I did not expect was a small but virulent strain of dark wizardry, in the form of comments that ridiculed developers who use XHTML, or who didn’t know as much about HTML 5 as the person writing the mean-spirited comment.

    There weren’t a ton of these, but even one felt like too much, if we’re supposed to be a community of professionals who teach and help each other.

    Some of these negative comments led to negative blog posts, whose tone I found offensive. I didn’t take personal offense, but I objected emotionally to the creation of a false class system in which some people claimed to be better than other people because they knew a bit more about an unfinished spec, or because they had retreated to HTML 4 instead of using XHTML 1, and felt that the cessation of work on XHTML 2 gave them a pulpit from which to finger-point.

    I was already engaged in writing “In Defense of Web Developers” when I came upon Mark P’s parodic poem. I recognized the cleverness of it, and didn’t take it particularly personally in spite of its portrayal of me as an evil jackass and misleader of millions.

    The “poem” calls XHTML the house I built. It pretends I personally wrote the spec, forced the web to use it without so much as addressing any of its drawbacks, and persuaded Microsoft not to support its MIME type correctly.

    This is silly and the author knows it. His little feat of doggerel gives me more power than I have. It blames me for things that aren’t blameful and attempts to shame me for teaching a best practice to people who, at the time, wrote tag soup. Most of all it glories in the “destruction” of my little house of cards—which isn’t mine, and which hasn’t been destroyed. (XHTML 1 will probably outlive me.)

    Mark’s poem didn’t make me cry or punch a wall, but it represented a “nyah, nyah, told you so, dumbass!” attitude that I find objectionable in any realm. When such an attitude encroaches on the realm of web development and web education, I feel called upon to publicly reject it, and to try to focus the conversation on learning, helping each other, and helping those who write our specifications stay in touch with our needs.

    (The WHAT working group responsible for HTML 5 has done more outreach than many other groups responsible for web specs, but not enough of us have been sufficiently aware of HTML 5 to provide all the feedback the group needs.)

    Back to Mark P. I have always loved his free online book, Dive Into Accessibility, and he has done other good and important things for the web. I have no personal beef with the gent.

    I do object to personal attacks, particularly when they impugn not just the person being ridiculed, but more importantly, anyone who has learned from that person. This is not the way to interest the community in learning about or contributing to HTML 5; nor does it present a true or fair picture of XHTML 1.0’s merits.

    My objections go no farther than that. And if I mentioned behavior unbecoming a professional or a grown-up, well, that’s my take on that kind of discourse on the subject of XHTML and HTML 5 at a time when so many are confused and concerned. A person who feels entitled to ridicule others can hopefully take a little gentle ribbing in return. Neither Mark or I will lose sleep over each other’s words, you can be sure. Further, I’m sure we both want what’s best for the web, even if we sometimes disagree on what’s best or how to persuade others to consider our point of view.

  121. As if all of this wasn’t operatic enough, some fool has left rude comments on Mark Pilgrim’s site and signed them Jeffrey.

    Mark Pilgrim may have thought I wrote them.

    Mark Bernstein certainly assumed I did, and seized the opportunity to write an essay criticizing Pilgrim and me for our rudeness.

    It would be a fine (if unimportant) argument if I had in fact written those comments, but I didn’t.

    I can’t defend my honor on Bernstein’s site, since his site does not include comments, so I have to point out here, on my own site, that I didn’t write the asinine comments labeled “Jeffrey” on Mark Pilgrim’s site.

    Apparently the comments offended Mr Pilgrim. I can see why they would. They were stupid, offensive comments.

    Apparently another friend of mine assumed I wrote the comments while on post-surgical narcotics. Also not true.

    I hope Mr Pilgrim is not angry at me for stupid comments I did not write. I also hope Mr Bernstein finds something better to write about soon.

  122. Please. This is not worth it. Been using XHTML1 for 5 years or so. It worked very well. I’m sure HTML 5 will work (out) very well, too. HTML 4 was a good standard if you didn’t use browser-specific additions, and CSS instead of font-tag soup. Don’t see why there would even be a need to say »told you so«. The discussion is without merit. The future will be bright.

  123. And now for something completely different. The font style in the comments is “georgia, ‘times new roman’, times, fantasy” with quotes in italics. However, what I’m looking at right now is oblique (glyphs artificially skewed) and not actual italics, i. e. the usually completely seperate (and much more asthetically pleasing) glyph shapes for serif fonts. Is something wrong with my browser (Safari 4) or OS (X)? Should I submit a screenshot?

    Ah. Never mind that. Just found out that I apparently deactivated all of Georgia except for the normal Roman style, so Safari was forced to fake the italics on my system.

  124. What I do not understand, is why the discussion at all???

    XHTML 1.0 is not dead.

    HTML 4.01 is not dead.

    HTML 5 is the future.

    In HTML 5, you can use XHTML syntax or HTML syntax — this is your own choice. You can also write XHTML 5, if you like.

    So, where’s the problem and why the war?

    Are designers who prefer XHTML 1.0 worse than designers who prefer HTML 4.01? Are designers who prefer HTML 4.01 worse than designers who prefer XHTML 1.0? C’mon, people, this is really stupid… We are all at the same side of the fence! :)

    And I, personally, will continue to write XHTML syntax code. I don’t think this makes me a worse or better designer than others, who prefer the HTML syntax.

    Peace, brothers! :-)

  125. I actually feel more confused than ever. And I thought the standards were meant to simplify the whole system :/ I mean what exactly is XHTML and HTML? Why would I use one other the other. The way I saw it was HTML was old, and XHTML was the modern version that used proper tags and semantic code. Now they’re saying XHTML is bad and HTML is the way forward??? What gives! I think they need to clear as to what we’re heading towards, and this whole 2022 bullshit is ludicrous. In 13 years HTML5 will be obsolete we’ll have some other crazy system in place, so what’s the point in waiting that long?

    Can anyone clear all this up?

  126. Jeffrey, if it means anything, I’ve been quietly following all this for days and have found your words enlightening and your demeanor admirable, especially given your situation. Even your post-op flash of sass towards Hickson wasn’t too far out of bounds. ;)

    On the point at hand, I suppose we’re on the same page. I don’t really understand what the fuss is about, particularly Mark’s rather silly poem about XHTML. It seems like attempting to perpetuate a religious debate rather than simply accepting that XHTML 1 continues to be a fine standard (and continues to be my preference over HTML 4 at present).

    Regarding the tone of conversation: as someone who has managed a small, successful community for the past 6 years, I’m afraid the only method I’ve found that reliably works to maintain the desired tenor is to outright delete the comments that go too far and speak out on the ones that approach the line. Over the course of time you find yourself moderating less and less as everyone comes to understand the required standard for conversation. Of course deleting posts is anathema in many circles as I suspect it is for you, which leaves us where we are: sometimes the pot boileth over and we spend the week cleaning up. :) If you ever find the middle path between the two, I’d be keen to hear about it.

    Technical problems, a wide-ranging debate, and major surgery… when it rains it pours, no? Cheers to you sir, and best wishes for your recovery.

  127. While it’s true that xhtml users have been ridiculed by html supporters, the opposite is also a reality: people who still accuse whoever chooses html 4 to be a bad developer who codes tasty tag soup wrapped in a trashy table layout.
    I think it’s more of a generalized issue.

    I’m looking forward to one day in which (hopefully) debates about accessibility, design, user experience, creativity, and the role of human responsibility and decisions in making websites will get more attention than (yawn) markup, doctypes, robotic stuff…
    Will it happen?

  128. Well, I just * had* to share this email I received from someone evidently confused by this whole ‘XHTML is dead’ thing. Made me laugh, anyway …

    “I’ve been interested in your book for a while, and checked out SitePoint’s free sample chapters. I noticed before much else that you use XHTML. I’m wondering if you’ll be coming out with a third edition using HTML 5 now that XHTML 2 has been dropped in favour of HTML 5.”

    /me slaps head

    Well, there may be a third edition at some point in the future, but highly unlikely that it will be for those reasons!

  129. First of all, XHTML 2.0 is dead, not XHTML as a concept. This news says a lot more about the W3C than it does about the technology. The XHTML 2.0 spec is was highly pretentious to say the least. I’m no Bert Bos or Dave Raggett by any measure, but even I could see that XHTML 2.0 was stillborn. It made the same mistake that was made with the original HTML: targeting scientists and academia, instead of tackling real-world issues. HTML 5 gives you canvas, audio, video… XHTML 2.0? blockcode.

    At the end of the day, in terms of markup, XHTML 1.0 was only as good as HTML 4 was. Similarly, XHTML 5 can only ever be as good as HTML 5. It says nothing about XHTML as a technology and as a concept; it is wholly dependent on the underlying specification.

    So it’s unfair of certain people to use this news as an excuse to ridicule anyone who ever supported XHTML in the first place. Jeffrey, just remember: it was you who persuaded the web design community to take their code seriously; to separate content from presentation and behaviour; to use semantic markup. While people like Mark Pilgrim preach to a handful of alpha-geeks, constantly looking down their noses at anyone deemed to be below their level, your words reach the “average” web designer/developer – the “man in the street”, if you will – and make them take notice.

    Anyone can convince a few alpha-geeks to follow standards -that’s simply preaching to the converted. You helped to convince the masses – now that’s an achievement to be proud of.

  130. Jeffrey Zeldman I can’t believe you of all people are using this bullshit “HTML5 wont be ready until 2022″ nonsense to support your rant.

    Much of what you say about XHTML vs HTML is very true, but you know damn well that HTML5 is expected to be ready as a candidate release by 2012!

    The 2022 date being spread about as the date HTML5 will be ready is doing nothing more than damage an attempt at actually dragging the web forward. 2022 is the date the W3C/Hixie expect the spec to have full support by at least two browsers (or well on the way to this with the detailed test suites). You of all people know there are no mainstream browsers with full XHTML/HTML support and there are certainly no test suites to help this happen.

    Spreading these sensationalist, harmful comments will help nobody.

  131. I actually feel more confused than ever. And I thought the standards were meant to simplify the whole system :/ I mean what exactly is XHTML and HTML? Why would I use one other the other. The way I saw it was HTML was old, and XHTML was the modern version that used proper tags and semantic code. Now they’re saying XHTML is bad and HTML is the way forward??? What gives! I think they need to clear as to what we’re heading towards, and this whole 2022 bullshit is ludicrous. In 13 years HTML5 will be obsolete we’ll have some other crazy system in place, so what’s the point in waiting that long?

    Can anyone clear all this up?

    Ok I’ll be blunt here; you don’t actually know what you’re talking about. However it’s good you’re asking for things to be cleared up and I’ll see if I can answer some of your questions. Im going to be pretty short and to the point, there is more depth to some of these answers that I wont go in to but I urge you to seek them out.

    I mean what exactly is XHTML and HTML?

    HTML is a hypertext (semantic) markup language, XHTML is a hypertext (semantic) markup language based on XML. Neither are more or less semantic than the other though there are difference, mostly in syntax. XHTML can also do some rather more advanced stuff which I wont go into.

    Why would I use one other the other.

    If you don’t need any of the advanced XHTML abilities then it doesn’t matter, it comes down to personal choice. Here’s the thing… you only get these advanced abilities if you serve your XHTML as application/xhtml+xml, which is how it really should be done, but if you do this then your site wont work in IE because IE does not properly support XHTML. You end up having to serve your XHTML as text/html… this is most likely how you do it right now if you’re using XHTML. The problem some people have with this (myself included) is it’s no better than just using HTML 4.01 in the first place.

    The way I saw it was HTML was old, and XHTML was the modern version that used proper tags and semantic code.

    Sadly that’s the way many if not most web designers see it. HTML certainly is olderer but there is barely any difference in the choice of tags and virtually no semantic difference.

    Now they’re saying XHTML is bad and HTML is the way forward??? What gives! I

    Probably because they realised that all these great benefits of using XHTML came to nothing (thanks IE) and all along we’ve been using a messed up version of HTML. People are embracing HTML5 as the way forward but HTML5 can be served as both HTML or XHTML.

    and this whole 2022 bullshit is ludicrous. In 13 years HTML5 will be obsolete we’ll have some other crazy system in place, so what’s the point in waiting that long?

    See my earlier comment further up, we are not going to be waiting until 2022.

  132. Oops, looks like I should have validated my markup before submitting that last comment ;)

    Enough from me…

  133. @Ryan Roberts:

    Jeffrey Zeldman I can’t believe you of all people are using this bullshit “HTML5 wont be ready until 2022″ nonsense to support your rant.

    Rant? Really?

    Here’s what I’ve been saying: HTML 5 is an emerging specification that we need to learn more about; parts of it can be used today (which is one good way of learning about it); XHTML 1.0 is and will remain a valid working specification; parts of HTML 5 are controversial today, just as parts of XHTML 1.0 were controversial ten years ago; and developers should help each other, not insult each other over their choices.

    What part of that is a rant? None of it.

    you know damn well that HTML5 is expected to be ready as a candidate release by 2012!

    Actually I didn’t know that until you said it in your comment. I reported what I did know. An article in Wired quoted Hixie as saying HTML 5 would be ready in 2022. I have no agenda in repeating that information. I used it merely to point out that HTML 5 is still very much in development.

    If XHTML 1.0 is stable, HTML 5 is still in development, and XHTML 2 is off the table, the sky isn’t falling, there’s no crisis, and there’s certainly no cause for name calling in our community.

    I’m sorry if you understood me to be saying anything besides those things.

    Anyone losing their cool over this stuff needs to go for a swim or a bike ride or a therapy session. Anger, finger-pointing, accusations, insinuations, ridicule—these strong, negative emotions and behaviors are out of place in a discussion about markup standards.

  134. Do you happen to have a link to that article? I couldn’t find it. I’ve mentioned 2022 as a date I hope to see two complete and bug free implementations of all of HTML5 in various articles, but I wasn’t aware of one where I was quoted as actually saying it’d only be ready by then. The plan is to have it more or less “ready” by October this year. (We’ve never had two complete and bug free implementations of any Web spec before as far as I know, so 2022 is pretty optimistic in a way.)

  135. @Jeffrey Zeldman

    What part of that is a rant? None of it.

    The very first paragraph sounds ranty to me :/

    Actually I didn’t know that until you said it in your comment. I reported what I did know. An article in Wired quoted Hixie as saying HTML 5 would be ready in 2022. I have no agenda in repeating that information. I used it merely to point out that HTML 5 is still very much in development.

    First of all I apologise for the aggressive tone in my comment, it comes from frustrations at the repeated mentions I see of the 2022 date being the “done date”. The interesting stuff is going to be happening sooner rather than later, as you say yourself HTML5 is already being implemented. However I’d have thought this is something you would have known.

  136. Let’s not forget that XHTML is required for using certain features in certain javascript libraries. HTML 4.0’s loose definition and subtle differences in doctype structure mean some features won’t work or won’t work as expected. See documentation on Prototype and JQuery for details.

    I was skeptical about the usefulness of HTML 5 at first, but I’ve been sold on the demos I’ve seen so far, and I’m glad it’s possible to stick to the XHTML syntax, which I strongly prefer (I don’t like my code yelling at me, among other things). Assuming the above-mentioned issue is not going to cause a problem in HTML 5, I’m all for the move.

  137. Ryan:

    First of all I apologise for the aggressive tone in my comment, it comes from frustrations at the repeated mentions I see of the 2022 date being the “done date”.

    No problem at all, and completely understandable given the knowledge you possessed about the actual release date.

    However I’d have thought this is something you would have known.

    I would have thought so, too. :D What I don’t know could fill a million books.

  138. Ian:

    Do you happen to have a link to that article? I couldn’t find it. I’ve mentioned 2022 as a date I hope to see two complete and bug free implementations of all of HTML5 in various articles, but I wasn’t aware of one where I was quoted as actually saying it’d only be ready by then.

    The Webmonkey article’s here: “HTML 5 Won’t Be Ready Until 2022. Yes, 2022.” (The link also appears in paragraph 6 of my post, above.)

    The author, Scott Gilbertson, takes his information from TechRepublic’s “HTML 5 Editor Ian Hickson discusses features, pain points, adoption rate, and more“—he doesn’t appear to have interviewed you directly. And although the story is formatted like an article, it appears to be more of a blog post.

    Indeed, rereading it, Mr Gilbertson seems to have done this: first he read a blog post by Jeff Croft expressing anger and dismay at the projected release date of HTML 5. (The post may be down when you follow the link, owing to “maintenance downtime or capacity problems.”) Then Mr Gilbertson checked TechRepublic to verify that Mr Croft had quoted your dates correctly. Then he published his article, which echoes Mr Croft’s point of view.

  139. That article, in the text, if not the headline, correctly points out that we already have implementations and that 2022 is only “for browsers to comply with every line in the HTML 5 spec” (something we’ve never seen before for any other Web spec), and that it’ll be ready (as in, people will be able to use HTML5 features) long before that. The headline of that blog post really is misleading, though.

    I expect HTML5 to be obsolete by the time we get two complete implementations. Hopefully by then we’ll have moved to a “living document” model where HTML doesn’t have version numbers any more and this kind of thing isn’t worth talking about. :-)

  140. Maybe I’ll go back to writing tag-soup webpages in HTML4 and throw out everything I’ve taken on board about code clarity, semantics and separation of content from presentation.

    And how are those all related to HTML4? Do trailing slashes make your XHTMLish (served as text/html) documents more semantic/clear etc. ?

  141. Whilst it’s encouraging to see a spirited debate in the comments here and in Jeffrey’s previous post XHTMl DOA WTF, some of the comments betray a worrying lack of awareness of current standards and, equally important, roadmaps for future development.

    We operate in an industry that changes rapidly. Keeping abreast of developments as they emerge is essential to maintain an understanding of contemporary practice moving forward.

    It’s great to see heated debate, but we all owe it to our profession to read just a little more and equip ourselves with the facts about our industry before pitching in with comments that are, in many cases, inaccurate or – to put it kindly – somewhat disingenuous.

    Thanks for getting the debate started Mr Zeldman, it’s been a rollercoaster following along.

  142. Pingback: Planet HTML5
  143. Pingback: mezzoblue § Home
  144. How is writing in an HTML 4.01 strict dtd going to lead to tag soup? Maybe I need to skim the article again.

    IMHO, it seems like XHTML users that I have met are more militant and elitist than HTML users.

    Also, why would someone who has so much influence in the web world be so opinionated about something like DTD usage? Keep an open mind my brother. ;)

    Interesting article though.

  145. Nate Klaiber said on 7 July 2009 at 8:45 am:
    I am still waiting for an example of someone truly using XHTML for a purpose other than text/html, and I haven’t been able to find it. I am genuinely interested to see examples of people using it.
    —–
    Take a look at mobile-friendly sites such as Acronyms.net on a handheld device (iPhone, iPod touch, cell phone, PDA, etc.) vs. non-XTML sites on the same device. Do “view source” on the XHTML versions of those pages and note that the content doesn’t include the common elements (navigation, etc.) which makes the pages more SEO-friendly (enter “acronym index” in bing.com and see what site comes up first). The common elements are in site-wide templates that browsers can cache, speeding up page load times 2-3 times (compare the size of those files to the .html ones where the common elements have to be included with _every_ page). While you’re there, select “View” -> “Page Style” -> “Printer-Friendly” from the menu bar and/or compare results at http://mobiready.com/launch.jsp?locale=en_EN

  146. Pingback: Burningbird
  147. The problem with XHTML is that it didn’t directly add any value to the user experience. Arguably the code performs better, but the improvement isunrecognizable to the layman simply trying to buy a sweater quickly and get it delivered.

    Most XHTML experts were using their expertise to get more business re-coding existing websites. Good for them, not necessarily good for their clients.

    My advice is to focus on something that makes life better for the person using the computer.

  148. Wouldn’t it be nice if the W3C could stop playing with marketing-messages and start producing a single, useable doctype so the people that code those browser clients finally know what their browser should do?

    XHTML or HTML… ham or eggs? What about both? That would sure rock the web once and for all… not!

    As it seems it’s either hoping “ye olde standards” will survive over the next 15 years, or it’s “quirks mode, baby – all the way down on history lane”.

    Oh well, as long as I can read the content, why care what it’s wrapped in? As long as I can style it, the designer in me is happy; and as long as I can code it with 20 tags or less, the coder in me is happy. You can call it XHTML6-plus one day if you like; I will call it the logical way to a minimal, working website.

    I once read an article by T.B.Lee about “good url’s don’t change”. I would like to extend the idea by saying “good doctypes don’t change because good hypertext doesn’t change either”!

  149. The problem with XHTML is that it didn’t directly add any value to the user experience.

    Neither did HTML. It’s the code that tells browsers what to do and “user experience” comes from the content, not the code making up the presentation. Or can you give me one example of a single tag that leverages the user experience of html over xhtml? It’s like telling the same story in another business suite. Both can look and do the same… xhtml just tended to throw of some “balast”. (I’ve seen too much submarine movies lately.)

  150. Well, that was a waste of a couple of hours. It started out interesting, finding out opinions on HTML5 and the like, then a few million posts later (about 3/4 of the way down) it turned into a strange public argument.

    Perhaps there should be a warning prior to starting to read all the posts that you are about to waste your time (worse than the time I lost 3 hours when I went to the movies to see Moulin Rouge).

    It’s ridiculous to have public grievances like this, and make such comments – as people who buy your books (if you write books of course) read these comments and could be swayed into finding alternative authors.

    This comment:
    Well, I just * had* to share this email I received from someone evidently confused by this whole ‘XHTML is dead’ thing. Made me laugh, anyway …

    “I’ve been interested in your book for a while, and checked out SitePoint’s free sample chapters. I noticed before much else that you use XHTML. I’m wondering if you’ll be coming out with a third edition using HTML 5 now that XHTML 2 has been dropped in favour of HTML 5.”

    /me slaps head

    by Ian Lloyd (who I have not heard of before now) illustrates this point. Finding well described articles about web stuff is tricky especially as only a small talented few seem to know how to impart their knowledge so that others can understand sometimes difficult concepts, or concepts that should be simpler than they have been made out to be. Scoffing at someone who does not understand a concept is not a good way to behave. Enough said.

    While I’m here, I have taught myself XHTML/CSS/PHP/Accessibilty/Info Arch etc etc (well it has taken longer than just my visit today to learn these things mentioned) and have taught myself well, using properly coded XHTML and validating and producing accessible code right from day one, although I still can’t remember quite how the DOCTYPE goes, and I have not really come across this term tag soup – it must be something that’s outdated. I would class what I imagine tag soup to be as just a big mess. They are called elements are they not? and the rest of the junk in there is not a tag either. Perhaps the old fashioned ‘tag soup’ name should be renamed something fitting such as ‘incomprehensible rubbish’ – a name which fits perfectly to a well outdated form of coding practice (if it was ever a practice).

    Oh, HTML 5 – I did actually find a very good description/analogy of the HTML 5/HTML/XHTML thing: http://www.smashingmagazine.com/2009/07/29/misunderstanding-markup-xhtml-2-comic-strip/
    I don’t think that everyone should be annoyed that things change – they have to to improve things – but they should be annoyed at certain browsers who do not give two monkeys about what web standards and good web designers are doing to improve the web.

  151. Pingback: Anonymous

Comments are closed.