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."
That has to be the dorkiest article write-up I've ever seen on Slashdot. It sounds like a story from those fake news shows they show on airplanes.
Karma: Good (despite my invention of the Karma: sig)
Now just convince the gazillions of bad webdesigners out there to actually use the standard, any standard, please?
Wax-Museum Fire Results In Hundreds Of New Danny DeVito Statues
I'm all for the advancement of standards and the cleanup of bad practices sanctioned by older HTML, but we all know this changes nothing in our immediate future. Most normal (non-Slashdot-reading) users aren't going to download and install the browser of the week, and most web authors aren't going to go back and rework all their web content for new standards.
After reading the article (a good one, by the way), I have to wonder whether any of this will ever be used in practice.
There's got to be more backwards compatability, or it's just not going to be adopted. I have this horrible vision of every major website replacing their initial homepage with a front door: "For XHTML 2, click here. For everything else, click here." and their entire site duplicated. Yeah, right.
I really like the idea, though. Mark it up based on content not presentation, so that multiple browsers and other tools can all make sense of the page, and use another tool (here, CSS) to make it look pretty. Hmmmmm...... holy shit! they've invented TeX!
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
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.
My question is, are they expecting browsers to simply only understand only XHTML 2, or just that the current browsers out there will not be able to read XHTML 2, but future browsers will have be able to read both XHTML 2 and the previous?
If the browsers are allowed cross-compatibility, then I say I like what I see. But if HTML and et all are thrown out the window completely, then I don't think we will ever see XHTML 2 ever put into practice.
AnamanFan - Trying to find the Truth, one post at a time.
Which of the following looks more like "500 lbs of HTML":
<style type="text/css">
body { font: bold larger "Verdana" }
</style>
<body>
<p>This is my duh page.</p>
<p>It is a nice page.</p>
<p>It has three paragraphs. Wow.</p>
</body>
or:
<body>
<p><font face="Verdana" size="+2"><b>This is my duh page.</b></font></p>
<p><font face="Verdana" size="+2"><b>It is a nice page.</b></font></p>
<p><font face="Verdana" size="+2"><b>It has three paragraphs. Wow.</b></font></p>
</body>
Liberty in your lifetime
Style sheets mean less code, not more. An XHTML/CSS page is cleaner and simpler than older pages - less spacing tricks (non-breaking spaces, invisible images, convoluted tables), more consistant code, less repeated tags.
As a programmer myself, I don't see why you are more confortable with micromanaging <font> tags rather than defining the page properties once in one central place. Hell, if you want, you can just use embedded style rules and put style="font-family: Verdana" right in the tag you would have wrapped in a <font></font> tag.
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...
and
. It's not a replacement for DHTML menus (boo! hiss!) or anything like that; effects like that would still be handled via (ECMA|Java)script or CSS.
:)
/. comments is <a>, <p>, <blockquote>, <em> and <strong> (and like I said earlier, that last is being challenged). This is, quite frankly, really, REALLY sad. Why hasn't /. gotten rid of all their legacy crap yet?)
For another, backwards compability has not been "dropped" in the sense that it's gone completely, total split with the past, et cetera. It's just no longer a priority. You can likely expect <br> and maybe the <hN> elements to dissapear entirely as things evolve (many are in favor of that last; many aren't) in addition to those that have already gone byebye. There's also debate about the sematic value of <strong> and either <abbr> or <acronym> (I can never remember which one folks want to get rid of) and whether or not they should stay.
There's also quite a bit of talk about how to handle titles for other elements. Some folks question why <name> is being used instead of <h> in the new navigation lists, for example.
And they're right about XLink, by the way. There's a new reccomendation being put together to try to address these issues, called HLink. You can find it at http://www.w3.org/TR/hlink/.
And just so I can put out these totally unsolicited opinion: XFrames absolutely rocks. Love it. Nurture it. And I've been waiting way too long for <img> to die; now let's just all hope that Microsoft fixes up all of their horrifyingly large bugs with <object> in time for this...
(Ah, one more note. Slashcode doesn't appear to allow the <code> element in comments. Indeed, the only semantic markup allowed in
--
viqsi - See "vixen"
If we do not change our direction we are likely to end up where we are headed.
...the problem is that many designers don't know enough about programming to muck around with the table tags to get the layout perfect.
I agree that it's a waste of a programmer to have to muck around with stylesheets...but the programmer should have not problem implementing them. And, many times, programmers understand more about which properties are supported in which browsers...lots of designers just throw together their stylesheets in Dreamweaver without giving much thought to what's going to work and what's not.
On an only slightly related note: it is interesting that IBM is pushing this, when IBM is internally still requiring support for Netscape 4.x users. In otherwords, it's pretty unlikely that XHTML 2.0 will ever actually grace the IBM intranet (which is sad, because I wouldn't mind converting over)
what the hell is a 'junk character', anyway?
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".