W3C's New XHTML 2.0 Draft A Mistake?

EchoMirage writes "The World Wide Web Consortium (W3C) has been quietly working on drafts for a proposed XHTML 2.0 standard. But some well-known and well-respected web authors are balking at the proposal, because it invalidates several well-used tags. Given that XHTML 1.1 hasn't even seen any wide use yet, and many browsers are still working on basic HTML 4 and CSS1 compatibility, many people are questioning the W3C's push to create new standards before the old ones are solidly in place."

Comments

Misguided, not mistaken

[medeii]

I'd agree with Zeldman on this one. They need to rename it to something else, and do some sort of forking, because switching terminology in midstream (for no appreciably visible reason) is simply not a good idea. I can see that it makes a certain amount of logical sense to convert images to objects, etc. ... but getting rid of H* tags and, as Mark mentioned, CITE? There isn't really anything to replace that kind of semantic markup, which is unfortunate.

I do remember reading some other stuff by IBM on this, and it was a fairly cogent explanation of the reasoning, but I still don't agree with the theories behind the changes.

I wouldn't mind most of the changes myself, but it will take decades for this standard to replace the current version if they drop compatibility. I'm sure that a few days afterwards Mozilla will have support for it, but the massive numbers of people who haven't yet upgraded to CSS-capable browsers tell me that we might see a few sites using XHTML 2 in, say, 2010.

Re:why some people are upset

[coaxial]

I can see why some people are questing the value of this standards proposal.

I don't.

# acronym tag is gone

Who used this? I've never seen it used. It's demise has been overdue for a long time. I hope they killed its identical twin ABBR too. While you're at it get rid of CODE (computer code), KBD (keyboard input), VAR (program variable), DFN (defining instance), SAMP (sample program output), and ADDRESS (was this suppoed to be email or postal or both? It's ambiguity destroys any semantic value).

# q tag is gone

Good. We already have something for this. It's called the quote. It looks like this: " .

# cite tag is gone

CITE would be useful document, but without any citation fields defined its useless. Is this a standard citation like APA or MLA? Is it IEEE or ACM? Is it some sort of made up one? Or does CITE just indicate a superscript, parenthentical citation, or bracket citation? Without these fields denoted you can't do anything with it.

# img tag is gone (yes, really!)

It's handled by OBJECT, after all this is the HyperText Markup Language. Layout and textually there's no difference between an image and an applet or plugin.

Which brings us to...

# applet tag is gone (also really!)

Good. Why should Java be handled differently from Shockwave or Flash? APPLET is better replaced by OBJECT. IMG can also be handled by OBJECT as well.

# br tag is deprecated

This is a style markup, not unlike U, TT, SUP, SUB, STRONG, STRIKE, SMALL, S,I, EM, CENTER, and B.

BR will be replaced with LINE which encoses a single line of text.

# h1 thru h6 are deprecated

They were only sort of used properly. People knew they were headings, but they tended to pick them based on how they looked rather than what they meant. By depreciating these, they can be replaced by something with stricter semantics.

Missing the point

[leighklotz]

Mark is missing -- or perhaps deliberately obscuring -- the point of XHTML 2.0.

XHTML 1.0 made HTML 4.0 into an XML language, by requring that you close all tags you open and quote all attributes, and that's pretty much it. Anyone who has ever tried to write code to manipulate HTML in middleware or on the client end will see the point of making sure that the markup is syntactically well-formed.

XHTML 1.1 with modularization breaks XHTML up into modules; modularization is a key idea in building extensible systems of any type, and it is put to good use in HTML. You get a tables module, a forms module, etc. There is now modularization for both DTD-based XML and XML Schema-based XML, so you can get your job done either way.

But the real goal is to make the modules well enough defined and have the semantics and the presentation and the underlying infrastructure (what is a link, when does it get followed, what are events, etc) all well enough separated so that HTML can become just another application of XML, without a lot of special knowledge hard-coded into browsers about what "i m g" or "b r" or "r e l" means. In other words, the goal is to define modules of functionality in XML, and then be able to use those together with other modules (things like SVG ) in kind of the same way that people can use class libraries in PHP and Java and other systems, without having to have someone write a new browser for every possible combination.

Remember how years ago during the browser wars, vendors kept inventing their own tags and writing browsers that understood the tags? Well, now we've got enough of all that figured out to be able to factor the web and its interfaces into a bunch of different parts, and then let you mix and match those parts together to make your own cogent language. You use CSS for presentation styling, XML Events for events, and markup for semantically describing the content. If you have to build your own language for displaying your weblog and call it RSS, well you just go do that and you put your tags in a namespace named by your favorite URI, and you go off. You and your friends (and enemies) can write CSS style sheets or XSLT transformations or what-have-you to display the resulting pointy bracket file in a browser, and it will look and act indistinguishable from today's HTML, but will offer other advantages -- blind people will be able to use their style sheets for reading it, and programs will be able to parse the format without having to screen-scrape the HTML, and you won't have to have six versions of it around for different devices and so on.

So after we move all of the essential stuffness of the web (events, hyperlinks, object embedding, forms, styling) into their own standards and get browsers and other user agents have to hard-code those implementations, what you're left with is a need for a common semantic markup language where things are clearly expressed and easy to write.

That's where tags like <section> and <h> come from, and why they make perfect sense as transitions from <h*>.

In summary, XHTML 2.0 is just the meaning-laden parts of web pages that are left over after all of the plumbing has been moved out to other specs, where it can be shared.