The Future is XHTML 2.0

An anonymous reader writes "As with its past, the future of HTML will be varied, some might say messy, but I believe XHTML 2.0 will ultimately receive widespread acceptance and adoption. A big move in this direction will be in Embedded devices such as phones and digital TVs, which will have no need to support the Web's legacy of messy HTML, and are free to take unburdened advantage of XHTML 2.0. This Developer Works article examines the work of the World Wide Web Consortium (W3C) in creating the next-generation version of their XHTML specification, and also their response to the demand for 'rich client" behavior exemplified by Ajax applications.'

Comments

Really?

[Eightyford]

Embedded devices such as phones and digital TVs, which will have no need to support the Web's legacy of messy HTML, and are free to take unburdened advantage of XHTML 2.0.

I would have thought that if the devices didn't need to serve up web content, they would use a proprietary system that is best suited for the job. If they did serve up web content, than of course they should support HTML.

Re:Really?

[tengennewseditor]

HTML is difficult to parse because it is so syntax lenient. The point is that an XHTML parser can be much slimmer and/or faster than an HTML parser and therefore more suitable for portable devices.

Re:Really?

[Bogtha]

You point is a really good point for XHTML 1.0. However, the discussion is about XHTML 2.0, which has I think 5 different languages.

5 different languages? What are you talking about? Modules? It has many more than that, but I don't see the relevance.

tengennewseditor was pointing out that XHTML has a more regular syntax than HTML. It has this because it's based on XML. The XML parsing rules are more regular so they are easier to implement and parsers require less memory and cpu. XHTML 2.0, also being based on XML, is just the same as XHTML 1.0 in this respect.

Both Opera and Apple stated they will not support XHTML 2.0 in it's current form.

Nobody will, its current form is an incomplete draft.

Standards v AJAX

[matt me]

These are a complete oxymoron. Google and windows live (I hear) are all about reimplenting normal functionality in confusing new ways, that certainly won't work on any simple client.

Re:Standards v AJAX

[Trails]

Well, yes AJAX != Standards, depending on the standards.

AJAX is inline with all relevant technical standards ( (X)HTML, CSS, ECMAScript (except for MSIE), XML, etc...)

The fundamental standards that Ajax fails at meeting are USABILITY standards, specifically the notion of the web as a series of pages. Ajax violates this page metaphor, which has some usability gurus in minor fits of apoplexia, Jakob Nielsen included. Adhering to these standards is, imho, much more open to interpretation though. Case in point, many users like these AJAX web apps, Flickr for example. If users like it, then why are some of the usability folk, self proclaimed "user advocates", having said fits? Personally, I think it's time for the page metaphor to evolve, and clearly so does a large portion of web users.

Re:Standards v AJAX

[John Hurliman]

Ajax violates this page metaphor, which has some usability gurus in minor fits of apoplexia, Jakob Nielsen included.

AJAX doesn't have to violate the page metaphor, and I actually haven't seen any real examples of people destroying usability like people are running around yelling about. Yes it would be _possible_ to replace all navigation in your site with AJAX just as people have replaced all the navigation in their sites with a Flash menu, but the technology doesn't force you to improperly use it. If your front page has a stock ticker that dynamically updates, is that breaking usability? Also there are certain places you don't want the user to be able to bookmark, like the third page in a five page form they are filling out. The user thinks "Hey I'll just bookmark here and finish this later". Instead you could save the state of everything entered so far and return back to the position they left off at a later point with cookies, and your web app actually knows what's going on. All five pages of the form have the same url (http://www.mysite.com/survey/) so there is no confusion.

Messy HTML?

[The Ancients]

While XHTML 2.0 is more elegant - as always, the subject of this article depends on support. More flexible yes; however this also gives more leverage for non standards following types to screw with it.

I'm not entirely familiar with XHTML 2.0 (we have code monkeys who concern themselves with this these days) but is this a case of the standards following the people who will or will not use this as is intended with a begging bowl in hand, or does it really address the many concerns surround HTML/XHTML/CSS?

Re:Messy HTML?

[EchoNiner]

This is what makes it so easy to get ahead of the curve in the web game, and also why web monkeys are so often the target of derision from 'real' programmers. The industry is full of dabblers and bubble busters who learned HTML 10 years ago, and continue to eke out a living with little sense of cost effectiveness or missed opportunities.

This is true -- I used XHTML/CSS and was way ahead of the curve when I was a web developer. Now I'm going to a job as a software developer. 'Real' programmers are the only ones who take advantage of these new standards and are the only ones who create these new standards.

Of course, those who are most pedantically obsessed with XHTML validity also tend to be the ones who are using CSS to the fullest and exploring the frontiers of web development. While being too experimental does not save money for employers or clients, the fruits of these labors does. I got into the CSS-based layout game 5 years ago, and at first I didn't see the benefits because I was too busy learning the relevant browser issues and tricks. I never really noticed how much more efficient I was getting until I moved to a new job where people were still in the 1998 era of web design, and waste was immediately apparent.

Sounds just like me and I'm glad you're like that. However, my main point is that people like you and me are negligible compared to the masses of drones who create webpages with dreamweaver, microsoft word, and even the really advanced ones who use DHTML with the possibility of some inlined style tags.
(I dont' mean to insult anyone -- look at the statistics)

Why should the people crafting the standards take this attitude? Web development has a long way to go both in terms of features and efficiency, and standards are the only way to consolidate that progress. HTML has a reputation as a hack of a language, being poorly formed, and loosely interpretted. All the more reason that it needs to be cleaned up. We can't build the next generation of applications on such an untidy mess.

I agree there can never be enough browser standardization, however why should they stop the development pipeline at the top. If you look over a timespan of more than a couple years you'll see that standards support is actually progressing well. What if they had stopped with CSS 1 until all browser had it perfect? Well, we'd still be using tables for layout and it would take a skilled practicioner twice as long to build and maintain sites.

My main point is that the web standards community should change their focus. They keep releasing new standards when they hardly have anyone on board with their previous standard. What they're trying to do is compete with the newest version of regular HTML. Even if they 'win' they will have the best standard with no users supporting it. These people need to figure out a way to get people to use version 1.0 and releasing a version 2.0 is not going to help.

Yeah right

[Da Fokka]

I believe XHTML 2.0 will ultimately receive widespread acceptance and adoption.

Yeah right, just like CSS2. and XHTML1.0... 'Adoption' is not just not exploding when encountering XHTML2.0 - it means full support for the entire standard. And unfortunately we're not there yet for standards which have been around for years. I don't see why things will go differently for XHTML2.0

Who Accepts It?

[Elixon]

XHTML2.0 is nice. I would accept it immediately! But sadly this is not me and this is not you who decides what gets accepted... I'm a web developer and I'm supposed to do the best for my clients. My clients expect me to do the work in the way that the biggest audience available will be able to use it...

I will not "accept" the XHTML2.0 as long as I'm not sure that my clients can loose any of potential visitors/customers.

The right question should go to the major browser providers:
"Hey, browser creators, when do YOU and YOUR COMPANIES accept the XHTML2.0?"

(I'm afraid that it is too many years ahead to be worried about :-( )

Re:Really? No.

[AkaXakA]

Existing web is in html (and bad html at that).
ANYTHING offering 'web access' is going to support
the existing web.

Thus, HTML 5 is the future. Especially since xhtml isn't even supported properly in today's most used browser (ie. IE). And no, sending as html does not count and is even bad (yes, I'll change my own website to reflect this in the future).

Re:Why is this a story??

[Anonymous Coward]

Who cares if your HTML is messy?

People with disabilities who use screen readers, people with slow connections who would rather not download content with all the "fat" that HTML provides, and possibly even the standards-compliant browsers of the future - that's who.

Why bother writing a webpage if you're going to ignore your audience by taking the "who cares? don't look at it!" approach. If you and only you will be reading your page, then the idea of a progressive approach to compliance does not apply to you anyway.

Umm... This is a all cool, but

[berndtj]

Last I checked w3c complient browsers had less than 20% of the market share. Until IE is either updated or dead, the web is pretty frozen. Don't expect anything to change with IE 7 either.

Microsoft knows that the web is the only real forseeable threat to their operating system. What do you need windows for if you can run your rich business applications on a platform independent web browser?

I believe this a real conflict of interest that should have been addressed in all of the anti-trust hearings. Oh wait, nothing changed even after they were found to be a monopoly...

Change isn't going to happen easily

Re:Time for an Internet Reboot

[DigitalRaptor]

I don't want to be everything to everyone. But I also don't want to cater to 50 different standards for every one of Microsofts bastardized browser versions.

It takes all the fun out of being a web developer and serves no one.

I could care less about fancy new features. I just want standards, and that is finally starting to happen (until IE 7 comes out and probably screws it all up again, who knows?).

IE 5 and 5.5 are a nightmare. There are still people running on 4.x browsers on Win98 or even Win95. Those PC's are WAY more likely to be spambots or riddled with spyware and viruses. I'm just asking for a little more encouragement for people to upgrade to something more recent, like a browser and OS made this century.

What is it with those thick/thin client gyrations?

[IgnoramusMaximus]

the demand for 'rich client" behavior exemplified by Ajax applications.

Here we go again. "Thin client is the future!" -- "No the users demand bloated clients with millions of animated doodads!" .. "No wait, the thick client is a mess full of security holes!" -- "No, the server-side processing and thin clients are future, again" -- "No, wait, the rich contents thick like a brick clients are the future!" --

[interlude] Bah, "the client-server paradigm" is the future! [/interlude]

.. "Idiots, can't you see that thin is the future again!" ... "Morons, thick is the shtick!" ... "Thin!" ... "Thick!" ... etc and so on ...

Seriously though, thin, simple and reliable client coupled with powerful server-side processing is the staple of reliablity and usually the highest performance and security. The "rich client" is a fancy word for going back to "everybody needs a huge multimedia client (i.e a 23GHz CPU 3-core phone) to access this page with 4 lines of text on it!" and fat servers because the clients although bloated and huge are too dumb to do anything besides being pretty and acting like the swiss cheese of security. I think we've been there before, and it was called ActiveX, no?

Re:Really? No.

[Xamataca]

Thus, HTML 5 is the future. Especially since xhtml isn't even supported properly in today's most used browser (ie. IE)

then the war is lost... fall back!!!...
We can't fight IE's predominance so lets join forces and extend frontpage beyond the imagination!!!! yay!!!

XHTML 2.0 is the future, and will always be

[Stan Vassilev]

XHTML 2 is doomed to remain forever "in the bright future" of geeks, where noone cares for compatibility and real technology benefits, but is entirely consumed by semantics and how pretty his code is.

Look at the benefits if XHTML2 and compare it to HTML5, and you'll quickly see why WHATWG was formed.

As HTML5 offers answers to actual problems in web development, and offers backwards compatibility, XHTML2 pointlessly restructures the language, making it harder to read in the process (quick: count the nested sections spread accross pages of text to guess the heading level you're at).

Also while the author dreams about our XHTML2 future, the next major release of the dominant browser on the market (IE7) doesn't even support XHTML 1.0 yet. And this is the browser that most people will use in the next 5-6 years at least.

The author also calls XHTML's semantics better. This is subjective. HTML5 also offers more semantical tags, but according to my practise, it'll be easier to build sites styled with CSS in HTML5 than XHTML2. XHTML2 doesn't have better semantics, it just has different semantics. HTML5 is the one with better semantics IMHO, that build on top of HTML4.

No major browser supports XHTML2, but they support parts of HTML5 (like the canvas tag, invented by Apple's Safari browser, and included in the spec by WHATWG).

I won't even comment the section about XHTML2 "toys" because the subject is serious.

In conclusion I'll say that it's not likely XHTML2 will become a supported standard while most of us are alive, so better concentrate on good HTML4/XHTML1/CSS/JS/SVG/Flash code and applications, and follow the developments at WHATWG.

Conflicting goals

[Anonymous Coward]

From the article: ...the W3C's Steven Pemberton expressed the design aims of XHTML 2.0:

• Use XML as much as possible: Where a language feature already exists in XML, don't duplicate or reinvent it.
• Structure over presentation: Thanks to CSS stylesheets, you no longer need explicitly presentational tags in HTML.
• Make HTML easier to write: Remove some of the needless idiosyncrasies of HTML.

Thanks to CSS stylesheets...
Well, "Use XML as much as possible" didn't last too long. Why isn't there a version of CSS defined as XML so you just need a single kind of parser?

Make HTML easier to write
If you want it to be easier to write (and hopefully read), why not use something nicer than XML? XML is easy to parse and easy to generate, but is very messy humans to read & write.

Re:Time for an Internet Reboot

[drinkypoo]

Web browsers work. We were developing web applications before javascript and AJAX, they just make them faster and better (and do things they couldn't otherwise do.) And we're not going to stop doing this. Anything substantially server-based is probably best served by having a web interface. As hard as it can be to support multiple browsers (yes, I would prefer standards compliance myself) it's still easier than supporting multiple disparate platforms.

Re:Yeah, whatever

[starseeker]

Heh - that's EXACTLY how ANSI Common Lisp was created.

Grow up

[21mhz]

I'm amazed at how immature some of my /. friends' friends can be.