XML was badly designed garbage; XHTML is badly designed garbage. Ditch them both.

HTML5 is made of fail. Those dodgy shadows remind me of marquee and blink.

Please everyone ignore HTML5.

"HTML5 is an attempt to subvert XHTML" What crap.

Do you want Microsoft to set their crappy standards, or would you rather it was a bunch of people who cared about the Internet, i.e. a standard where the public gives a shit?

BTW, Robert Long, XHTML is not garbage and neither is XML. Yes, there are interoperability issues; these show exactly why these standards are a great idea.

Don't talk out of your backside. Believe me, you have plenty of room to talk.

It's clear that you don't have any useful function or qualification in IT. If you did, you would have an IQ of at least above 100 and would use your mouth to speak instead of using the orifice which others reserve for defaecating.

Anyhow, should be interesting to see what they come up with.

At the end of the day the browsers have to support this, and all seem to apply their own interpretation, if we get things that make the code cleaner, enable interoperability across the browsers a bit better, sure it is all good.

XML has always struck me as a poor man's first draft to a database, there is so much extra code around the loose data structures, I tend to use it when I can be bothered as a prototyping structure. Once the space is known then better to model with more rigid datasets and handle anything new as an exception to extend the system.

HTML5 is exactly what the web doesn't need, a bunch of widely different ways of doing the same thing making it a nightmare for user agents to support properly.

Building specific content multimedia elements in to the standard is also just outright foolish and simply works against a major goal of creating standards - ensuring they are futureproof.

The biggest difficulty XHTML faces is that it requires programmers who know what they're doing to implement it properly. It requires programmers to properly understand separation of concerns that is separation of code, content and design and XHTML excels at pushing this important agenda that would leave to an interoperable, usable, extensible, accessible web.

HTML5 is focussed towards bad programming habits, this allows more people to write code but leaves the web in the same old mess it always has been which is a bad thing, it's only going to continue to lead to browser incompatibilities due to so many things being undefined - does setting a height/width on a video tag for example define the size of the video plugin area or the size of the actual video area? these are the sort of little complications you have to deal with if you start putting these into the standard and that you then can't count on being implemented the same between brwoser versions.

What needs to happen is HTML5 to be ditched, XHTML and it's agenda of a better web to be pushed and people forced to spend just a little extra time (it really doesn't take much) to figure out how to write pages properly. If people do that, we'll all be better off, if instead we continue making the problems that HTML4 and earlier always suffered worse by pushing forward with HTML5 then we'll forever have to keep providing hacks for each different possible browser people might use to make it look the same.

The web needs a bit of professionalism applying to it's design and XHTML provides that, please let's not keep the web back another decade by making HTML5 the standard people follow just because it's easier so that even people like Robert Long above, who clearly don't have the slightest clue about XHTML/XML and the benefits of these technologies over HTML5 can make web pages.

XHTML/CSS = extensible HTML, built on a coherent logical basis, with equally extensible styling. How much REAL need for breaking the codebase of the entire World Wide Web is there?

I've been coding webpages since the early nineties and teaching web development at university since 2003. At that time I started teaching XHTML because it was then 'the future' and XHTML 2.0 was the thing to aim for so graduates wouldn't get left behind in their language usage. XHTML enforced the standards much better than HTML. The meant that I could also teach accuracy.

A couple of generations of graduates later and we're still waiting for the future. Is it any wonder that frustrations with a static language have surfaced and that people want to develop? Although the standards arguments are interesting academically we do live in the real world.

Whwther we code XML, XHTML or HTML then ther is a standard to be followed, but technology and techniques are moving on. Standards had better make the effort to keep up. They'd also better decide on a direction.

However I can already hear the arguments that manufacturers should follow standards. However if the standards do not cope with the requirement then the standards are inadequate. It would, however, be counterproductive for there to be a free for all again (remember Netscape?) so getting real and keeping up is not really an option - it's now a requirement.

"Yes, there are interoperability issues;.." ...By Anonymous Coward

Posted Friday 16th May 2008 23:10 GMT

Don't you just love the Heavy CompleXXXX Semantics in that Simple Statement. Tear away all the waffle and what you are left with, are naked attempts at nothing more or less than Exercises of Dominance rather than CoOperation with any Pre-Eminence allowing for Global Markets and Currency Control.

Any Control Programmer/Systems Analyst worth anything at all, will always Program Systems to Beta Control Management of Imagination and Perception for then they Offer Total Information Awareness Control of the Future.

AI Priceless Alien Gift for Free?!. .... and Light Years ahead and so much more than just QuITe Princely too.

XHTML is far more robust than HTML. It really is designed from the ground up as being a markup language. That is to say, its strengths are in the separation of the presentational content from the informational content.

IMHO, I'd choose well formed Strict-XHTML and CSS over plain old HTML and CSS.

It's not XHTML that's the problem... It's the different way user agents render CSS. If you ask me, the WaSP project is a step in the right direction. The best all-round solution would be if there was an open-source project to build a rendering-engine that ALL user agents would use. Then it's just the feature-set built around the rendering engine that would separate the different browsers.

Imagine that... KNOWING with 100% certainty that your page will look pixel-for-pixel identical on every browser. Ah, bliss!

It might take 10 years, but Rome wasn't built in a day.

Evil Bill because he allowed IE6 to be so.... SHITE.

It does seem foolish to say that XML and XHTML are garbage, but neither of you has made any case whatsoever for your opinions.

As for HTML 5 vs XHTML 2 - why do they appear to be diverging? Would it really be so hard to have a single standard for web pages?

There's nothing like a well-reasoned argument.

And that WAS nothing like one.

XML is extensible. So you have to define what you mean by the tags and where they can be. XHML is approximately an XML that defines tags that map to HTML. This is so that you can have the same processes that make your documents convert over to XHTML seamless and still understood by web browsers. A lot of what CAN be in XML doesn't make sense in HTML (like absolute positioning: what if I'm on a mobile phone with 200x400 res?).

XUL, Flash, Silverlight and the like all allow *browsers* to run an application that looks native in a cross-platform way. That was supposed to be HTML's goal, but as the web got bigger and people got used to it (and, lets face it, computers got fast enough), there was a demand for more web bling and a standard takes a long time to get accord from its many members (unless there's only one member and they want to stack voting boards, but then it isn't a standard). So HTML 5 had to wait until the market and members understood what was needed.

Probably because then I figured all its new cool features would be ported over to the next XHTML version.

But no, they took out all the neat crap.

If people care enough about Web development in a cooperative, interoperable environment, they'll support XHTML; it *can* be extended in lots of interesting ways without breaking what makes it interoperable; in a word, it's extensible.

HTML 5 likely appeals to you if you thought the recent ISO "standardization" of "OOXML" was well-run and had a positive outcome.

As TFA said, appealing to two different, mutually exclusive audiences.

As usual it will turn out that whatever the standard is the browser / applications will not follow it.

I don't mind particularly. It keeps the people wanting to have a decent website knocking on my door to hand over cash.

Yes it would be nice to have a clean standard that everybody follows.

No it will not happen

What web designers wanted was drop down menus and a way to ensure that a form field would appear somewhere close to its label.

What they got was this mess of CSS, XHTML, etc.etc.

Simply adding a "<menu>" tag and a "label=" attribute to the "<INPUT>" tag would have made life easier for the majority of web developers.

But no everybody got caught up in this purist "seperate content from presentation" b****ks. Now in my opinion this is doomed to failure because content and presentation are inseparable. Presentation has semantics of its own, the position of text conveys meaning. Especially where forms are concerned size matters, input fields should be big enough for the text you expect to be entered -- this is basic and NOT a matter of style but currently we are expected to convey this information in a style sheet.

Imagine if a hollywood studio pronounced speech and photography to be "speparate concerns" which should each be handled by a specialist director. All thier films would end up looking like "acorn antiques".

I think the HTML5 standard is a rare but welcome attack of reality at W3C.

@Plankmeister

> Imagine that... KNOWING with 100% certainty that your page will look pixel-for-pixel identical on every browser. Ah, bliss!

That's the problem, it's not SUPPOSED to look the same in each browser, that's the whole point of HTML.

My favourite web browser doesn't even support TABLES, so smoke that !!

goddam penguin, where's MY mascot !!

"Presentation has semantics of its own, the position of text conveys meaning."

Except for when you are blind, or partially sighted and the location of things becomes less important and the correct semantic markup is applied so the page actually makes sense.

Anybody who wants to go back to coding HTML 3.2 nightmares with inline presentation please go ahead. Meanwhile, I'll continue with my easy existence of totally seperated content and presentation which allows me to update the websites I manage (each reaching into thousands of pages, one over 10,000) with ease, instead of picking apart a knotted mess of table layouts, spacer.gif's and inline presentation attributes.

That said there are some good things in HTML 5, but also some things I'm not too kean over either.

Ha! Speech and photography _are_ separate. True, the same director is responsible overall, but why do you think films have cinematographers? Plus, the soundtrack often has to be re-recorded in a recording studio both to get rid of unwanted sounds and to enable dubbing in other languages (dubbing is evil in most cases, but I liked the dubbed version of The Legend 2 and I thought it worked well as a comedic device for Wayne's World).

Separating style and content is hugely important. When the presbyopia hits me I want to be able to make things bigger. When your boss wants you to change the colour of all your links you can either hit him, parse all your html pages with your favourite scripting language or use your common css file.

The problem is that CSS has a nasty horrible syntax and it can be like a sledgehammer for small sites, although the style attribute is handy. Then you try to do something simple on your blogger page and the template's CSS messes up the flow somewhere. grr. took me hours to find that one. Sanddollar, hang your head in shame.

@James Anderson - The XForms standard is a godsend for the forms developer. It's just a pity it's had such a retardedly slow uptake.

As an aside, however, the slow process of developing a standard is nothing in comparison to Microsoft's reticence to implement these standards.

You want a vector drawing standard? Here's SVG. And them Microsoft don't support it and create XAML instead.

You want some standards to work with XML documents? We're on XSLT 2.0, XPath 2.0, XQuery 1.0 etc. And then Microsoft don't support anything other than the severely restricted XPath 1.0. spec.

As a developer it's incredibly frustrating when a standard you want to use exists but you are unable to adopt it yourself due to inadequate support. I don't want to be pushed into using proprietary systems, so I'm stuck with the same tools I had in 2001.

The standards body shouldn't make it any more difficult for adoption or implementation, because this is the biggest problem that exists right now for web developers. Bring on XHTML.

We are heading back to SGML, from which HTML was but a tiny subset. The notion of publisher-definable syntax and document interoperability have been around and in use for years before Tim B-L released HTML. HTML set us back because "the masses" needed to be able to publish at will using stupidly simple concepts.

Now we are seeing that "new" ideas are running into the same wall that SGML ran into .. client capabilities. It does no good if you specify all of your syntax to the nth degree if the client is so stupid it doesn't bother to follow your instructions (DTD). There is nothing more frustrating than perfecting your schemas only to find that the vast majority of people can't view the results of its implementation because the browser they use is incredibly limited in its parsing and rendering abilities.

Let's get back to browsers that pay attention and can respond to DTDs before we worry about expanding the common pool of generally acceptable tags and attributes. As long as we allow browser manufacturers to decide which syntax to support, we'll be dragged through the tar pits of cross-browser performance issues.

As soon as we declare "unacceptable" those limiting programming decisions we will be opening the floodgates of true "mass publication", freeing those who have been trapped in the "my browser does this when the code does that" petty arguments for the past nearly 2 decades.

Sorry but this article really is complete nonsense, and shows a real lack of understanding of XML. I can't speak for the Adobe/MS stuff but to suggest XHTML is competing as a replacement for Mozilla's XUL is nothing but rubbish.

Mozilla's XUL is built from an XML language called XBL. XBL 2.0 has already been ratified by the W3C as a way of "BINDING" and thus extending arbitrary actions and behaviours into XML elements. XBL is as usable alongside XUL as it is XHTML, because it binds and extends behaviours as the author intends.

XUL doesn't have a "treeview" element because XUL defines a <treeview/> element it, it's because XBL binds a set of "tree like" behaviours to an XML document that happens to have a .xul extension (and XUL XML namespace).

Please sort it out. The X in XML stands for extensibility.

WTF! The HTML 'standard' should be retired and all the work moved to XHTML and sub projects. It's about bloody time that web authors learnt to use XML properly and got told off (and shown the right way) every time they misusing the document type or abused the document structure!

IMHO:

All web pages should be XHTML pages and a strict document type should be standard so that the browsers can be streamlined and not have to guess (wrongly) what was intended.

The garbage DOM API should be retired and be replaced with a proper, usable XML document API, similar to XOM (Java), with XPATH. A proper API should only allow child elements to be added from other valid XML documents, not direct from text. All XML APIs should transparently deal with escaping text; there is no excuse not to do this!

Separating the content and style might not be to your liking but you have alternatives you could use. For anyone else running a large website it's a Godsend.

The ease of changing the style of a website even dynamically is great. When you have multiple content editors who are news hacks and don't know anything about HTML tags (no offence to the el Reg) then you need them to be able to add content whenever and wherever they are you would not be able to do it with a rigid fixed layout.

Newspapers and book shave been doing this for decades. A newspaper has a semi rigid frame and a definitive style and the content is flowed into it.

It sounds like you come from a traditional graphic design background who's got into "New Media" rather than a web developer who actually do the grunt work.