Forgot your password?

typodupeerror
The Internet Technology

XHTML 2 Cancelled 222

Posted by timothy
from the that-html-5-he's-so-hot-right-now dept.
Jake Lazaroff writes "According to the W3 News Archive, the charter for the XHTML2 Working Group — set to expire on December 31st, 2009 — will not be renewed. What does this mean? XHTML2 will never be a W3C recommendation, so get on the HTML 5 bandwagon now. According to the XHTML FAQ, however, the W3C does 'plan for the XML serialization of HTML to remain compatible with XML.' Looks like with HTML 5, we'll get the best of both worlds."
This discussion has been archived. No new comments can be posted.

XHTML 2 Cancelled

Comments Filter:
  • XHTML merged (Score:3, Interesting)

    by werfu (1487909) on Friday July 03 2009, @11:41AM (#28572257)
    They should have never created XHTML. They should have XMLized HTML in the first place. But, XHTML has corrected many wrong thing that HTML developpers used to do. Now, HTML5 should simply pick up the best of both world while still being XML compliant.
  • Re:XHTML merged (Score:3, Interesting)

    by IntlHarvester (11985) * on Friday July 03 2009, @12:08PM (#28572489) Journal

    Agreed. XHTML was rather pointless. It didn't add any particularlly interesting features, made pages more difficult to author, and its claim that it made life easier for browser authors was belied by poor support and slow rendering. Making things more "XMLish" with closed tags and quoted attributes was a good idea, but in reality writing XML-conformant CSS/Javascript XML was a pain in the butt and usually not done.

    I suppose XHTML might have been useful as part of a document management/transformation system, but it didn't seem to offer much to most web developers.

  • by otakuj462 (1071510) on Friday July 03 2009, @12:25PM (#28572647)
    What I liked about XHTML was the conceptual clarity regarding the creation of compound documents. Like XML, XHTML is modular, precise and fully extensible via XML namespaces. This allowed one to augment XHTML without needing to fully revise the XHTML spec: one simply needed to use an alternate XHTML namespace inside of the XHTML document. So, for example, this made it very easy to use XHTML in conjunction with SVG, another XML application. I know that HTML5 defines ways in which it may be used in conjunction with SVG, but I'm not sure if it's extensible in the same way. What happens if we want to mix in another format, like XForms? Will we have to go back and revise the complete HTML5 spec?
  • Re:XHTML merged (Score:2, Interesting)

    by DoktorSeven (628331) on Friday July 03 2009, @12:36PM (#28572773) Homepage Journal

    Exactly. XHTML is not that hard to get right, and it makes a web page "clean" in that there doesn't have to be any guessing going on in the browser to figure out what a page designer wants.

    The best thing in the world would have been browsers adapting a rigid HTML standard to begin with and browsers simply saying "Sorry, this page has invalid HTML" on bad pages.

    I can dream, can't I?

  • Re:Good (Score:5, Interesting)

    by Reaperducer (871695) on Friday July 03 2009, @01:50PM (#28573501)

    Imagine a compiler that would eat any typo. Missing brackets, braces, semicolons, object-function separators, completely meaningless semantic messes. HTML4 browsers eat it all.

    So, what you're saying is that the computer works for people instead of the other way around?

  • Re:CSS 3 spec (Score:3, Interesting)

    by jilles (20976) on Friday July 03 2009, @02:11PM (#28573677) Homepage

    That's the whole problem. All the experts are working for the browser vendors. The W3C never had any business overriding them. Css3 will never happen (standardized & widely implemented). But of course the relevant bits have long been implemented and now those await standardization. It would be nice if w3c bureaucracy could catch up here.

    Basically what's wrong here is that after a agile start in the nineties, w3c turned into yet another standards organ. Essentially, for most of the past ten years they've done nothing relevant. Most of the good stuff on the web today basically bypassed their processes (AJAX, HTML5, javascript, DOM). At some point XHTML was hijacked by the Semantic Web crowd. This was essentially given a well deserved neck shot today. They never produced standards or products worth reporting here. Meanwhile, browser vendors had to organize outside the W3C to get some progress going. Current HTML5 is the result of that. Anything else ongoing in W3C is pretty much not relevant (unless you are part of the Semantic Web crowd). Css3 is a good example of why standardize first and implement later is a bad idea.

  • Re:XHTML merged (Score:3, Interesting)

    by moderatorrater (1095745) on Friday July 03 2009, @03:28PM (#28574311)

    They should have XMLized HTML in the first place.

    They did. It's called XHTML.

    And now it's failed. What does that tell us?

  • by zigurat667 (1380959) on Friday July 03 2009, @03:52PM (#28574471)
    Looks like your whishes were heard
    Some earlier versions of HTML (in particular from HTML2 to HTML4) were based on SGML and used SGML parsing rules. However, few (if any) web browsers ever implemented true SGML parsing for HTML documents; the only user agents to strictly handle HTML as an SGML application have historically been validators. The resulting confusion â" with validators claiming documents to have one representation while widely deployed Web browsers interoperably implemented a different representation â" has wasted decades of productivity. This version of HTML thus returns to a non-SGML basis.
    from the HTML 5 specs [w3.org]
  • by Pfhorrest (545131) on Friday July 03 2009, @05:19PM (#28575207) Homepage Journal

    I see a lot of debate here about XML versus SGML (or SGML-like) serialization and parsing rules, and plenty of people (rightly) pointing out that there is an XML version of HTML 5.

    But what about those features which those of us who already code strictly to spec either way really care about? New elements that were scheduled to debut in XHTML 2.0 such as nl, h and section, the ability to put href and src attributes in any element, etc [xhtml.com]?

    Those are the sorts of things which made the debate for me, not some silly XML vs SGML, strict vs lenient debate - either way I'll be writing my code for strict compliance with spec. I'm more concerned with what the features of the spec will be! Less so with how it deals with people out of compliance with it.

    So any news on whether X/HTML 5 will be incorporating any of these, now that it's a W3C project and XHTML 2 is dead?

  • Re:XHTML merged (Score:3, Interesting)

    by Haeleth (414428) on Friday July 03 2009, @06:08PM (#28575589) Journal

    Lazy? Writing messy HTML takes more effort than writing clean XHTML. If you use a decent editor -- one that can take advantage of the structure and parseability of XML to provide validation, auto-completion, etc. on the fly -- then XHTML practically writes itself.

  • HTML5: Just Say NO (Score:2, Interesting)

    by jonadab (583620) on Friday July 03 2009, @06:45PM (#28575827) Homepage Journal
    > so get on the HTML 5 bandwagon now.

    Not gonna happen, fanboy.

    HTML 5 takes entirely too many steps in the wrong directions. I'm not interested in going there. I'm *definitely* never going back to non-wellformed SGML-oriented markup, and that's just for starters.

    Though, to be honest, I wasn't real excited about XHTML2 either. Not so many steps in *wrong* directions, but plenty of *unnecessary* changes. Meh. I'm not really going to mourn its loss.

    What I really want is XHTML 1.0.1, the only difference from 1.0 being that you can put block-level elements within a paragraph. That's the only change I really wanted.

    So hey, I can live with 1.0. I'll just keep using <div class="p"> like I have been. It's a kludge, but it works.

    Or maybe I'll just study up a bit and end up going to straight XML with a custom namespace. Then I can have my block-level elements inside of paragraphs :-)
  • Re:XHTML merged (Score:3, Interesting)

    by VGPowerlord (621254) on Friday July 03 2009, @06:49PM (#28575851) Homepage

    Under the current draft, browsers choose what set of codecs/container-formats they support.

    Yes, and unfortunately, as far as I can tell, this is how support for the two leading hi-def formats is right now:

    Chrome 2: Supports both Theora and H.264
    Safari 4: Supports H.264
    Firefox 3.5: Supports Theora
    IE 8: Supports neither.

    Congratulations, between the 4 largest browsers we've managed to have all four possibilities you can have with two booleans (2^2)!

  • Re:Good (Score:3, Interesting)

    by Blakey Rat (99501) on Friday July 03 2009, @07:58PM (#28576297)

    The main key is, that, while HTML5 is based on the superior SGML (because of more freedom), XHTML had started to enforce strictness and cleanness. This meant the browser did not have to support a ton of typos, just because the editor was a freakin' lazy ass. Imagine a compiler that would eat any typo. Missing brackets, braces, semicolons, object-function separators, completely meaningless semantic messes. HTML4 browsers eat it all.

    Totally wrong. One of the most important rules in software is: "be liberal in what you accept, and strict in what you output." XHTML does that first part COMPLETELY WRONG.

    Here's the thing: while you're going on about dumbing-down, you're completely ignoring the basic power of the web-- the fact that everybody can (and should) participate in it.

    You long for a world where, if I put my STRONG tag and my EM tag in the wrong order, a completely trivial error, the browser should show absolutely nothing. Even though it's obvious to everybody what I *meant*, since a computer thinks like a computer and rejects it like a retard.

    You know what? I already have enough computer programs that act like retards. I want my software to be smart, so that humans don't have to worry about that trivial shit you seem to relish so much. In the ideal world, software would *do what I mean*, not *do what I say*. Your world sucks.

    It doesn't help, BTW, that "dumbing down" is always one of those grouchy "get off my lawn" arguments people make when they don't really have any actual arguments.

    And how do we move into your world? Well, first of all we completely and utterly delude ourselves into thinking that HTML4 will disappear overnights and XHTML can make browser simpler to implement. Thus deluded, we then create a new standard which offers absolutely *nothing* new over the old standard, then tell all the browser makers to add that into the already-too-long list of standards they need to support. Oh, and just to cement W3C's isolation from the *actual* work of creating and maintaining webpages, let's make this new standard incompatible with some of the most popular web analytics tags out there.

    XHTML was retardation from day 1.

    Now the flamebait part: of course what you're probably really after is some kind of elitist high-priesthood-of-technology bullshit for your own selfish reasons.

Many are called, few volunteer.

Working...