XHTML DOA WTF

Firefox developers who were initially alerted to a problem on this page, please view the Firefox test page and the page that explains its use. — JZ

The web’s future isn’t what the web’s past cracked it up to be. 1999: XML is the light and XHTML is the way. 2009: XHTML is dead—kind of.

From the W3C news archive for 2 July 2009:

XHTML 2 Working Group Expected to Stop Work End of 2009, W3C to Increase Resources on HTML 5

2009-07-02: Today the Director announces that when the XHTML 2 Working Group charter expires as scheduled at the end of 2009, the charter will not be renewed. By doing so, and by increasing resources in the Working Group, W3C hopes to accelerate the progress of HTML 5 and clarify W3C’s position regarding the future of HTML. A FAQ answers questions about the future of deliverables of the XHTML 2 Working Group, and the status of various discussions related to HTML. Learn more about the HTML Activity. (Permalink)

Please note that this thread has been updated with useful comments and links that help make sense of the emergence of HTML 5, the death of XHTML 2.0, and what designers and developers need to know about the present and future of web markup.

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
  • In Defense of Web Developers: Pushing back against the “XHTML is bullshit, man!” crowd’s 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. — 7 July 2009

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

248 thoughts on “XHTML DOA WTF”

  1. This isn’t all bad news. Most browser companies are getting behind HTML 5 (which is a good thing) and XHTML 2 has been dead in the water for some time. Aren’t web standards more powerful when everyone is behind a single standard?

  2. I don’t understand why this is happening. Didn’t XHTML fix all the inconsistencies in HTML? HTML5 seems to bring back a lot of those inconsistencies from what I’ve seen so far. WTF indeed.

  3. The sad fact is that XHTML2 hasn’t been getting any traction – so if this means that the folks responsible for all the good ideas in XHTML2 start contributing to the the de facto future spec (HTML5) then good on them.

    I think a lot of us find the idea of revolution attractive, but in actual practice reformation is far more pragmatic, realistic.

  4. Alright, I agree — this was kind of expected. I don’t think XHTML 2 had much future, now that HTML 5 emerged and the focus shifted to it.

    What is strange to me (and I am not yet sure I’ve found the answer to this question) is that HTML 5 is fine, but where is XHTML (5?). I have nothing against HTML (without the ‘X’ in front), but in HTML there are some omissions — I can, for example, write badly formatted code, and it will be perfectly valid in HTML 4.01 and HTML 5. This is not nice… I like my code to be well written, my tags properly opened and closed (and correctly nested), etc. But HTML is too loose and will allow me to make mistakes — which I don’t (obviously) want.

    So… I wonder: Where is the ‘stricter brother’ of HTML 5?… Or we are going back now?

  5. So what happens now? Leave tags open? Validate code to what standard? Sigh, Googling HTML 5 resources..

  6. reading the FAQ, it sounds like the HTML5 working group will now be responsible for the same deliverables that the XHTML2 working group was going to produce.

    sounds more like the groups are being merged (i would imagine lots of overlap here)

  7. This is depressing news. However, I guess it will just be up to the designer/developer to use HTML5 semantically, continuing “sensible code” and not letting it fall to the sloppy standards of pre-XHTML. :/

  8. It looks like the W3C intends XHTML to be alive and well as part of the HTML5 specification. (See the FAQ linked in Zeldman’s post for more about this.) If the good stuff from XHMTL2 can make it into (X)HTML5, it’s all for the better.

  9. XHTML is not dead… They only stopped working on what was going to be the alternative to HTML5. You can still use HTML5 with XHTML syntax served as application/xhtml+xml…

    See here

  10. It makes sense to stop work on XHTML2. It stopped being relevant many years ago.

    Disclosure: I was a representative in the HTML working group that worked on XHTML2, and disagreed strongly with the priorities of the rest of the members of the working group. From a blog post over six years ago:

    The biggest problem that I have with XHTML 2 is not just its misnaming/misplacement as a “future version of HTML”, but also the amount of the HTML Working Group’s time that it consumes at the expense of what I think are imminently more important things for the HTML Working Group to work on.

    Jeffrey, we were all shouting about this six years ago:

    Mr. Zeldman: http://www.zeldman.com/daily/0103b.shtml#skyfall

    Mark Pilgrim: http://diveintomark.org/archives/2003/01/13/semantic_obsolescence

    Eric Meyer: http://meyerweb.com/eric/thoughts/2003a.html#t20030114

    But the W3C staff/chairs didn’t listen.

    It took the Great Web Standards Schism of 2004 and the subsequent formation and momentum of the WHATWG to actually iterate on HTML4.01 (as my past blog post had suggested should have been the top priority of the W3C HTML Working Group *six years ago*).

  11. I think this could be a good thing if some of the Resources can be redirected to working with Microsoft to support application/xhtml+xml in IE. That way we can truly have full support for XHTML cross browser. Lets make this the goal now instead!

  12. I, for one, welcome our new HTML5 overlords!

    XHTML 2 was sort of a mutant offspring, anyways.

    I plan to use XHTML 5 served as text/html, just to tork off the purists, just like I do now with XHTML 1.0.

  13. Man, I am super glad I spent time switching from HTML4 to XHTML1. Maybe XHTML1 was like Vista, you should have just skipped it and waited for a better version to come out. :)

  14. I like the strictness of X(html), guess I’ll just have to move HTML5, eventually, and kid myself that it too has a nice strict policy and adhere to it.

  15. This is going to be a real issue for those of us who are vested in systems that use XHTML, such as WordPress.

    This site is powered by WordPress. What are your plans Jeffery?

  16. Someone needs to be shot for stopping xhtml 2’s release. HTML is bad enough as it is. I was looking forward to actually looking forward to CSS and the new ways to section and do navigation and such. I just scratched the surface with my xhtml reading and im in love with it. HTML 5… not so much. Haven’t we been working to move away from pages filled with crap defining colors and towards pages containing useful info and tags to define who is what? This is moving backwards. Its a bad move.

  17. Do not panic, XHTML fans. XHTML lives on as the XML serialization of HTML5, called XHTML 5. What is dead is the less backwards compatible language XHTML 2 that was going nowhere fast anyway.

    See, it’s better – it jumps 4 version numbers in one fell swoop!

  18. I guess this day has been coming for along time now…

    The ideal of XHTML was always a bit much to ask, anyway; the language was always going to be shunned by the vast majority of mainstream websites. The only people who would ever have used XHTML correctly are standardistas.

  19. All that I ask is to make unclosed tags invalid. Something about the trailing slash in an image tag just makes everything feel right. Grant me that and the future of xHTML makes no difference to me.. (Oh yeah, I also don’t want to see any capital letters anywhere. Thanks.)

  20. Like a few people have already mentioned XHTML5 remains. In all honesty this was a good move for the W3C, espcecially for people who are fans of XHTML because it was causing them to choose between XHTML5 and XHTML2.

    Me personally, I could care less since I’ve given up on XHTML years ago, and strictly use HTML 4.01.

    I’ll never understand why people would serve their XHTML pages as text as almost everyone does. And even if you do serve your XHTML as XML it’s nearly impossible to reach 100% validation at all times (see also: CMS)

  21. @Grant Elliott: you do realize that XHTML1.0 semantically is the same as HTML4.01?
    And HTML5 gives you what you ask: it has more elements for document’s structure.
    I am pretty sure, that anyone mourning for XHTML does not know much about it.

  22. I don’t understand most of you people complaining about Tag Soup and bad code. You can have perfectly fine code in HTML 4.01 Strict, as well as in HTML 5.

    Just write good code. Stop complaining. And try to understand that HTML offers much more flexibility and much more safer[1] then XHTML.

    [1] And by safe i mean if XHTML would actually be treated as XHTML and not HTML (as in XML parser and not a SGML parser). Then if one of the editors of your site would introduce a wrong formatted content, the whole page would fail.

  23. I’ve been doing this for so long that I honestly can’t tell the difference. There are very few things that I note as different between HTML and XHTML…and it’s the X. The real differences that I use on a daily basis are minimal and more along the lines of “Best Practices” than “Working or Broken”. Like the closing /> or . Unless I’m missing something, why does XHTML matter? What are the major issues/features we’re not getting in this transition? What are we losing/gaining? If XHTML was doing amazing things then why is it dead?

    I say this with a lot of real world experience and honestly not being able to tell the difference. I’ve been doing this for 13+ years and day to day it’s mostly just preference…from what I can tell. I do say I code CSS and HTML mostly because the X is too long :) and as most designers I’m somewhat verbally lazy.

  24. Some earlier comments mentioned looking for HTML5 resources – in which case can I recommend two for your consideration:

    HTML5 Doctor has lots of great, really really practical advice aimed at stuff you can use, not impenetrable specs.

    One of the people involved in HTML5 Doctor is Bruce Lawson at Opera

    I was lucky to hear Bruce at @media last week talking with Molly about HTML5 and what it really means – you couldn’t find a calmer, more helpful voice. His site is using HTML5, so have a peak at view source too.

    My own take on this is that W3C have done the web a bit of a favour here, if leaving XHTML’s future looking more than a little uncertain. We’ve done the days of trying in vain to support two different (browser) standards – we really don’t need it again in markup.

    HTML5 can only be as good as we make it – so get involved if you can.

  25. My concern is the extensibility. We’ve been screwing around with cramming semantic data into html using microformats and now RDFa, when all we really need is an extensible version of html that will let us define the meaning of our content. Now what?

    Between this and Outlook 2010, I feel like reinstalling GoLive 5 and cranking some Fastball.

  26. I was really liking XHTML2 over HTML5, but XHTML2 lost so much momentum. I’m not in favor of the sloppiness of HTML5, but we can still code with XHTML strictness. I always served XHTML1 as text/html so I guess it’s of little consequence. Maybe this will be a good thing, and HTML5 will be finished and adopted much sooner than the two slightly (yet significantly enough) different languages would have been. I’m looking forward to seeing what becomes of it.

  27. I think the biggest potential hit here is to education and advocacy. Having the XHTML standard to reference when advising new and old developers alike gives weight to the argument for well-formed code, helping to promote the adoption of good coding habits without the individual needing to have already grasped for themselves the full reasoning behind their use.

    Vagueness in standards is a primary detractor to their adoption, and is something that HTML 5 has sought to eliminate in many cases, which makes the flexibility on syntax all the more puzzling.

  28. I plan to use XHTML 5 served as text/html, just to tork off the purists, just like I do now with XHTML 1.0.

    You actually can’t, because “HTML5″ vs “XHTML5″ is defined not by the syntax but by the MIME type. So just serving anything as text/html means that it is HTML5. :-)

  29. I always knew the stupid rules of XHTML had no benefit what-so-ever, just a bunch of false positives for XML fanboys to pitch in salesman fashion. It was a big waste of my time learning to conform to that nonsense, all because I wanted to see a green “Congratulations” when I click the validate button. Sigh. I wonder what the next five years has in store.

  30. I could be wrong, but the inconsistencies drive me mad and make me care less about conforming to standards.

    For example, as I understand it, a closing slash in an img tag is required in XHTML, but not allowed in HTML4; whereas a closing tag IS allowed (required?) on a break tag.

    Can anyone point me to good resources regarding the differences/similarities of both?

  31. Crazy. I’m kind of torn, actually. On one hand I really like the possibilities that HTML 5 will offer — and the AEA website is a nice example of starting down the HTML 5 path — but on the other hand I have heard about (and experienced) some issues and inconsistencies working with it.

    Sites like http://html5doctor.com/ will help to increase interest in HTML 5, but I think I’m stuck using XHTML until HTML 5 has more browser support. I still wish that I could actually serve-up XHTML as XML…you know, like it’s supposed to be. :-/

  32. Serving XHTML formatted code as HTML/SGML never made much sense to me.
    Serving XHTML as XML hasn’t been really practical.

    Not really surprised by this decision.

  33. This is not too surprising a development as HTML5 development includes XHTML5 – so why have two working groups duplicating efforts.

  34. Looks like I have something fresh to work on this weekend.

    I wonder if I should apply HTML5 the book companion website I’m creating.

  35. But, @nick, that means he’ll need to rethink his clever (and appropriate but currently and inexplicably invalid in HTML5) practice of marking up commenter names with <cite>!

  36. Hello,

    Just for clarification, with that news, does that mean I should use other doctypes when I start developping a website ?
    I am kind of lost about the technical implications of this…

  37. It seems there’s a lot of misinformation going around about HTML5, I would’ve thought web developers were better informed…

    Time for some PR for HTML5?

  38. Can anyone point a resource outlining the difference between the future HTML and XML? In the latest year I was trained to believe that HTML il EVIL because you can leave tags open. Will one be allowed to do that in HTML %?

  39. Also, for the sake of chronicle, whenever I tried to parse XHTML as XML through ruby I failed miserably, falling back to hpricot, which treats everything as HTML, and works very well, so maybe some looseness isn’t that bad.
    Davide

  40. There’s a long time to debate this, IE6 doesn’t support HTML5. IE8/FF/Safari have partial support. So we’re back to that again. We can’t actually use HTML 5 yet because we want to provide a good experience accross the range of browsers our visitors have. XHTML will remain the best way to do this for many years to come.

  41. Despite having the same shock when I saw the announcement, I was under the impression that this isn’t necessarily a bad thing because HTML 5 will essentially incorporate all of the XML focused elements of XHTML (namespaces, etc).

    I could be missing some big omission, but it has seemed to me for a while that HTML 5 looks much more exciting and likely to succeed than XHTML 2.

  42. XHTML 2.0 + XForms + Xlink + any other XML based standard could be a future of the web. Just read point 6 of the FAQ – there is no clear idea how to implement extensions. And there is always problem with semantics and missing tags (requests for audio/video/menu/date/section/ and finally my own) which can’t be easilly implemented in HTML 5 and could be in XHTML by namespaces. Practically XHTML 5 is dead because IE does not support application/xhtml+xml. One more thing. W3C is became more and more company related/addicted. If You haven’t noticed they just removed ogg codecs (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020620.html) because it’s not in the interest of Apple. So, what standards are we talking about? Standards made by corporations to fill their pocket?

  43. It isn’t very amazing that many people still get confused, but once you get down to basics, things are really simple…

    XHTML isn’t dead. Both ‘XHTML2′ and ‘XHTML5′ could/can be used, in theory, for enforcing validity and distributed extendability. The HTML5 effort doesn’t take away any of those (mostly theoretical) possibilities.

    You can write with your precious extra backslashes and add things like RDFa or even self-cooked extensions all you want if you can deal with namespace wrangling, and if you send it out as application/xhtml+xml with the HTML5 Doctype: <!DOCTYPE html> it will be valid. And if you send it out as text/html, it will also work and not even get marked as invalid, because HTML5 is nice for you, except that you can’t get a ‘valid’ stamp when using extensions not yet part of the HTML5 spec, like RDFa. Which doesn’t mean you can’t use them.

    What is different between XHTML2 and (X)HTML5, for those interested in the X in XHTML, is mainly that the latter doesn’t introduce incompatible new elements to the HTML vocabulary, which would break rendering of your documents in all existing browsers when you send it out as a text/html document.

  44. This was pretty much inevitable for the last half decade. Either XHTML 2.0 would become irrelevant as a REC, or it wouldn’t become a REC at all.

    XHTML 2.0 was destined to be the next generation HTML3.0, an idealistic W3C spec not fulfilling market needs. Apart from the excruciating process which is the W3C track, most of the good ideas in HTML 3 reincarnated in HTML 4 in a much better version (some even in HTML 5). Likewise the good ideas in XHTML 2, and there are a few, are bound to be taken up by HTML 5, or possibly HTML 6.

    Furthermore the syntax-agnostic approach of (X)HTML5 makes a lot more sense. The strength of HTML, among the most successful languages around, never lied in the syntax, but in what it could economically express.

  45. Pingback: Xhtml ist tot
  46. Great. Ditching what could have been a great, clean, extensible markup language for some browser-maker-driven mess with tags for every little thing you might want to put in a page; but not in a standardised way. Are you as excited as I am?

  47. @Rijk: I’m referring to cross-browser support. We’re at a point now where we have good consistent support accross every browser. We’ve fought hard for it. Introducing a new specification means we have to revisit the process of browser-specific markup/code – to find suitable workarounds where the feature support “isn’t quite there yet”.

  48. Mike Whitehurst said on 3 July 2009 at 3:59 am:

    There’s a long time to debate this, IE6 doesn’t support HTML5. IE8/F/Safari have partial support. So we’re back to that again. We can’t actually use HTML 5 yet because we want to provide a good experience accross the range of browsers our visitors have. XHTML will remain the best way to do this for many years to come.

    Amen.

  49. Pingback: Anonymous
  50. XHTML 2.0 was destined to be the next generation HTML3.0, an idealistic W3C spec not fulfilling market needs.

    Agreed. Many of us have said this for years. While speaking to the W3C in Spain, I met the main dude behind XHTML 2, a lovely, gracious, brilliant gentleman, and was unable to convey to him the earthbound, practical needs of folks like you and me. Likewise, he was unable to persuade me that “IMG” needed to be fixed or that a shift to elements no browser supports was a wise move when IE was still having trouble supporting “OBJECT.”

    (I’m sure I’m oversimplifying our conversation over a lovely dinner. I spent half the meal chasing our then two-year-old daughter around the restaurant.)

    Even in the first edition of Designing With Web Standards, I expressed concern with the direction of XHTML and the notion that a more abstract and variable XML was the markup language of everyone’s future. On the other hand, XHTML 1.0 was and is a stable, clean, and logical standard markup language that every browser supports (with the exception of MIME type in IE). At the time of the first and second editions, even with HTML 5 in the wings, XHTML 1.0 still made sense to me as a solid toehold for web development for years to come.

    We’re at a point now where we have good consistent support accross every browser. We’ve fought hard for it. Introducing a new specification means we have to revisit the process of browser-specific markup/code – to find suitable workarounds where the feature support “isn’t quite there yet”.

    Yes and no.

    There are two issues with HTML 5. One, brilliantly expressed by John Allsopp in Issue No. 275 of A List Apart, runs like this:

    We don’t need to add specific terms to the vocabulary of HTML, we need to add a mechanism that allows semantic richness to be added to a document as required. In technical terms, we need to make HTML extensible. HTML 5 proposes no mechanism for extensibility.

    The W3C’s decision to dump XHTML 2 (while inevitable given its purist outlook and lack of uptake in the market) may foist HTML 5 on us before the community and the builders of HTML 5 have come to anything like solid agreement about the strategic and specific tactical direction of the specification vis-a-vis semantics, elements, extensibility, and so on.

    The other problem is that of browser support. And here’s where I net out at “yes and no.” Yes, we’re going to have problems, especially with IE, and didn’t we just spend more than a decade working through all that? But also, no, we shouldn’t fear or attack new specifications on the grounds that browser makers may resist. The web is changing, and specifications must advance. (Not everybody can do everything via JavaScript libraries.)

  51. The web is changing, and specifications must advance. (Not everybody can do everything via JavaScript libraries.)

    I would dare go so far as to say that we will all be dependent on JavaScript libraries for emulated functionality for a lot longer than we all would like to be, if we don’t think pragmatically about situations like this one.

    If the status quo is satisfying enough to you, then by all means, attack such efforts. But to me, the status quo is far from satisfying enough, and I’m not going to be satisfied until every single browser with 1% market share or more is capable of doing what Safari can already do today.

    So for me, it’s very clear and simple: (more) change is needed.

  52. What worries me most is the obvious disconnect between HTML5 and CSS3 specs. To the , I would add the necessary interoperability with styling mechanisms that ensure acceptable accessibility across multiple devices and media, and provide more consistent ways for designers to layout content.

  53. Sorry, that should read “To the ‘strategic and specific tactical direction of the specification vis-a-vis semantics, elements, extensibility’ I would add…

  54. The main problem with the complaint “HTML 5 proposes no mechanism for extensibility.” is that it is only partially true. If you use the XML serialization, you can have the same extensibility as XHTML1 and XHTML2 offered – it is NOT a step backwards as some try to imply. But such extensibilty isn’t all that useful, and requires messy namespaces.

    People who want that kind of extensibility in HTML5 (in the text/html serialization) either want direct support for namespaces, or something much like it and just as messy, like CURIEs. Or you give up and just try to get plain direct recognition for your favorite vocabulary in the HTML spec (SVG, MathML).

  55. As interesting discussion as it is what makes this good news?

    We as web developers moved from html 4 to xhtml1.0 and now we will move back to html5, now i know that is good for the development of the web that finaly there is a goal and a light in the end of the tunnel and that w3c are focus on only one language for the future.

    However how long do you think will take for the browsers to support this language as well as browsers such as IE6 or IE7.
    Yes IE 7, i dont think they will change the rendering engine to accomodate html5 if we take in consideration their attitude with outlook 2010.

    I don’t know but any progress is a progress so happy days.

    My cent thanks

  56. Regardless of our pursuits it will be years, potentially decades before W3c working groups, browser vendors, and software vendors all agree on a single spec.

    In support of XHTML, extensibility is crucial if we are to remain open to what the future brings. Who knows if the semantic names given to HTML5 elements will still be relevant in the future? Perhaps an exciting new development renders them useless. The novelty of article and aside tags is endearing. But these and the other new semantically named elements provide no real value over div class=”article” or div class=”aside”.

    If a page doesn’t validate, should it render? I think not. Programatically, strict adherence to the spec and forcing markup to comply is good for everyone because it removes ambiguity. So long as we need to consider improperly nested, unclosed, or other invalid markup the tools we use and, consequently, the web as a whole will suffer for it.

  57. I think it would be time to actually rethink the whole HTML concept. Think about it: it means HyperText Markup Language. Hyper TEXT, people.

    Isn’t it time to come up with a broader way of describing content on the web and the relationships between these pieces of content? Bottom line, why keep expanding HTML to encompass new things and not start from scratch in a more generic way?

    Just my 2 cents.

  58. @Mike: is XHTML somehow more cross-browser compatible than HTML? Never noticed that. I don’t get the point of your first message at all :)

    If you mean that we better stick to the vocabulary defined in HTML 4 and also used in XHTML1, then yes, that’s the save choice, and it isn’t that bad…

  59. As to the future, it’s looking more and more like HTML5 will be the one spec to rule them all. Thus, if there are things missing from HTML5 that you feel passionate about… you no longer can ignore their omission by thinking you’ll just use XHTML2 instead. You want a feature, work on getting it in html5.

    At the end of the day I hope this helps get HTML5 finalized, because it appears MS isn’t interested in adding HTML5 goodies (or CSS3) until the specs are finalized or near to it. By having only one spec to focus on hopefully thing will move faster.

  60. I’m not going to be satisfied until every single browser with 1% market share or more is capable of doing what Safari can already do today.

    Agreed. But you and I may not be satisfied for decades to come. Let’s hope the next generation of WaSP is up to the task of working in partnership with browser and tool makers and designer / developers. (Or that Microsoft abandons Trident for Webkit.)

  61. @Rijk: Poor choice of words on my part. The obvious point is that we will have to wait a while until our favourite web browser has suffifienct HTML5 support.

    I was really thinking about (but not explaining properly) the accessibility issues that HTML5 will inevitably create. XHTML & CSS are all about seperating content from presentation. I remember 3 petri-dishes and some wind-up dinosaurs :o)

    I haven’t spent any time reading the HTML5 specification yet, but I’m certain there’ll be visually impaired, hard-of-hearing, handheld using, printing (and so on) people who (if they knew what it was) would be quite worried about the effects that HTML5 will have on them.

    I wouldn’t say I’m resistant to change, but at the moment there are a lot of questions that I don’t have answers to. I’m sure ALA will provide most of them in good time, but right now I’m a bit “WTF” and that scares me.

  62. There seems to be a lot of dis-information about HTML5 out there. It’s not a step back from XHTML 1.0, but a natural progression. XHTML 2 is the one being given up on, not XHTML in general. XHTML 5 lives on and will be very useable.

  63. The good news is, according to this comment at html5doctor.com using the xhtml-y syntax for links without a natural end-tag (such as <br> being written as <br />) is valid in html5. With Bruce Lawsons follow-up comment I can only assume that this is correct.

    That makes me happy (and I wouldn’t miss xhtml2 any way, it always seemed like utopia).

    Now, if only they could agree on one codec for <video> html5… To compare that failure (not a failure of Hickson, but of Mozilla, Apple and MS) with the fact that <img> doesn’t specify which format images should be in is a moot point. A correct comparison would be if MS required .gif, FF .jpg and Safari .png *for the same image*. Unless this is fixed I’m afraid <video> is dead and we are stuck with Flash movies for a long time. (Sorry for going off target…)

  64. I somehow think RDFa is going to get a lot more attention now, likely where xhtml folds into html5. Interesting to see what unfolds during the folding.

  65. As far as I’m concerned, about dang time they officially killed XHTML2 and focused on what has been for a while the obvious future direction of the One Spec To Rule Them All, so far as leading-edge web markup goes. And I say this as someone who currently uses XHTML1.0 strict for everything I do, because, ignorant though I usually am, I’ve been paying enough attention to understand where things should be going and indeed where they thankfully are going.

    I don’t mean to be insulting, but the number of comments here that come from people who are obviously completely clueless about what HTML5 really is, or, for that matter, what XHTML1 really is and isn’t, is disappointing to say the least. Seriously, if the Powers That Be hadn’t jumped on the XML bandwagon, what we call XHTML, sans a tiny bit of XML-ness that never went anywhere, would have been labeled HTML4.5. Or even HTML5, if you wanted to go up a whole version number, in which case we’d just be discussing HTML6 today and there’d be no confusion at all.

    It’s not like HTML5 hasn’t been in the works for months already, and XHTML2 hasn’t been effectively dead for… well, years, really.

    Me, I’m looking forward to it hugely. Now, to all of those panicking above: go read up on HTML5 and stop saying things that make you sound ignorant and silly. I’m sure y’all are plenty smart when you’re paying attention.

  66. How can you get anyone behind XHTML when the don’t understand
    what it is for? Add to that the constant stream of misinformation from
    standards gurus who don’t realize what it does in the first place. XHTML is to right angle for most to grasp. Something that is closer to engineers and computer scientists expectations than a web designers tactile needs.

    The move away from XHTML is for the most part a Microsoft issue.
    While IE supports XHTML (oh yes it does I can prove it if asked) that would present a huge revenue loss if asked to support it. A word doc is nothing more than XML with a namespace. If you can write a namespace you can write an application. That scares software vendors and web designers to death. Add to this XSL and you remove the need for SQL for small to intermediate web projects eliminating a great deal of expense and time.

    So try this, create an XML doc that marks up as HTML. Add to that the XHTML namespace in the “HTML” tag. Load this into any browser but IE and you have just synthesized HTML in XML by adding the namespace. Now you have a document that could be parsed by XSL as fragments and parsed by the namespace as HTML. To get it to load into IE you need access to apache.conf . But it can be done.

    What bothers me the most is the Peter Pan notion of error handling as it is explained in HTML 5. What is so hard about the error handling in XHTML?

    At the end of the day though an improved HTML version that is flexible an easy to use for everybody is a good idea. I guess a little bit of ritual and liturgy isn’t a bad thing.

  67. I\’m bummed that xHTML 2.0 was dropped. However, according to the FAQ put out by the W3C, members of that working group will be incorporated into the HTML work group, so we might yet see RDFa and many of the cooler features of xHTML 2.0 make their way into x/HTML 5 (or future iterations of it). In the end, I\’m just glad that I can keep coding xHTML.

    However, another interesting development has come about. <audio> and <video> have been dropped from x/HTML 5. According to the article, the browser vendors couldn\’t decide on a codec to support for video and Microsoft flat out refused to support <video>.

    Honestly, I thought those tags were completely unnecessary. Since we have to declare a MIME type for media in the <object> tag anyway, why can\’t the browser simply decode the video/audio native when it detects a \”video/ogg\” or \”audio/ogg\” declaration? Why can\’t it also then give me the option whether I want it to natively decode those codecs or not?

  68. Rijk,

    People who want that kind of extensibility in HTML5 (in the text/html serialization) either want direct support for namespaces, or something much like it and just as messy, like CURIEs. Or you give up and just try to get plain direct recognition for your favorite vocabulary in the HTML spec (SVG, MathML).

    If you read the article Jeffrey linked to, and I wrote, you’ll see that I’m advocating no such thing. XHTML 1.1 already has the role attribute, its extended by ARIA to enable all of what the new structural and text elements of HTML5 enable, and considerably more. It “works” in current browsers back to IE6 (and there’s a CSS based, not JS based workaround for IE6 and older – all documented in the article).

    This alone won’t give us all the extensibility that developers are already striving for (through the use of class and a lesser extent id attributes), but it will give us a good deal, and provide a model for adding further extensibility.
    I’ve never seen a decent argument against this path, just strawmen like “you need namespaces”.

    HTH

    john

  69. Agreed. But you and I may not be satisfied for decades to come.

    I suspect the same, but that’s why I’m all the more eager to try and make things move forward faster. Modernizr is one such effort.

    Plus, I’m willing to fight this battle for decades to come. In the end, the Web and all of its users will win.

  70. At least there’s (X)HTML5.

    Personally, I was much more excited about XHTML2 than I ever was about HTML5. H tags instead of H1-6? More intelligent structure? All the good things and very few of the bad ones.

    Now XHTML is gone. I’ll probably stick with XHTML 1.0 Strict until IE8 becomes the de facto IE browser. Then I’ll look into (X)HTML5.

  71. >sigh<

    Back in 1997, tables and WYSIWYG editors were everywhere. SGML was on it's last legs if not dead – despite my learning it just a year before. I was told that HTML was dying and I should learn to do something new. They said maybe I should do back-end programming or become a designer instead.

    Then "DHTML" came out. People jumped on that bandwagon and everyone threw around that buzzword for a while – ignoring the fact that it was the combination of CSS and JavaScript that made the "D" part of HTML. But, the HTML was still HTML. The browser wars ensued and made everyone's life miserable.

    Then along came HTML4 with browsers to support it and people cheered! JavaScript was "dead", back-end coding (ASP, Java, etc.) took over, and Netscape was killed. The reign of IE had begun. Dot Com Bubble bursts. People are sad. Front-end developers go for months on unemployment.

    Then, along came XML. People thought this was tres cool. We could mark things up however we wanted (hmm… I thought, this XML stuff sounds a lot like SGML with it's strictness, DTDs, etc.) but also have semantics. Validation ruled. Thus XHTML was spawned and it was good. Real separation between presentation layer, the content mark-up, and interactivity was here! Firefox takes on IE, Opera becomes free to use, and Web 2.0 buzzword was thrown around for a long time. Standards and accessibility (508) were now here. JavaScript comes back in the form of AJAX! Everyone rejoices! (Front-end developers scramble to re-learn JavaScript for the new age.)

    W3C realizing that it's not really being paid attention to and those rascally rabbits in the HTML Working group were onto something new – HTML5. W3C realized those cats are the meow and brings them into the fold. Thus the new era of HTML5 (with really only 3 browsers now currently supporting it) begins!

    Accessibility-focused people wonder if people with disabilities will be able to even use these "cool" new HTML5 features. Wonder what about the ~20% of users still using IE6. Will there ever be peace in the browser wars?

    In two-three years, will we be talking about how HTML5 is dead and long live the new HTML standard?

    Please folks, be kind to your fellow front-end coders, make your mark-up good, modular/extensible, and understandable.

  72. From Bruce’s post:

    What does this mean to you? Nothing. Your current XHTML 1.x sites still continue working (except in IE, if you serve them as XML rather than HTML).

    Yup. Moreover,

    HTML 5 took some good ideas from XHTML 2 – the idea of deriving the “level” of a heading from its context, although it preserves using h1…h6 for backwards compatibility rather than a generic h element. XHTML 2 allowed “href anywhere” so anything can be a link, and HTML 5 has a similar idea, although it preserves backwards compatibility by allowing the a element to surround block-level elements. The XHTML 2 element nl for navigation list is doubled in the HTML 5 nav element that wraps a ul or ol. The main side-effect of the end of XHTML 2 is that its resources will now be given to HTML 5.

    In other words, those who looked forward to using XHTML2’s more abstract approach to markup will be able to do so (but in a more backward-compatible way).

    HTML 5 was initiated (and thus supported) by browser makers and was intended to move fast-tracked W3C-style standards activity with the fast-moving app-based web. Once the W3C adopted it, its eventual adoption as a working spec was inevitable.

    And, really, the abstract direction of XHTML 2 and its lack of connection to a changing web doomed not only XHTML 2, but XHTML. Those of us who came to admire the clarity of (most of) XHTML’s markup rules were unable to persuade the brains behind XHTML to stay on track with web development rather than reinvent markup in ways some browsers might never support. HTML 5 arose in part because XHTML 2 looked like a derailment of the future of the XHTML we had converted to and evangelized.

    XHTML 2 was never going to pan out, thus there was no urgency to learn about it, and we enjoyed a period of stability as browsers came up to spec.

    XHTML 1.x will be a stable rec forever, and we can keep using it forever if it meets our needs. The urgency at this point is to familiarize ourselves with HTML 5 and voice concerns, if any.

    Limited HTML 5 already works in browsers; it’s used in aneventapart.com and plenty of other sites.

    Now for the next editions of your books, search and replace “XHTML” with “HTML5″ and you’ll be all set. Am I right??

    Heh-heh. Wrong as Prohibition. Thanks for playing.

  73. From 2003:

    If XHTML can be branded so as to create the association with validation, separating structure and presentation, accessibility, and other techniques that have worth in their own right, then maybe they can all get traction together. But that’s not a technical argument, it’s a social one, and anyone who claims that these loosely coupled concepts are really tightly coupled is either misinformed or lying.

    Dive Into Mark

  74. “What does this mean to you? Nothing. Your current XHTML 1.x sites still continue working (except in IE, if you serve them as XML rather than HTML).”

    IE does support serving documents in XML as HTML.

    What they do not support is application/XHTML+XML mime type.

    The Peter Pan idea of error handling in HTML 5 is next to impossible. Why is it so hard to remember to close tags and not nest block elements inside
    inline elements etc. These are simple rules. Observation we freak out at spelling or grammatic errors yet machine corrected markup is ok?

    We can do better than that.

  75. This entire debate falls down to a fundamental disagreement between pragmatists and purists. Both sides are trying to convince the other side to hop on to their side of the fence, for “the good of the web”. Both sides really do mean well. But good intentions aside, the reality is that in this debate, much like in other debates (vi vs emacs anyone?), the two sides are never going too see eye to eye because on each side of the debate, in their own subcommunity, their view is what makes most sense. We need to reframe this debate in ways that are inclusive, that allow both models to exist. To keep supporting logical evolutions of HTML, while at the same time to be working on ground-up reworkings of the web’s core.

    Browser makers have the biggest role to play here. Imagine for example if they could agree on a pluggable parsing and component model, so that you could implement either HTML5 or XHTML2 as a plugin, and let the market decide which one they preferred? Not that you’ll catch me saying that this is what is going to happen, or even that it should (it’s just a kooky idea). It’s just that keeping this debate in an us vs them mindset isn’t doing anyone much good, as evidenced by the last decade.

  76. “One of HTML 5’s goals is to move the Web away from proprietary technologies such as Flash, Silverlight, and JavaFX, says Ian Hickson, co-editor of the HTML 5 specification. (Hickson is a Google employee, while his co-editor David Hyatt works for Apple.)”

    — Source http://www.infoworld.com/print/79291

    … hmmm ….

  77. When is XML-style “strict” rendering a mistake? Whenever you allow anyone to provide their own markup.

    Imagine some ignoramus (i.e., anyone who doesn’t develop websites for a living) who wants to comment on your blog post, decides to add a line break and enters <br> instead of <br />. Congratulations! Your page will no longer render.

    You can solve that by running every form submission through some sort of process to clean up any markup that someone tries to enter, stripping out any markup, demanding they use specific alternate syntaxes, or put up other barriers to entry. But why would you want to go through any of those hassles? (Aside from auto-escaping anything malicious, of course.)

    I love writing “correct” code, but I don’t want to close the conversation to anyone who doesn’t know how (or to anyone, God forbid, who makes a mistake filling out a <textarea>). So give me HTML that doesn’t get in my way.

  78. Didn’t XHTML fix all the inconsistencies in HTML?

    No! No! No! No!…..

    Looks like XHTML will vanish before people (who are using it as the super-cool markup of modern times) understand what is it, and stop writing in XHTML but serving in HTML.

    People! You are not using XHTML anyway, you just think that you do! So why bother ;)

  79. Does anyone have any idea when would be best to implement HTML 5 into practice or does the specification only recommend only using HTML 5 on a case by case basis depending on the project etc? If support effectively is ending late 2009 should I be coding in HTML 5 in 2010?

  80. Wait a second. Actually how do browsers know if document is xhtml 1.0 strict or xhtml 5? According to docs http://www.whatwg.org/specs/web-apps/current-work “XML documents may contain a DOCTYPE if desired, but this is not required to conform to this specification.” + note below. Because both documents share same namespace and doctype could be just thrown away all xhtml 1.x documents are probably xhtml 5 right now.

  81. @John Allsop, that was an interesting article. But there are some open questions at the end. To me it feels like answers to these questions will lead to variants of the ‘get my vocabulary recognized’ solution, but now with attributes instead of with elements. I don’t think that’s bad at all, it looks much nicer to me than namespace-based solutions. But markup useful on the scale of the web will always benefit from some centrally accepted vocabulary. If you don’t try to get your markup recognized, you are effectively creating your own private sub web, that will lack some of the advantages of the open web.

  82. “In other words, those who looked forward to using XHTML2’s more abstract approach to markup will be able to do so (but in a more backward-compatible way).”

    Bloody hell, Zeldman – why do you always say what I want to say twice as clearly and in half as many words? ;-)

  83. Thanks Rijk,

    I think that’s an eminently valid point about who anoints vocabularies and how. We actually have the same issue with HTML5 element names, BTW, but with a far less flexible process.

    And, we do have a well thought-out, widely adopted standardized vocabulary in ARIA’s role attribute that provides all of the semantics of the currently proposed HTML5 structural elements. So first and foremost the issue it – elements or attributes?

    I guess my biggest concern is that we are hurtling headlong into turning the whatwg’s HTML5 proposal into the next major iteration of HTML, with far from adequate debate and input from any but a small group who have the time and inclination to participate in a highly flawed development process, and who are in many respects simply tinkering at the edges of the work of a tiny handful of people between 2004 and 2007 at the whatwg.

    to me, the future of the core technology of the web is far too important for this to be how we arrive at it.

    Just my humble, probably increasingly annoying 2c worth.

  84. XHTML2 was going to be ace!

    Including things like a ‘navigation list’ is what we need … not another name for a ‘div’ which then needs a ‘ul’ or ‘ol’ in it … this is what we should be steering clear of, not moving towards it …

    A bad dav for the web world …

    RIP HXTML2

  85. Henri Sivonen has published An Unnofficial Q&A about the Discontinuation of the XHTML2 WG. It is intended to clear up some of the confusion expressed in comments on this post. It does and it doesn’t.

    Although “unofficial,” it offers the straight dope on many questions raised here and elsewhere, and this is admirable. It does its work with attitude and gusto.

    The problem, and it’s not Henri Sivonen’s alone to solve, is that the information he presents is extremely condensed and, even though it is presented as a FAQ, it assumes a level of background knowledge not all readers will possess.

    Many designers and developers have only a limited awareness of such esoterica as the role element, let alone being able to decrypt nuggets like…

    Most likely an ARIA-only CURIEless incarnation of the role attribute will find its way into HTML 5 as the ARIA specs mature.

    Thanks for clearing that up.

    Inability to easily parse such chunks does not mean the reader is an ignorant developer; it just means he or she is busy, and has limited time to try to decipher the specialist language with which W3C experts speak to each other.

    It is up to all of us in the standards community who have even a faint inkling of these geniuses’ intentions to translate their language and activity into sentences more people understand. In this way, more of us can prepare to work with, and even contribute to the shape of, standards to come.

    By the way, I’m not knocking the shapers of web standards for communicating in shorthand. It would be silly and a waste of time for them to talk to each other in long explanatory passages any lay person could understand. The trouble—and this has always been the case—is that a set of experts using a closed vocabulary is making decisions that could benefit from the practical input of those who don’t share their vocabulary and are thus lopped out of the conversation.

  86. Bloody hell, Zeldman – why do you always say what I want to say twice as clearly and in half as many words? ;-)

    @Brucel: One of my self-imposed jobs in life is to follow people (like you) who are much, much smarter than me, and condense their genius into easily digestible bites.

  87. From Webmonkey: HTML 5 Won’t Be Ready Until 2022. Yes, 2022:

    If you’re a web developer looking forward to the new tools in HTML 5, the next generation of the language that powers the web, we have some bad news for you — you’re going to waiting a while.

    Ian Hickson, the editor of the HTML 5 specification, recently outlined the time table for HTML 5 and, even assuming browser manufacturers embrace HTML 5 when it reaches the final draft stage, that puts HTML 5’s widespread adoption at 2012. Worse, the final proposed recommendation won’t be released until 2022.

    Yes, you read that right. 2022. Yes, that’s thirteen years from now.

    See also TWO THOUSAND TWENTY TWO by Jeff Croft, in which the gentle Croft, on the basis of the timetable, decides that web standards are meaningless.

    He might instead have decided that XHTML 1.0 is a safe standard to keep using, but where would the drama be in that?

    More links:

    * Current Events: The Official End to XHTML

    * Comments on Comments on Zeldman’s XHTML WTF

  88. Pingback: Planet HTML5
  89. Pingback: log » XHTML2
  90. so, will html5 also have a tag?
    This whole ordeal pretty much confirms that we are all living in a fantisy world were there will be a single standared that we all follow.

    c,mon. w3c drops xhtml… wtf… thats like a government collapsing. All trust is lost!

  91. I still think that going from XHTML to HTML is a step back, although I understand most people here will disagree with me.

    I also doubt that HTML5 will be that much backwards compatible with XHTML1.0 in practice.

    I also feel that XML in the interface is a good idea and that proponents of HTML5 should have done more to ‘push’ it onto the browser vendors as it has happened with most HTML5 tags and so on.

    I also feel that HTML5 spec development is far too slanted towards Google and the big corps, as well as web apps, as web apps are not be all and end all of Web.

    Ah well …

  92. @Berserk The hidden comments seem to be caused by the div#wrapper { overflow: auto; } style. Disabling that style with Firebug appears to correct the issue.

    Happens to me on XP FF 3.5

  93. XML for the web is not dieing, and neither is XHTML. HTML5 will be usable via either the text/html mime-type (HTML4 and previous) and an application/xhtml+xml mime-type. The latter is suppose to trigger browsers to process the document as XML with all its strict syntax requirements and features. They’re even calling this usage XHTML5 in the HTML5 spec.

    XHTML 2.0 is dieing, in favor of a more unified approach in HTML5. HTML5 should be able to make everyone happy (at least in theory).

  94. @Jason:

    Actually, browsers are going to support only (X)HTML 5 from now on and rely on backwards compatibility for XHTML 1.0/HTML 4 (i.e. they have just one engine and it’s going to get HTML 5 stuff added, e.g. video tag works in Firefox 3/Safari 4 even if you tell browser to use HTML4/XHTML1 that isn’t supposed to have it).

  95. far from adequate debate and input from any but a small group who have the time and inclination to participate in a highly flawed development process

    @John Allsopp What changes would you like to see in the spec development process? In comparison to the standard W3 process (member-only email lists etc), I feel the WhatWG’s process is significantly more open, but I’m sure there’s room for improvement.

    Unfortunately I don’t think there’s anything we can do about most people having limited time to participate. I’ve personally found WhatWG to be very responsive to discussing feedback and suggested improvements, so if anyone has feedback don’t hesitate to get on IRC, post to the email list, or add it to the W3 bug tracker. Hopefully once the Last Call Working Draft comes out, more people will feel compelled to participate…

    PS some of these comments are hilarious! Thanks for the lols people ;-)

  96. 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, though it tries to dish it up for the HTML5 set, too. I’ve really appreciated how Zeldman and ALA articles have steered clear of that.

    You’re aggravated that people use XHTML without knowing what it is? Fine. But, first of all, don’t pin users (front-end developers are merely users of specifications) with Microsoft’s failure to support the correct MIME type. That’s crazy. And if you must belabor us for using XHTML1 when it isn’t necessary, please explain to us why XHTML had to be necessary to be used in the first place. In fact, no, don’t do that. Just stop all the snobbery, and let’s introduce people to HTML5 in a way that doesn’t get hackles up, and actually informs.

  97. And, for the record, I’m very sad to see XHTML 2 go. Here’s hoping its better ideas, made even better by articles like Allsopp’s, are worked in.

  98. Thank you, DN.

    For the record, I applaud comment 44126. There is wisdom.

    Snobs “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,” you are sad little people indeed.

  99. The problem, and it’s not Henri Sivonen’s alone to solve, is that the information he presents is extremely condensed

    I am busy, too. :-/ I tried to get it out fast so that it doesn’t get stuck in my partial blogging queue.

    Many designers and developers have only a limited awareness of such esoterica as the role element, let alone being able to decrypt nuggets like…

    The answers are written to be understandable if you’d really ask the question. If you’ve never heard about the XHTML role module, you wouldn’t ask that question. I agree that the presentation of questions and answers that the reader wouldn’t actually know how to ask is not good.

    ARIA is a way for retrofitting screen reader (or Assistive Techonogy more generally) support to DHTML user interfaces. ARIA is not yet normatively referenced from HTML 5, because the ARIA family of specs doesn’t specify implementation requirements in the kind of detail one would expect from HTML 5. As for CURIEs, they are a way of abbreviating URLs used as identifiers rather than addresses and you ain’t gonna need them.

  100. Hmm will keep with XHTML for the time being as it will keep working, need to do some more reading if and any need to move to HTML 4/5.

    Will be interested if WordPress makes a shift but cant see why it needs to in the meantime.

  101. Pingback: In pace requiescat
  102. Good post jeffrey. sorry don’t have enough time to go through all the comments. i have a burning question to ask, please bear with me….

    tell me one thing, is it just me or a crazy number of developers or designers really think that they are in fashion industry ?

    ( i am not necessarily pointing to all the people in this blog but i have been noticing for a few days now in different blogs, that people are just acting as if its not a technology we are talking about but a new gucci perfume ( if people actually talk about gucci perfume or even if it exists ). Or am i missing a huge point ?

    I am no way closer to even being a mediocre in terms of my technical abilities and probably its not wise to open my mouth here but do the guys act same everytime they bring new spec out ( or at least talk about it in similar way).

    Back in the 2000 i had just started doing tables. i got into css in 2002. LEft it for a long time ( moved out to be become RAD tool user, mostly visual basic and visual c ).

    Got away from programming for a year and half.

    Got back into web in 2007 and everything was bloddy same. oh yeah i had to google the xhtml doc type, w3c was telling me to close img in one line, and css was valid. but i guess thats why i was charging my client becuase it needed some effort.

    you could argue i am not that professional, what do i know about pro coding or semantics, or microformats or xhtml specs or css specs or whatever it takes to make a world class thing and yes you are probably right.

    And if you are that smart enough why don’t you just act smart then or at least form your own opinion like Jeffrey has.

  103. good or bad, right or wrong, sensible or WTF, we either have to set the trend ourselves or keep abreast of where it goes to survive in this industry. but good grief, 2022? couldn’t they move the timetable up a bit? and what should we be coding in the meantime? HTML 4? XHTML 1? 2? what?

  104. Pingback: MarcArea Weblog
  105. Pingback: Хабрахабр
  106. Pingback: Burningbird
  107. Great post! It really gives a detailed overview of the “XHTML is dead” confusion that has been discussed over the past few days.

    I have to agree that learning and using XHTML is far from being redundant, especially for people who are beginning in web design and development. I feel that strict rules provide a much simpler framework for learning than “loose rules with multiple shortcuts”.

  108. LOL… somewhat this whole discussion shows me that the html/xhtml hype I fell for myself was a waste of time and resources.

    html5 is more compatible than other doctypes, it’s cooler and more fancy? Geez, that’s no wonder if the doctype pushes almost any known browsers back to the so-much-avoided quircks mode.

    Call me a nerd, but didn’t we nag at the doors of Microsoft and Netscape for years so they would make their browsers “standards compliant” instead of rendering their quirks mode? And now, after years and years of development, discussion and a bunch of working groups we get more tags and a thingy we once told that would kill our pages over time?

    Bah, I used xhtml1.1 and hoped xhtml2.0 would strip more tags, adher more to the “stick to the minimal basics while opening up in an xml way” and last but not least draw a big, fat line between those who just “whip up a quick, invalid website” and those who “know their code”.

    My 2 cents are: this whole html2.0 to html5 evolution is a round trip, taking us back to 1996. But telling us it’s the invention of the wheel. Right… and in 2 or 3 years the W3C will say that blinking text is the newest thing and therefore a good idea or what?

    Have all those people that plugged out of their BBS and into the WWW forgotten about the past, or have they just retired?

    On the other hand… somehow I like the fact that it is “more compatible”. It saves me from needing to adher to useless stuff and it sure saves me from whipping up my own doctype one day.

    If it were up to me, a document would have a HTML tag, a HEAD with contained TITLE, the well known BODYtag and just 9 main tags to be used: H1, H2, H3, P, UL, OL, A, DIV and SPAN. Ok, those forms and tables would throw in a few more, but I don’t need a fancy doctype offering over 100 tags to push text to the screen in a useable and nice-looking way.

    And think about this one: neiter the pages of Google, nor Bing do validate in any mode whatsoever. If that is what search-engines produce… why stick to standards anyway? Those companies (Google Inc. and Microsoft Inc.) are big enough to buy the planet… if they don’t produce valid code, why should we?

    And what about the “plugins are now replaced by embedded rendering alternatives” thingy? Cool, all that means is that the W3C is killing business for companies that digged their cash in the plugin market. Good thing that Macromedia didn’t live long enough to see that happen… now it’s a problem for Adobe, but they cash-in more on their flagships like Photoshop.

    Furthermore: stuff like “video” and “canvas”? Makes me think of Netscape’s blinking text idea again! Remember that HTML = Hypertext, not Hypervideo or Hyperanimation. It’s not even Hypercool… it’s text, just a bit smarter. But hey, who am I to judge?

    In the end we all have to ask ourselves a totally different question: what do we need the W3C working groups for anyway if web evolution means “going forward into the past” to them? They could as well have simply added a few tags to html 2.0 and bingo…

    Argh! Just realised this is just a simple comment box and not a place to post a book. I Hope I didn’t kill your nerves for spitting out what my braincells produced and I sure hope I don’t get hunted down and shot for this comment, but when I start agreeing with Zeldman, the world is getting out of order! ;)

Comments are closed.