Breadcrumbs

We'll Miss You XHTML 2

XHTML 2002 - 2009

The W3C officially announced last week (2 July 2009) that they will not be renewing the charter for the XHTML 2 Working Group (external link) at the end of 2009. Their objective is to increase the resources of HTML 5, in order to accelerate the completion of the specification. I was not entirely surprised by the W3C's decision because HTML 5 has been receiving a lot of marketing buzz thanks to the big wigs at Apple and Google. All the browser makers are rushing to implement parts of the HTML 5 Working Draft, but there has not been a single attempt of an implementation of XHTML 2, at least as far as I am aware. It makes sense for the W3C to devote more resources to the specifications that companies are actually adopting.

I have always been a fan of XHTML 2, mainly because HTML 5 feels bloated and tag-happy and, overall, the wrong direction for the web. I see XHTML 2 as a fresh start towards a truly semantic web, whilst I see HTML 5 as an attempt to build semantic meaning on top of the current, presentation-oriented HTML. Will it work? Perhaps, but I guess the question is no longer up for debate. Web developers are now stuck with HTML 5, whether we like it or not.

I waited a week to write this blog entry because I wanted to see how the blogosphere responded to the death of XHTML 2. Really, all of the blog posts I read seemed to praise "the birth of HTML 5" (external link). No one seemed to question HTML 5 and whether it is actually the right direction for the web. Jeffrey Zeldman wrote an interesting blog post that at least defends XHTML 1.x (external link), something that these all-of-a-sudden HTML lovers (bandwagon anyone?) are patronising. Also, the idea of the HTML lovers that XHTML 2 died because it was "too strict" is simply absurd. XHTML 2 died because it was too revolutionary, not because it was too strict. If I read/hear one more person claim that XHTML is too strict, I am going to throw a fit!

At the end of the day, XHTML 2 is dead and gone. I could sit here and endlessly write about why I do not like HTML 5, but this blog post is meant to commemorate XHTML 2. We'll miss you XHTML 2!

Comments

  • I'm perfectly happy with XHTML2 being dropped because anything that was good about it has been transfered into the HTML5 spec anyway. The thing I liked about XHTML was the slightly stricter syntax which just made me code a little bit nicer, this is allowed. The generic header tag <h> is also in there and a few other bits and bobs.

    I think the main reason why XHTML2 didn't get adopted was that it wasn't trying to solve problems that we face at the minute. It was just sort of missing the point with what people wanted and how people are using (X)HTML at the minute.

    Untill HTML5 comes out I'll still be using XHTML1.1, and even after it does I'll still be using the XHTML syntax because it's what I've got used to.

    To me it's no big thing as XHTML2 wasn't anything special anyway. It also makes it easier that everyone has only one set of standards to work towards.

    Posted by Matt Oakes (external link) on Sun 12 Jul 2009 at 15:24

  • My issue with HTML 5 is that it adds too many tags that XHTML 2 solved with the role attribute. HTML 5 also allows the poorly written syntax. Sure you can write good code, but why not force people to write stricter code? A stricter web is always better, in my opinion.

    Posted by Ethan Poole (external link) on Sun 12 Jul 2009 at 19:49

  • The problem is that people don't want to be forced. If they are foced to do soemthing they don't want to they are likely to just not bother with it at all and hence stich with HTML4. Which is bad for the web.

    There is no point writing a spec if no one wants to follow it. In the end that's the reason why XHTML2 didn't gain adoption, it turned out it wasn't what most people wanted.

    Posted by Matt Oakes (external link) on Mon 13 Jul 2009 at 12:16

  • I disagree about the strictness. Forcing strictness is always better for code. One of PHP's greatest weaknesses is that you can easily write crappy PHP code, just as easily as you can write good code. Languages like Python and Ruby address these problems and enforce a very specific syntax.

    I don't see why HTML 5 has to be non-XML? What is the benefit of leaving off end tags and not being well-formed?

    XHTML 2 didn't gain adoption because it was too big of a change and it didn't offer any backwards compatibility. However, it died because Apple and Google (others too I'm sure) have turned HTML 5 into a marketing buzz word. A lot of the cool HTML 5 things Apple and Google have hyped, like <audio> and <video> and <canvas>, were also available in the XHTML 2 spec.

    Posted by Ethan Poole (external link) on Mon 13 Jul 2009 at 12:45

  • I'm perfectly happy with XHTML2 being dropped because anything that was good about it has been transfered into the HTML5 spec anyway.

    I admit that I don't know much about XHTML 2, but I do know that you can't do namespaces and all those nice XHTML things that result in XHTML+MathML & XHTML+SVG, XHTML+MathML+SVG etc etc. In HTML it has to be explicitly added to the HTML specification and due to HTML5 not being XML, doesn't quite work with proper SVG either.

    HTML 5 also allows the poorly written syntax. Sure you can write good code, but why not force people to write stricter code?

    Since HTML5 defines error handling, I think that should result far less in the well-known IE guessing at what someone meant to do problem?

    I disagree about the strictness. Forcing strictness is always better for code. One of PHP's greatest weaknesses is that you can easily write crappy PHP code, just as easily as you can write good code. Languages like Python and Ruby address these problems and enforce a very specific syntax.

    With PHP I could start out with relatively crappy code and as I learned, I started to write better code. I'm sure that applies to many people. Perhaps poorly written PHP and Javascript code makes some better programmers who are more familiar with languages like Java sniff at it, but in the end most of the really bad things you can do in PHP have to be explicitly enabled anyway and will probably be disabled in most modern PHP installations. In the end, you can still very easily write crappy program logic in any programming language.

    Posted by Frans (external link) on Sat 25 Jul 2009 at 3:19