Slashdot Mirror
The Web's Future: XHTML 2.0
Lee writes "Over the years, HTML has only become bigger, never smaller, because new versions had to maintain backward compatibility. That's about to change. On 5 August 2002, the first working draft of XHTML 2.0 was released and the big news is that backward compatibility has been dropped; the language can finally move on. So, what do you as a developer get in return? How about robust forms and events, a better way to look at frames and even hierarchical menus that don't require massive amounts of JavaScript. This article takes a sneak peek at what's new in XHTML 2.0 and how you might one day put it to use."
Nicholas Chase seems completely oblivious to the fact that no-one would ever really associate a style with the semantic-category 'holiday'-- styles are just a way of varying emphasis, and almost never reflect the underlying semantics in that fashion. (If you mention three different holidays on the same page, is there any reason to expect they'll all need the same style? Of course not-- semantics doesn't really work that way.) [more]
My original proposal was a response to the incompatibility of XML with HTML, but this 2.0 proposal even throws that away. Given that there are several billion HTML docs floating around, how likely is it that anyone is going to use a browser that can't render them? It just ain't gonna happen-- human factors doesn't work that way.
I've even called for a 'W3C Secession' because they seem so out-of-touch with the real world and the real Web.
The XHTML2 working group could create an XHTML 2.0 site, and create a link that embedded a XHTML2Java app for those people with non-compliant sites. Only, instead of making it a standalone browser, make it work inside existing browsers.
... people are too jaded to accept this as a working possibility :)
The Java app could do all of the XHTML2 rendering in clients that today don't support it. The web author can write their site in XHTML2 and provide a javascript that detects older browsers and opens a window with the app to browse the XHTML content. Due to app sizing limitations you would probably need to create a form that chose an appropriate screen size and font size preferend, but a cookie could store that.
In addition, if created by the working group, make it GPL and use it as a reference implementation so that other browsers can reuse what code they want to speed up their development.
Eventually, all of the browsers catch-up. People still using older browsers don't get limited by this, they just suffer slower load times on XHTML2 sites.
Since XHTML2 has been cleaned up so drastically, the App would actually be reasonably small compared to an app that would be able to deal with all of XHTML1/HTML4/DOM/CSS.
Plus, for internal use, people would already have a browser component that could be gracefully loaded over a network in any Java-capable OS that provided a robust and clean document language.
Oh wait, I forgot, it's not 1996 anymore
It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
XHTML wants to take away an authors ability to affect presentation. However, it is clear that authors want comlplete control over presentation. When HTML first started out, it was static. And it was good. Then, CGI appeared and you could now create static pages on the fly connecting to other systems. This too was good. Then HTML replaced the interface for 75-90% of internal corporate applications. This was kind of good. .Net, Macromedia, Netscape-Plugins, etc. all try to make the broswer a better presentation language for dynamic data in the back. People want to write applications and have them automatically work on all platforms. And not just work, but take advantage of what we know are good interfaces. Good interfaces are not hitting submit and waiting 3 seconds for a response, or even clicking a link and having the whole screen go blank while it downloads and figures out how to display the next page. A good interface to an application respons immediately and looks good.
The problem is that HTML is not a very good presentation language, and every since it first arrived, programmers are wanting to make it a better presentation language. Java, ActiveX,
Therefore, I think XHTML is doomed because it tries to take out the thing that everyone and there mother wants from a web application; the ability to create interfaces to applications that are always update and don't require complicated download and installation processes. A web language that increase a programmers ability to control the interface while not adding complicated download processes will replace HTML. Nothing short of that.
This isn't the sig you are looking for... Carry on...
People liked HTML before XHTML because it was forgiving. One could forget a few close tags, one could overlap tag runs and the browser would muddle through.
Actually, I think that this is why most people hated html. The muddleing you speak of was different between implementaions (browsers) and thus you have a pseudo standard.
So you've traded tables for a collection of nested DIV elements? I guess the semantic web means nothing to you.
Ah yes. Using "Table Data" to indicate a navigation bar makes MUCH more sense than a simple nondescript "division".
I mean just look at this post. Should I, and if I should, how do I, mark up "much". Should it be EM, STRONG, B[old], I[talic], or just capitalize it? Do I markup the previously quoted text as BLOCKQUOTE, since that's the only tag that's even close, even though it's not actually blockquote material since it's only one line?
Useful content based markup was pretty much DOA when they created the CODE tag, over say something much more useful like "name".