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 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.
No colour or religion ever stopped the bullet from a gun
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.
But, XHTML has corrected many wrong thing that HTML developpers used to do.
No it hasn't! Writing valid code (be it HTML 4.01, XHTML, or HTML 5) and checking it with a validator is what has corrected many wrong things that HTML developers used to do. Valid HTML 4.01 is still just as legitimate as XHTML ever was.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
XHTML would have been great standard.
When fed invalid XHTML, the browser chokes, which would have gone a long way to eliminating much of the crap code, and crap "web developers" out there.
I don't see why it's the browsers business to be THAT lenient, and second guess the developer all the time.
The problem is, a lot of web pages today are not a single coherent document, they're a bunch of little code fragments concatenated together (template, content, advertising, etc.). When coders get sloppy, this can result in invalid markup. When browsers choke, the content producer may have no idea how to fix the problem - it may not even be their problem.
What HTML5 tries to do is clearly define exactly how broken markup is supposed to be handled, so all browsers can try to "second guess the developer" in exactly the same way.
Kudos to Firefox for reigniting the browser war. In Browser War 2.0, all the major players are striving toward standards compliance, trying to bring their behavior in line with a single unified goal instead of adding their own proprietary features to HTML itself. Five years from now, when IE6 and IE7 are as distant a memory as IE4 and IE5 are now, web development is going to be a lot easier.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
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!
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
Getting a web page clean is a hard problem ... when you accept user input in something approaching HTML format, like /. does.
No it isn't. You should not ever, ever, be inserting user-provided HTML directly in to a document. If you do, then well done, you've just created a cross-site scripting vulnerability. And you've let pranksters submit <!-- and hide half of your page.
The correct way of handling user-provided HTML is to parse it with an HTML parser, construct a DOM tree, navigate this stripping out any tags that aren't on your whitelisted set, and then use the result. Most of the time, you want to run it through a very relaxed HTML parser because hand-typed HTML in a web form is likely to be full of errors. When you dump the DOM tree as HTML, it can be XHTML 1, HTML 3.2, or any other dialect you want.
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
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
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.