XHTML 2 Cancelled 222
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."
Good (Score:5, Informative)
Re:XHTML merged (Score:5, Informative)
They should have XMLized HTML in the first place.
They did. It's called XHTML.
Unless you mean XML-ise HTML 3.2 or earlier, but I believe XML didn't exist back then.
Re:XHTML merged (Score:2, Informative)
Good compilers still choke on syntax error, you idiot. Hell, scripting language will crash immediately if you made a syntax error too.
XHTML isn't worse than programming language compilers and interpreters. It won't detect wrong semantics if you didn't use what you needed but it chokes on syntax error, malformed tag, which is a GOOD thing.
Sounds like a few people are confused... (Score:5, Informative)
XHTML 1 was the XML-ization of the existing HTML 4 stuff.
XHTML 2 was a new HTML version that sought to remove lots of HTML cruft (including non-XML syntax) and add new capabilities. Basically, it was working toward a new HTML version. This effort has died, because browser makers are not behind it - they are all behind HTML 5.
HTML 5 has always had an XML profile called XHTML 5, and that won't go away.
Re:XHTML merged (Score:2, Informative)
We made great use of it once in an internal web-based system. There was a command-line client that basically just did a GET/POST and then parsed the xhtml with an xml parser to display the output, which made implementing that a doddle. Coding the website to be xhtml compliant added very little overhead, much less than defining a whole separate soap service or similar.
Re:I'm disappointed. (Score:3, Informative)
XHTML has some great features, notably the ability to embed MathML and SVG in it (great for academic sites) and strict error handling. Unfortunately these features never caught on because Internet Explorer doesn't understand the XHTML MIME type at all. What a shame.
I'm not familiar with the MathML and SVG features. Hopefully there's another (if less elegant) way to do what you want in HTML5.
As for strict error handling, one of the things HTML5 is doing is defining exactly how errors are supposed to be handled. This doesn't mean "strict" error handling in the sense that any page that contains an error will completely fail to load at all, but it does mean we can expect a consistent behavior across multiple browsers even when the HTML doesn't validate.
The trouble with XHTML is that many web pages today are generated from multiple sources; a single page may not really be a single coherent document, but a conglomeration of little pieces. When coders get sloppy, this results in a document that doesn't validate. If you're using XHTML with strict error handling, this can break the entire page. If you're using HTML with clearly defined but less strict error handling, it may result in some of your content not looking quite right, or the browser may be able to guess how it's supposed to work and it ends up looking just fine. This isn't an ideal world, but we don't live in an ideal world; this is what the Web has evolved into, and we need to accept that.
What really killed XHTML is that it became a buzzword used by people who had absolutely no idea what the hell they were doing. A bunch of idiots jumped on the XHTML bandwagon, added lots of slashes to their broken HTML code, and called it XHTML. Browsers ignored the extra slashes and rendered the broken HTML the same way they always had, and the idiots thought XHTML was the greatest thing since sliced bread. Half the Web looks like that now, and there's nothing the W3C can do to make everybody start writing valid XHTML, so why even bother?
Re:No more compound documents? (Score:4, Informative)
XHTML 1 is basically HTML4 with the added requirement that the document must also be well-formed XML. This is useful, because it allows you to put any other arbitrary (but properly-namespaced) XML data in the same file. XHTML 2 was meant to dramatically reduce the number of valid tags, clean up HTML even more than HTML 4 did, and split the spec into a large collection of smaller standards. No one really liked it; it was developed in the traditional W3C 'let's create a new standard without thinking too hard about how it will be implemented' way.
HTML 5 is an evolution of HTML 4 backed by people who actually implement these standards and developed in a more incremental way. Unlike HTML 4, HTML 5 doesn't specify the representation. It has SGML and XML bindings. HTML 5 with the SGML binding looks like classic HTML, HTML 5 with the XML binding looks like XHTML. HTML 5 with the XML binding has all of the advantages of XHTML; you can mix it with any other XML data in the same file, and have a unified DOM tree.
Re:XHTML merged (Score:3, Informative)
Yes, we can dream.
How lazy do you have to be not to close your tags, and nest them properly? It's a low barrier, but given people's infinite laziness, they will write their code until it is just not-too-crappy to render in IE. Then call it a day.
A strict standard would also give MS less wiggle room to subvert the standard in their IE implementation of it.
Re:XHTML merged (Score:3, Informative)
A key feature of html5 is that is specifies the algorithms to use when normalizing poorly formed markup. It doesn't eliminate ambiguous cases, but it gets rid of many of them, meaning that the presentation and DOM should almost always be the same, regardless of the browser.
Re:No more compound documents? (Score:4, Informative)
"XHTML 1 is basically HTML4 with the added requirement that the document must also be well-formed XML"
It also deprecated a lot of the older tags that were made obsolete by CSS hence encouraging better separation of document structure and presentation. Unfortunately HTML5 undoes this particular good work because it caters to the lowest common denominator (i.e. bad developers who don't "get" separation of concerns and trivially parsable markup).
"HTML 5 is an evolution of HTML 4 backed by people who actually implement these standards and developed in a more incremental way."
The problem is, those people implementing those standards have proven time and time again how incompetent they are at implementing those standards. The state of standards compliance in browsers has for well over a decade been utterly shameful and that really goes for Firefox as much as it does IE. I'd argue it's those who use the standards that know best - people building the biggest sites on the net because they're the ones who need the markup to be able to support large scale application development. Browser vendors need to be able to implement that standard, don't get me wrong, but putting faith in them as the ones who guide the standards has time and time again proven disastrous - look at the HTML5 video tag debacle for perhaps the most recent example.
I'm not disagreeing with you though, XHTML2 wasn't brilliant, but I'm not convinced HTML5 is even any better than XHTML1 which was also an evolution of HTML4 and IMHO a better one. It was designed with those people building enterprise applications for the web in mind rather than joe average, who is more content using the likes of MySpace and Facebook to manage their content for them in the first place.
Of course, HTML5 can do everything XHTML does for the reasons you state, but sadly it seems to encourage bad practice whereas XHTML discouraged it. One final beef I have with HTML5 is that accessibility seems to have been ignored in it's creation, for example there were no real efforts to ensure easy inclusion of subtitles the previously proposed audio/video formats. Again, we really just don't seem to be any further on with web standards than we were at the start of the decade and again, the people to blame are the browser vendors as much as the W3C and it's allowed not particularly ideal or portable proprietary tools such as Flash to gain a lot of ground as a result.
Re:XHTML merged (Score:4, Informative)
Getting a web page clean is a hard problem ... when you accept user input in something approaching HTML format, like /. does
No it is not. Have php run the user input through tidy. Even if it doesn't display as the user wanted in their browser, at least it displays consistently between browsers which is more important imho. Just go. Install it now in php [php.net]. Seriously, if you are not checking html code coming in from users, something is not right. They could destroy your page with some of those unclosed tags.
Re:No more compound documents? (Score:5, Informative)
It also deprecated a lot of the older tags that were made obsolete by CSS hence encouraging better separation of document structure and presentation. Unfortunately HTML5 undoes this particular good work because it caters to the lowest common denominator (i.e. bad developers who don't "get" separation of concerns and trivially parsable markup).
I think you read a different version of HTML 5 to me. It still deprecates or removes all of the tags that HTML 4 and XHTML 1 removed, for example removing the center and font tags which were only deprecated by HTML 4.
Where it introduces new tags, it is for expressiveness. A lot of the 'separation of content and presentation' folks seem to think that HTML just needs three tags; span, div, and object. HTML 5 doesn't add more presentation elements, but it does add more tags with well-defined semantics. Examples of this include section and nav tags. These don't specify anything about the presentation, they just indicate that a part of the document is a section, or a set of navigation commands. A mobile browser, for example, might have an option to hide and show the nav section to conserve screen space.
Take a look at the current draft of HTML 5 [w3.org]. You'd be hard-pressed to find anything presentation-related. Presentation still goes in the stylesheets, HTML 5 just adds tags for common things so you don't need quite so many class attributes.
Re:CSS 3 spec (Score:4, Informative)
There is no "CSS3 spec". There is a whole bunch of separate specs all advancing along the REC track separately. They're at various stages of readiness.
For example, CSS Namespaces is in CR ("spec work done, implement it please"). It'll become a REC once there is a test suite and two interoperable implementations and the various paperwork involved in becoming a REC is done.
Selectors Level 3, CSS Color Level 3, CSS Multi-column layout are all in Last Call, with the next step being either CR or PR (PR is "this is done implemented and all; just needs sign-off from the W3C staff"). Same for Media Queries, CSS Basic User Interface, CSS Marquee Level 3, CSS Print Profile, etc.
Was there a particular part of "CSS3" you were interested in seeing specced and implemented?
Re:No more compound documents? (Score:5, Informative)
No, HTML 5 has an XML serialisation and a tag-soup-compatible serialisation that, yes, looks like classic HTML, but in fact isn't based on SGML. It's based on the way popular browsers parse HTML rather than what they are supposed to do according to previous HTML specifications. One consequence of this is that obscure parts of previous versions of HTML that are not well-supported by popular browsers are not supported by HTML 5 - it's not completely backwards-compatible with previous versions of HTML.
Re:Sounds like a few people are confused... (Score:3, Informative)
The doctype.
Not sure you'll like the answer : ) :
<!doctype html>
I believe because they wanted to keep it short and simple, and hixie doesn't believe in versioning HTML - having a version-less doctype forces people to keep it backwards-compatible when html6 rolls around. Perhaps someone else who followed the process better can chime in here.
Re:HTML 5 parsing is just awful. (Score:4, Informative)
Now try to imagine Microsoft, Opera, Mozilla, and Google implementing that compatibly.
I believe they already do, for the most part. HTML5 parsing rules were mostly reverse-engineered from existing browsers' HTML parsing rules, which are more or less consistent across modern browsers, so it's only documenting what most existing browsers already do.
What the spec is defining is a limited subset of an SGML-like language (whose entire parsing rules, if incorporated into HTML, would span for pages) and how to transform it into a DOM. It isn't mandating any new parser rules, it only documents them for the benefit of new implementations of the spec, and to align what minor variations there are between browser parsing models together. Compared to SGML rules (of which HTML 4.01 is technically a subset), this is a great improvement.
Re:Good (Score:3, Informative)
HTML 5 is based on the DOM. The HTML4-compatible syntax is defined from scratch, it isn't based on SGML because no web browser actually parses SGML correctly. Most of them don't do HTML4.01 fully for that matter (IE doesn't do simple things like <q>, Moz doesn't support all the weird table-column align stuff...).
Re:XHTML merged (Score:4, Informative)
That most web page authors are too incompetent to even follow XML's validity rules, let alone HTML's?
Re:Good (Score:3, Informative)
HTML5 comes in two forms.
It comes in an SGML-inspired format, that is not strictly SGML but matches real word HTML almost exactly. The big difference from HTML4 besides the new tags is that it does not use a DTD, nor does it support the shortag features of SGML, with the exception of the short attribute feature. Thus "<title/</<body/".
(Yes, that has three open brackets, zero close brackets, and 3 slashes) is not valid HTML5, despite being valid HTML4. (At least once you add the DTD).
There is also an XHTML form, which may informally be called XHTML5. Except for the new tags, this is pretty much identical to XHTML 1. In some ways this is the prefered form of HTML5, being that the other form does not support namespaces.
XML mode and separating author/browser concerns (Score:3, Informative)
Now if they implement HTML5 right, and we get the same cleanness that XHTML 1.1 had (Strict only. No transitional shit.), and they add cross-language abilities too (trough SGML), then I'm all for it!
Have some faith, the HTML5 spec and its writers are wayyyyy smarter than /. commenters!
Re:Will they roll XHTML 2 features into X/HTML 5? (Score:1, Informative)
Exactly. All those XHTML 2 features that you mentioned are simply beautiful and made mark-up simpler and more semantic. I've been eagerly awaiting being able to use them for years, and now I fear that HTML is getting more complex without any of the simplification that XHTML 2 offered. I have not seen any discussion as of yet of rolling those features into (X)HTML 5, but I hope more people who care (like you) will fight for it. The only discussion I could find is from a year ago and ended up with the rejection of "href anywhere" [meyerweb.com], my favourite XHTML 2 feature. Perhaps this is the right opportunity to try again.