HTML V5 and XHTML V2
An anonymous reader writes "While the intention of both HTML V5 and XHTML V2 is to improve on the existing versions, the approaches chosen by the developers to make those improvements are very different. With differing philosophies come distinct results. For the first time in many years, the direction of upcoming browser versions is uncertain. This article uncovers the bigger picture behind the details of these two standards."
Both standards are being worked on the by the W3C standards group. Microsoft, along with all other major browser developers, is a member.
My blog
I'm sticking with XHTML1.0 strict. Perhaps I'll use XHTML1.1 with appropriate DTD if I ever need to support the canvas element, other than that... none of this stuff is what I want from a markup language.
HTML 5 is aiming to support various things needed for web applications (in fact, the current draft is formed of two documents: Web Applications 1.0 and Web Forms 2.0). Also, see http://www.w3.org/2006/appformats/admin/charter.html.
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML5) covers HTML 5, Nobody has started to try to implement XHTML 2 AFAIK (though definitely nobody major).
Both standards are being worked on the by the W3C standards group.
According to the IBM paper html 5 is being done independently of the W3C. "In April 2007, the W3C voted on a proposal to adopt HTML V5 for review" is about as much as W3C has with html 5.
FalconShould there be a Law?
The position taken is that XML is too hard and parse errors are scary or something. With XML, you need to make sure that your document contents are correctly encoded, use the DOM instead of document.write() and should be serving it with the correct MIME type (when appropriate). For some reason, it's deemed more important that cowboy web designers are permitted to continue ripping off their clients with inaccessible and invalid markup rather than advancing the web for the benefit of competent developers.
XHTML 1.0 strict is where it's at and there'll be no change with the release of HTML5 or XHTML 2.0 recommendations.
There are a lot of people who think that web, Ajax and Flash applications are a very bad thing. Not just users, but also noted developers and usability experts.
.NET framework makes for bad web applications: this explains why .NET apps using some of the latest technology around is often a bad idea.
More thoughts on why Ajax is bad for web applications: this is about how Ajax apps are often very fragile and usually don't work as expected.
Ephemeral Web-Based Applications: usability guru Jakob Nielsen writes this great article that goes into depth about how most web apps are complete failures when it comes to usability. Even something as basic as navigation quickly becomes unintuitive and difficult.
Why the
You're not on a fucking plane (and if you are, it doesn't matter)!: Ruby on Rails creator David Heinemeier Hansson talks about how we don't need web apps everywhere.
There are a lot of anti-web app articles here. Having done a lot of web apps for years now i think a lot of them are spot on although they are really against web apps when web apps probably are the best tool for the job:
Web apps: taking five years to get to where desktop apps were a decade earlier?
A JavaScript tip built on years of experience: try to avoid JavaScript.
Why is Web page layout still such a problem?
Web 2.0: A serious case of diarRIA.
AJAX: the "ricer" of the software development world?
Keep the Web in the browser, please.
The wasteful nature of pointless JavaScript effects.
An example of the sorry state of JavaScript today.
The Web is inherently an inadequate application development platform.
Where is the developer productivity increase with JavaScript-based Web applications?
A great Web developer is a waste of a really great application developer.
Anyone thinking of clicking on the parent's link (to vumit.com) should realize that it's a goatsex-style shocker page.
Find free books.
That's one of them, yes. It really depends on what you want to do; for example you don't need anything other than typical mousedown event handlers for things like Google Maps, and you can use things like dynamically generated image URIs to send data back to the server asynchronously, which is compatible all the way back to Netscape 2. There are lots of options, the value in XMLHttpRequest is more convenience than functionality.
Bogtha Bogtha Bogtha
Err, yes it does. From the Google Maps API reference:
And that's just a recent refinement. Google Maps has used the XMLHttpRequest object for ages. Yes, it's possible to get a similar effect using hidden iframes and such, but doing it that way is really awkward. They'd have to be crazy to pass that amount of data back and forth that way when they've got XMLHttpRequest.
For a few years now, the W3C publication process has included an additional final step. It is not possible for a specification to reach final Recommendation stage unless it has two complete interoperable implementations.
Bogtha Bogtha Bogtha
Sure, those techniques have been there since Netscape 2... and without XMLHttpRequest, we'd be back to the 1998 status quo.
As it stands, with both XHTML 5 and XHTML 2 using the same namespace, it is only possible to support one of the two.
Not true. They have different namespaces, so a processor can know exactly which language it is dealing with.
From the HTMLv5 working draft (section 1.1.2 "Relationship to XHTML2"):
"XHTML2 and this specification use different namespaces and therefore can both be implemented in the same XML processor."
When using HTMLv5-as-XML, the namespace is "http://www.w3.org/1999/xhtml".
The XHTMLv2 namespace is "http://www.w3.org/2002/06/xhtml2/".
Heck, you could even mix (X)HTMLv5 and XHTMLv2 in the same document, though it might be a bit perverse. I can't think of a good use-case off the top of my head.