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."
VXHTML or RXHTML?
Get the EULA T-shirt
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
Actually, that blurb was taken verbatim from the article. Credit due where credit is due...
Nicholas Chase writes...
Do you even lift?
These aren't the 'roids you're looking for.
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.
You know how children's TV shows are required to display good moral lessons and homilies about stewardship and good citizenship? I would be in favor of a measure that would require TV programs, like Friends, to insert adult-educational tidbits into the dialogue. They do this to some extent with Ross' excellent paleological viewpoint and I think we can attribute the popular success of movies like Jurassic Park to our increased understand of dinosaurs from this innocent-seeming sitcom.
Back to the point, I think /. should embark on a writing campaign to the networks they patronize, offering to serve as technical guides for the creation of Will & Grace episodes that contain deep insights into Computer Science.
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.
This annoys me for one key reason: I am a programmer, not a designer.
Now, if I want to make any web-interface code I have to write 500 lbs of html code just to make my HTML pages look decent instead of just being able to use a couple of nice <font> and <b> tags.
I don't want have to write a style sheet just to make project pages look good, thank you very much.
Hilary Rosen's speech was about her love of money and her desire to roll around naked in a pile of money.
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 think most of the post i have read in here are missing the point. this will not happen tomorrow. and once it starts to happen there will be (long) transitional period. actually i am sure that someone will write an xsl to convert any xhtml 2.0 to xhtml 1.x (and probably the other way around too). i am also sure that for quite sime time any browser will render both anyways. and for all that are complaing that they just want to write simple webpages and dont care for all of this: use a WYSIWYG editor! but for professionals this is important stuff. to prevent "infolation" by helping searchengine to get the content effectively this is important stuff. but rest assured there will be tools that will ensure that joe schmo and assembler developer X can publish their stuff on the web.
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
Yet another poorly implemented standard that I will have build/debug for. I wonder what super dooper features Microsoft will add on to give it for extra bonus fun? Happy Happy, Joy Joy!
No artist tolerates reality. -- Nietzsche
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...
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.
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.
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?
In case you were wondering how long it will take before browsers can handle XHTML 2.0.
Here are 2 techiniques to do this already in recent browsers:
CSS, works in Opera 6, Mozilla 1.0 and IE 6
XSL, works in Mozilla 1.0 and IE 6
I only go a few paragraphs in and I'm already dissapointed. They still represent CSS in a non-XML form. Why in the world would they not move CSS or whatever style language they want to use into an XML format? Now people that want to parse these things are going to have to write or continue to support their own CSS parsers instead of just using existing XML parsers! I'm not asking them to re-invent CSS or its rules, but please, let's change the syntax so that XHTML and CSS both live in XML documents.
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.
Dunno about that - only a few people I've met disliked HTML for that reason, and they were all finicky computer-geek types like myself (but less observant of what the "norms" do) - everyone else:
(a) Just assumes everyone else has the same browser they do.
(b) For non-trivial documents, just uses a WYSIWIG edifor of some description, and just dives into the HTML and tweaks the tags here and there if they feel like it, with the net result that even if the WYSIWIG editor spat out valid XHTML to begin with (unlikely in the first place), it sure isn't when they're through with it.
(c) For trivial documents, writes fragmentary html, maybe even remembering that head and body both exist.
HTML brought online document authoring to masses of people who don't really care about computers, but love the fact they can now build an online community of lacrosse players or some such. I beleive HTML became popular in part because it was actually simple enough that it was _easier_ to write HTML than learn to use a new type of wysiwig editor. These days, new editions of HTML books have big scary warnings about not forgetting to close your tags, to remember to close them in the right order, remember to put in / in singleton tags like br, why you should separate content and presentation, etc. None of which the average joe _wants_ to care about. And a bunch of geeks telling him to will just annoy him.
Choice of masters is not freedom.
The muddleing you speak of was different between implementaions
That's not really my point:
I'm actually arguing that the XML and XHTML language syntax and structure itself is poor - I do, however, beleive that a common set of HTML tags should be standardised - just not that those tags should _have_ to be in arranged in a rigid tree-structured document. e.g. There should be a consensus that p should continue to mean paragraph. I do not believe that I should have to remember to close my p tags.
Choice of masters is not freedom.
People keep whining about how font tags are bad. The only thing I tend to use them for is the color attribute. So, I'm quite happy using my poor deprecated font tags.
Frankly, I don't even listen to 'standards' anymore. Why should I? w3c lost the ability to dictate standards when Microsoft and Netscape moved into their turf. Not to mention the fact that their page is perhaps the ugliest site I've ever seen. Do you really want to be taking advice from them?
I check my pages with Mozilla, IE, and lynx. If they work in all three, damn the rest.
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.
You're not having much luck are you ;-)
Exactly! Not that I'm against XML, I use it everyday. And having a standard document format for everything and a standard API for accessing that data is wonderful. But I agree that HTML made page authoring easy enough for non-techies to be able to create sites about their cats, their little clubs, their personal lives and ideas, and that made the web really interesting in its day (something it has lacked in recent years).
It's great and all that we now have sophisticated document management system (one of which I'm guilty of having created, see .sig for details :)), but the fact of the matter is that all of this "easy" content management has only really created a new barrier to entry for the average joe wanting to publish his/her thoughts. It also helps further the rift between corporations/multinational conglomerates who are able to publish using these high-end systems and the average joes that made up the original commercial-free population of the net. While standards help the big guys do what big guys do, they also inhibit competition and are exclusive in this fundamental way.
So while we can have discussions about interoperability between CMS systems and at the same time talk about the refinement of HTML into a "proper British grammar" of itself, it's important that we recognize a few applications that have grown out of the need for "the rest of us" to express ourselves as well (specifically, blogging). And anyways, it should be the responsibility of the software makers to worry about standards compliance. For far too long now software like dreamweaver/frontpage/homesite/et al have been excused for their poor output quality, but it looks like things have improved at least somewhat on that front in recent years.
Now it's time to kick the leading browser out on its ass and get on with the web as it should be. Free for all, and accessible by all.
P.S. If you hate XML so much for structuring documents, you may appreciate YAML, SLiP, and the like. Search for them on Google.
putfwd.com - 1GB Free file storage with a twist
Proof of concept, anyway. This page doesn't work entirely in IE, because of IE's horrible <object> bugs. Works great in Mozilla, pretty good in Opera.
I'm as mimsy as the next borogove but your mome raths are completely outgrabe.
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.
How a first post can be redundant?
Adding the ability to display XHTML2 correctly doesn't require the hackers to remove old HTML display capabilities.
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?
Search engines can look at the meta-data I provide. There must be four specifications for that at this point.
Google ignores <meta /> elements because of the rampant spamming associated with unscrupulous use of keywords in <meta /> elements.
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?
The latter. With XHTML1 you had to close tags, for example you had to have </p> tags at the end of paragraphs. A problem was that some tags, like <br> and <hr> didn't have closing tags, so they were written as <br /> and <hr /> which would still work perfectly on very old browsers.
With XHTML2, old browsers don't know about the <line> tag, so it won't create a seperate line after a </line> tag, and you have to keep using <br /> if you want to support old browsers.
New versions of browsers will be able to render old HTML specs for many, many years to come.
When you make your money from an audience your goal is to reach that audience in a manner that increases your profit or at least maintains it. Cutting off 60% of that audience or presenting them with a sub-par show may be a web-altruistic thing to do, but it also is business suicide.
Also don't forget that:
1. What you see isn't necessarily what everyone else gets. The code you see may have very well been negotiated by the server with your browser.
2. CSS overrides many of those deprecated tags in browsers that support it, so just because you see a tag defined in the source doesn't mean the presentation it causes is entirely caused by the attributes of the tag - check the stylesheet(s) before you throw stones.
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?