Slashdot Mirror
XHTML 2 Cancelled
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."
I know a lot of web developers who dont know the difference between XHTML and HTML, and I hear XHTML as a buzzword all the time. The less confusion the better in my opinion. The HMTL5 spec is quite readable,but if you've not taken a stab at working with HTML5 (it runs all browsers) yet this article should be pretty useful: http://www.phpguru.org/static/html5
my band is more brutal techno punk than yours
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.
The W3C oversee current net content standard evolution. As it's name imply, it's a consortium. It regroup browser developpers, server developpers, thier application developpers, and many others. It doesn't try to override browser developpers. It oversee them on a technical standard view point. Browser developpers submit improvement for them to be included in the norm. This way it garantee that browsers don't split too much from each others.
More importantly, when are they going to finish the CSS3 spec?
I love that HTML5 is getting pushed to the forefront and browsers are advancing more than ever, but as a web designer that CSS3 spec needs to get done and pushed on the browser developers because it will be another 2 - 5 years before mass adoption and I'm pretty tired of CSS2.1's limitations.
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.
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.
I am TheRaven on Soylent News
Does this mean that someday /. will actually render properly in a browser? I used IE, FF, Opera, and Safari all regularly. /. does not reneder 100% in any of them :(
How do you know that one of them isn't proper and the rest are merely deviations from proper? Or, more accurately, how do you know what it is supposed to look like if you say they are all wrong?
sig not found
Simple: view source --> use your "The Matrix" vision to render everthing in your brain.
Every serious developer knows how to run code in his brain, that's how I run all my unit tests!
"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.
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. 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.
I am TheRaven on Soylent News
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.
Bogtha Bogtha Bogtha
At least with XML you have a simple, well-defined way to convert the XML text to a tree. With HTML 5, there's only "well-defined error handling". Read the sort-of specification for this.
Here's what's supposed to happen for just one of the hard cases. (There are dozens of other cases, some at least as ugly.) Parsing is in "body" mode (normal content) and an end tag whose tag name is one of: "a", "b", "big", "code", "em", "font", "i", "nobr", "s", "small", "strike", "strong", "tt", "u" has been encountered.
Follow these steps:
If there is no such node, or, if that node is also in the stack of open elements but the element is not in scope, then this is a parse error; ignore the token, and abort these steps.
Otherwise, if there is such a node, but that node is not in the stack of open elements, then this is a parse error; remove the element from the list, and abort these steps.
Otherwise, there is a formatting element and that element is in the stack and is in scope. If the element is not the current node, this is a parse error. In any case, proceed with the algorithm as written in the following steps.
Otherwise, append whatever last node ended up being in the previous step to the common ancestor node, first removing it from its previous parent node if any.
I think this attitude is more a case of wishful thinking and sometimes outright denial rather than than reality. Take a look at some of these, for instance:
Bogtha Bogtha Bogtha