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.
I have to ask why. Given structured markup and stylesheets, what is the reasoning for XHTML2.0? I understand 1.0 as a transition. If XML is what it says it is, what is XHTML?
illegitimii non ingravare
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
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.
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...
I edited my first paragraph without re-reading:
Should be:
...
Also ... it might speed developer adoption if a canned style sheet were developed that created a style to mimic HTML4 markup along with a translating cross-reference.
That way I as a developer could embed the canned style sheet, look at the cross reference and know that if I put something like italicized it would be close to using italicized.
Just ideas ...
It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
Well, really I was talking about the gee-whiz in-the-year-2000-we'll-have-laser-pants tone. You make a good point, though. While the move to edutainment is not going fast enough for some people, science-based TV shows and movies, such as CSI and XXX, are becoming more and more popular. I think it's a positive trend, and it won't be long before contestants on Survivor are in the lab racing against the clock to develop an antidote before the poison reaches their brains.
Karma: Good (despite my invention of the Karma: sig)
Ehm, as a programmer you must have some aesthetic sense of design, right? Things like, say, avoiding redundancy and abstracting things away?
Instead of applying a <font> tag to absolutely every element you want to set it, you just do body { font-family: foo, bar, sans-serif; } and be done with it.
Instead of doing this on *every* page you just <link> to it, and have a single place to change the font you want to use.
Instead of 5k of tables per page, you use a few <div>'s and position/float them in your one CSS file.
Your HTML becomes much more lightweight, and you can style it progressively without going back and editing your HTML every time. Do it once, and stick to the same classes and overall structure, and you don't have to do it again next time. You can modularise your stylesheets and swap colour schemes and layouts at will and without rewriting tonnes of HTML every time.
Granted many people are using Winblows and IEEEEEEE or mozilla / netscape 6+, but there is still that percentage of people that are not, or will stay on Win 98 / NT 4 until they can no longer.
What about getting all the pages out in cyber space to upgrade to this standard????
Now the browsers will have to support 2 standards, the new one and the old ones, or have many pages just plain unviewable.
Only 'flamers' flame!
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?
Good point, well made.
Hilary Rosen's speech was about her love of money and her desire to roll around naked in a pile of money.
Don't like the img removal. The example given uses a fallback from mpg to jpg to text, which makes sense. But most jpg use is not in this sense but just as plain pictures, and the alt tag provides a sufficient fallback mechanism for that. Having to specify the mime type of every picture you use seems like extra work for no gain as well. What happens if you leave that off? Is there some other reason for this?
The nested sections makes a lot of sense. You can probably rig this up in XSL right now if you really like it.
The href attribute to almost anything is the best part. Not having to wrap pictures in <a href=> tags will save quite a bit tags and convey the actual intent much better.
A Slashdot article about XHTML 2.0 and the wave of the future and yet the top of every page has the line:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
3.2? Now that's a blast from the past. How much do you want to bet that Slashdot's audience by and large uses browsers that are compatible with XHTML 1.1? This isn't the AOL start page after all...
Well...at least they have an XML and an RDF feed.
- I don't need to go outside, my CRT tan'll do me just fine.
No really, it's a tree language. If it was MARKUP - i.e. layers of "virtual highlighter pen", it would allow overlapping tags, and wouldn't shoehorn weakly structured data into rigid trees*. As it is, XML corresponds closely to Lisp sexps, but reimplemented badly with shitty redundant syntax.
XHTML is a particularly bad application of XML, because HTML text is intended to be authored by humans, not autogenerated by and for some bloated SAX parser/DOM tacked onto a bloated Java/CLR VM.
People liked HTML before XHTML because it was forgiving. One could forget a few close tags, one could <b>overlap <i>tag<b> runs <i> and the browser would muddle through.
There's no particularly good reason to burden people with maintaining rigid tree structure if it doesn't make sense. One of the major problems I have with people usng XML is is the weeks/months they spend agonising over their Schemas, on the correct way to shorehorn their transient data into pretty trees - for god's sake, people! If you're using tools so inflexible that you can't just change your mind halfway through, maybe it's time you stopped using the buzzword-laden marketware of XML/Java/C++/C# and moved to a more flexible platform, like Perl, let alone Lisp! 90% of the time, the stuff I see could just be a ASCII CSV dump of an array, or just a stream of bytes! At least Lisp sexps don't force you to bother with close tags that redundantly echo the open tags - and they have identical expressivity, since XML is a tree, not a markup, language.
Bring back real Markup languages! The XMLers have lost their way. They're busily reinventing lisp, badly (yet again) - they've just come from the other side (data-side) to all those scripting languages (code-side) that are slowly mutating into Lisp, where data is code and code is data.
* (And yes, I know that you can eventually make most everything look like a very broad tree-structure by placing a virtual root before an arbitrary collection - witness the UNIX filesystem! - but I hope the reader can see that that's not really my point)
Choice of masters is not freedom.
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.
It's not about to change at all. Because nobody is going to use xhtml 2. At least nobody is going to use it until one of two things happens: a) it is supported by internet explorer or b) somebody has the gumption to smash MS's anti-standards monopoly. As MS has loads of money and you Americans cannot seem to escape from your view that people who have money are obviously good or clever then I suppose it's gonna have to be a).
By the way, all my web pages are xhtml 1 transitional - but all my client's browsers ain't.
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".
Total mess in Konq 3.0.0-12
Close. RHTML already exists. Ruby embedded in HTML is wonderful to work with.
There are already many tools for tanslating Docbook to HTML or to paper surrogates like PS or PDF. If you consider XLST, then you can quickly make your own tools.
Not only that, with Docbook and TEI your markup is based on content, making the mythical sematic web one step closer to reality.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
why hide XHTML behind the text/html content-type?
Because if you serve XHTML to IE 5.x or 6.x under the application/xhtml+xml content-type, IE will render it not as an XHTML page but in a form more similar to source code: an XML tree. Somebody told me that to get IE to render it as HTML, I have to use some sort of XSL stylesheet. Does anybody know of an XSL stylesheet that allows use of XHTML with IE in the normal manner?
Will I retire or break 10K?
nine-tenths of them look at 4.01 Transitional, get validation under it, say "Hey, I've got standards-compliance!", and walk away
How does a web developer achieve both Strict standards compliance and Netscape 4.x compliance? Some people don't have the money to buy even the four-year-old computer hardware capable of running Mozilla, so they stick with Netscape 4.x, which runs at an acceptable speed on their hardware.
Will I retire or break 10K?
if you sniff their versions properly you can redirect them to a page that has links to upgrade their browsers.
According to the Mozilla 1.2a release notes, its system requirements include the following:
Many users of the World Wide Web do not have the money to purchase such equipment. They make do with their old Pentium 133 with 32 MB of RAM that runs Netscape 4.x. It would cost real money to upgrade their browser, and it's illegal for many people to earn money.
Will I retire or break 10K?
and google becomes an RSS service we can point our agents at.
But if the major search engines and other HTML-based services become easily scriptable, then the search engines lose the revenue stream of advertisements. That's why the Semantic Web won't work. Either that or most Semantic Web sites will become pay sites.
Will I retire or break 10K?