Why You Should Use XHTML

Da_Slayer writes "The w3's HTML group has released the 6th public working draft for XHTML 2.0. XHTML 2 is a general-purpose markup language designed for representing documents for a wide range of purposes across the Web. Meaning it is to be used for document structuring which is why it does not have presentation elements. The draft is located at w3's website. Also they have a FAQ about why you should use XHTML over HTML. It goes into specifics about embedding MathML, SVG, etc... and has links to tools and resources to help convert existing html documents to xhtml. One of those resources is a document on XML events and its advantages over the onclick style of event handling."

Comments

Funny quote

[slashdevslashtty]

Which browsers accept the media type application/xhtml+xml? Browsers known to us include all Mozilla-based browsers, such as Mozilla, Netscape 5 and higher, Galeon and Firefox, as well as Opera, Amaya, Camino, Chimera, DocZilla, iCab, Safari, and all browsers on mobile phones that accept WAP2. In fact, any modern browser. Most accept XHTML documents as application/xml as well. See the XHTML Media-type test for details. Does Microsoft Internet Explorer accept the media type application/xhtml+xml? No.

Re:Funny quote

[JamesKPolk]

Let's see what the MS apologists have to say about that. If their browser is so great, why can't they handle docs that use the W3C-recommended mime-type?

Of course, I'd like to see what the people who call Google a great, loving, standards-obeying company would say to the fact that Google can't handle application/xhtml+xml either?

Before I added a special-case hack to send my pages go Google as text/html (thus violating the W3C mime-type recommendation), Google would not read the content of my pages, and would offer to show an "HTML version" of my XHTML which was actually blank.

Re:XHTML and XML??

[Ambrose]

XHTML is HTML redone in XML. So XHTML is an XML "language", like MathML, SVG, etc.

Re:XHTML and XML??

[gregarican]

XML is a data definition language. XHTML is not.

Why You Should Use XHTML 2.0 ????

[stonebeat.org]

XHTML 2.0 almost forces you to seperate "content" from "presentation". Which is a good thing.

Something better would be to use pure XML for creating content and then let the browser apply a CSS to present the content.
See Mozilla + CSS + XML = Structured + Formatted Content for more info.

Re:XHTML and XML??

[typhoonius]

XML is a metalanguage; that is, it's a mark-up language for writing other mark-up languages. XHTML is one such language. It's basically plain old HTML but with XML's stricter rules. I like it because it discourages sloppy coding (sort of like preferring Java over Perl).

Other XML languages include SVG (for vector graphics), WML (for simple web pages designed for cell phones; never really took off), and RSS (for news feeds).

Re:XHTML and XML??

[volteface]

While HTML is an implementation of SGML (Standard Generalized Markup Language), XHTML is an implementation of XML (Extensible Markup Language, which is a subset of SGML used for describing different types data).

Basically as long as HTML follows the syntax structure of SGML correctly it is considered valid, but XHTML must follow the rules of XML correctly in order to be valid.

Re:XHTML and XML??

[Kentamanos]

XML is a pretty generic set of format rules. There are LOTS of various formats that are implemented in XML (SVG, XHTML, XSLT for some popular examples).

XHTML applies the rules of XML to HTML. For instance you can have one root node, you have to close all tags, attributes have to have single or double quotes around their values, etc.

Writing something that parses XHTML is a LOT simpler than writing something that parses HTML. It's also easier to confirm you've written it properly (using schemas for instance, which are also written in XML :)).

It's always the way.

[caluml]

From the FAQ:

Which browsers accept the media type application/xhtml+xml?

Browsers known to us include all Mozilla-based browsers, such as Mozilla, Netscape 5 and higher, Galeon and Firefox, as well as Opera, Amaya, Camino, Chimera, DocZilla, iCab, Safari, and all browsers on mobile phones that accept WAP2. In fact, any modern browser. Most accept XHTML documents as application/xml as well. See the XHTML Media-type test for details.

Does Microsoft Internet Explorer accept the media type application/xhtml+xml?

No. However, there is a trick that allows you to serve XHTML1.0 documents to Internet Explorer as application/xml.

Include at the top of your document the line in bold here:

<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet type="text/xsl" href="copy.xsl"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transition al.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>

where copy.xsl is a file that contains the following:

<stylesheet version="1.0"
xmlns="http://www.w3.org/1999/XSL/Transform">
&am p;n bsp; <template match="/">
<copy-of select="."/>
</template>
</stylesheet>

Note that this file must be on the same site as the document referring to it.

Re:File this in the Irony category

[smartalecvt]

There were two good articles on alistapart.com about bringing /. up to code.

one and two

Inertia is an ugly thing.

XML vs. XHTML vs. HTML

[diagnosis]

A quick summary of XML, and XHTML vs. HTML:

XHTML is the next iteration of HTML. It is more formal and more strict, and (hopefully) more consistent. From http://www.w3schools.com/xhtml/xhtml_html.asp:

XHTML vs. HTML:

• XHTML elements must be properly nested
  
• XHTML documents must be well-formed
  
• Tag names must be in lowercase
  
• All XHTML elements must be closed
  

XML:
XML is not really parallel to XHTML/HTML. It is more useful for defining data containers and storing data. It is another step along the path to separating content from presentation.

From from http://www.ucc.ie/xml/#acro:
"XML is actually a `metalanguage' --a language for describing other languages--which lets you design your own customized markup languages for limitless different types of documents."

---------------------
Dr. Movie Movie: DrMovieMovie.com
Tomorrow's media behemoth -- today's independent voice.

Re:XML vs. XHTML vs. HTML

[volteface]

"XML is not really parallel to XHTML/HTML. It is more useful for defining data containers and storing data."
Not sure this is not entirely true. Technically, a strictly conforming XHTML document is an XML document. If you think of an XHTML document like a hierarchy (which is in fact what it is in the Document Object Model), it becomes clear that a website is made up of data and data containers. This is my interpretation of it at least.

You are right that HTML and XML are really not parallel, though, other than they share the same SGML syntax.

XML on web sites sucks

[laird]

Nope, you're right.

I'll go out on a limb and say that using XML as the document format for web site production is a terrible idea. XML is a great data exchange language between systems, but it's insanely inefficient for use within a single system. All of XML's positive attributes (self documenting, robust, extensible, supports encodings, validation, use XSLT to do transforms between arbitrary XML representations of data, etc.) are all important between loosely coupled systems. But those issues don't occur within a single system, and the overhead of using XML is immense. It's orders of magnitude faster to query a datbase directly than to parse XML, transform, etc.

Re:on slashdot?

[MP3Chuck]

You weren't kidding when you said "a lot" ... damn!

For those who didn't RTFA the parent post had, it restructures /. with XHTML and CSS. Bottom line:
* Savings per day without caching the CSS files: ~3.15 GB bandwidth
* Savings per day with caching the CSS files: ~14 GB bandwidth

And the traffic figure they used was from June 2000. Do the math.

Re:on slashdot?

[Anonymous Coward]

Not to mention additional savings they could accomplish by using properly compressed PNG files. Also, valid HTML/XHTML tends to compress better (and they do use mod_gzip).

Re:/. should lead the way

[CHaN_316]

There was an article on slashdot a while ago about retooling slashdot with XHTML. A pretty good read that summarizes the benefits of XHTML/CSS. The cost savings pretty interesting too:


*Savings per day without caching the CSS files: ~3.15 GB bandwidth
* Savings per day with caching the CSS files: ~14 GB bandwidth

Most Slashdot visitors would have the CSS file cached, so we could ballpark the daily savings at ~10 GB bandwidth. A high volume of bandwidth from an ISP could be anywhere from $1 - $5 cost per GB of transfer, but let's calculate it at $1 per GB for an entire year. For this example, the total yearly savings for Slashdot would be: $3,650 USD!

Re:No, XHMTL is broken

[AuMatar]

For me, you, or anyone reading slashdot, it probably isn't. Remember, this is the average Joe we're talking about. Ok, perhaps the slightly above average. The XHTML spec is far more complicated than HTML was. CSS and stylesheets is something they just don't understand, they don't get the idea of separating content from presentation (in fact to many of them, the two are equivalent), and they don't understand the idea of abstraction that they represent.

HTML 4 was worse for the average guy than previous incarnations, but XHTML is terrible for them.

Re:File this in the Irony category

[critter_hunter]

Rob mentionned in his journal not too long ago that he had redesigned his page using HTML+CSS and that he would like to someday do the same for Slashdot.

Re:You have to wonder...

[volteface]

Well, Microsoft seems to be pretty big on promoting the use of XML as a whole, especially with its integration with their more recent .NET technology. What this means for IE and XHTML I don't know, but it definately seems to be a standard that Microsoft is interested in.

On a somewhat related note, Longhorn's presentation subsystem (Avalon) will use an XML-based definition language called XAML (similar to XUL, I believe) to define application user interfaces.

With XML being so common in new MS technologies, I would say they will more than likely adopt XHTML soon enough.

Re:XHTML and XML??

[JeanPaulBob]

No one seems to have explained this point sufficiently, so I'll give it a go. (The other posts give correct information--but incomplete.)

XML looks a lot like HTML. If you look at any XML or HTML document, you'll see a bunch of tags--a word or phrase or letter surrounded by greater than/less than symbols--perhaps with text in the middle. For example, here's basic HTML:

<p>The quick brown fox said, <i>"Lorem ipsum dolor sit amet."</i></p>

Your web-browser sees the <p> tag and interprets everything between it and the closing </p> tag as a paragraph. The text is formatted accordingly, with line breaks before and after. Similarly, the browser knows to show everything between the <i> and </i> tags--which are nested inside the <p> tags--using italics instead of standard formatting. Other tags include <img> for images; an image tag also has attribute inside the tag to specify the image to be shown. For example:

<img src="mypic.jpg">

That's HTML. XML is structured in pretty much the same way. Tags are used to give meaning to text in a systematic way, attributes can be included, tags can be nested, etc. For instance, you might store information for an address book in the following tags:

<entry>
<name>
<firstName>Joss</firstName>
<lastName>Whedon</lastName>
<title>Mr.</title>
</name>
<address>
<streetNum>1324</streetNum>
<street>Mulholland Dr.</street>
etc.
</address>
</entry>
<entry>
info for another person
</entry>

Then you would write a program that parses the data and displays it onscreen or saves it to your PDA or whatever.

The key difference between XML and HTML or XHTML is that XML tags have no inherent meaning. You can use any text you want as a tag name, with a few limitations (no spaces, for instance). There are no assigned tag names like there are in HTML, where a <p> mean paragraph, and <b> means bold, etc. In the above example, you could change "entry" to "stickyWicket" if you want. XML data is meant to be interpreted by a machine, not a person--though meaningful tag names are obviously more convienient than random junk like "xkljad".

As the other posts say, XML has some stricter rules than HTML. For instance, in HTML, there's a tag <br> for a line break. It doesn't have a closing tag--you just put it anywhere you want a new line to start. In XML, every tag has to have a closing tag--though you can combine both the opening and closing tags using the / symbol. You can use that to make your XML more concise. For instance, the <name> tag above with nested <firstName> and <lastName> could be simplified to this:

<name first="Joss" last="Whedon" title="Mr." />

People have used XML to define all sorts of formats, from music notation to images. All that means is that they decided on a tag structure with meaningful tag names and nesting, and published the rule set. Then anyone can write applications to deal with that data. XHTML is just the old HTML tag with the strict XML rules. So, in XHTML, a line break is <br />.

To sum up, XML is just a way to structure data systematically. XHTML is an XML document with particular tags intended for a web browser.

Re:on slashdot?

[Quixotic]

that's assuming those savings are if all client browsers dont support gzip compression... i'm fairly certain slashdot will gzip compress it's pages if the browser will support it.

since text compresses really well, those savings will probably be quite a bit less...

CGI.pm

[mishan]

I don't know about you guys, but my pages are already written in XHTML 1.0 and, thanks to CGI.pm, all I need to get my pages up to the XHTML 2.0 spec is a newer version of CGI.pm which would be provided through a newer Perl distribution.

Ah portability..

Re:why you *should* use XHTML

[Laebshade]

Why should you encourage XHTML?

• Readability: XHTML is readable as long as it is structured correctly. Note: That doesn't mean having everything on one line.
• XHTML can be done with a plain text editor just like regular HTML, though as always, it's best to use a text editor that at least has syntax highlighting.

I code valid XHTML nearly everday as a freakin' hobby. There's 3 useful things I've come to know:

• Make it structured and it is easily readable. Tabs, line breaks, and spaces in appropriate places.
• A text editor with syntax highlighting. A must.
• Ok, so I forgot what the third was.

The above is true for nearly all programming. Slashdot, home of the all-knowing arrogant beings.

Re:XHTML and XML??

[blanks]

I can understand your point, but the fact is it is forcing people to follow standards. One reason I test my web apps in many browsers, if it dosent look the same in all of them, I'm not doing something right! If people are not willing to use these standards, then their websites will not look right in most browsers anyways. Just because new browsers let you get away without following standards dosent mean people should be able to write sloppy code, and by this I mean most ma and pa sites dont even follow standard HTML specifications.

Re:on slashdot?

[blanks]

Its been done http://www.alistapart.com/articles/slashdot/ Its happening now http://www.slashcode.com/plugins/04/03/04/0229237. shtml?tid=4&tid=24&tid=28 Big update in next few months in the cvs http://www.slashcode.com/ Yes its not here now, but it sounds like slashdot will be XHTML compliant soon. If you dont like it, fix it, public CVS. Dont bitch, change it your self.

Re:XHTML and XML??

[canon006]

Good descriptions so far, lemme add my two cents. A professor I had put it this way, "XML is more like a set of rules than a language; XHTML, SVG, etc are languages built using those rules."

I always thought it was a good way to think of the relationship.

Re:XHTML and XML??

[Cereal Box]

How do you know that? Did you actually write both an HTML and an XHTML parser?

I'll tell you why it's easier to parse XHTML than HTML: if you're sure you've got well-formed XHTML data, then ALL you need to "parse" XHTML (that is, get it in a document tree format) is an XML parser, which someone else has conveniently written. Compare this with parsing HTML, which requires hacks to compensate for HTML's looser rules (i.e., elements like <p> and <br> which don't need to be closed off, etc.).

Now rendering XHTML is another story altogether, but there is no doubt that parsing XHTML is FAR easier than parsing HTML.

Re:Oh God, not again...

[the endless]

why don't they fix CSS first and try doing something GOOD, like making the id and name attributes the same or both handled in CSS and javascript

The id and name attributes aren't meant to be the same. The name attribute is used for naming form controls, and (for example) this means that all radio buttons that are meant to be part of the same set all have the same name. Since the id attribute is meant to contain a unique identifier, making them the same would mean either [a] making it impossible to group radio buttons, since their names would need to be unique, or [b] making it impossible to grab an element by it's unique identifier, since ids can't be unique if you want to group radio buttons. Which would you prefer, exactly?

Re:File this in the Irony category

[Grant_Watson]

"WTF? The work was already done for you!"

There's a big difference between converting a staticly-saved page to XHTML and patching up Slashcode to generate the same. The latter would have to be done to make Slashdot use XHTML, and it's a lot more work.

Still, CmdrTaco expressed interest in patches, if anyone would like to provide them.

Re:You have to wonder...

[Anonymous Coward]

I'll grant that XHTML 1.0 doesn't make clear either way whether its text/html compatibility profile extends to future versions, but will assume it does for a moment. So if you wish to use text/html, you must follow the guidelines of Appendix C of the XHTML 1.0 specification.

One of these (C.7) is to "use both the lang and xml:lang attributes when specifying the language of an element." So if you need to specify a language, you need to do it two ways. Fair enough. Oh, but the section in the XHTML 1.1 specification on changes from XHTML 1.0 Strict says that "On every element, the lang attribute has been removed in favor of the xml:lang attribute." So, there's a simple case where XHTML 1.1 can't be served as text/html.

Another big one is use of the name attribute as a fragment identifier (C.8 in XHTML 1.0 spec). These are used for such things as anchors within a document. Again, 1.0 Appendix C has a suggestion that one set the id and name attributes together to the same value. And XHTML 1.1 has removed the name attribute from the a and map elements.

However, all of this is moot as the W3C position seems to be that the compatibility profile defined in XHTML 1.0 does not apply to 1.1. There is even a W3C Note on XHTML Media Types which you may find enlightening (as seems to often be the case, the pretty colors near the end are the important parts here).

Furthermore, I'd recommend reading Sending XHTML as text/html Considered Harmful by Ian Hickson.

Re:OK, ya got me

[mrchaotica]

HTML is a presentation language and well, websites do present. It doesn't take a programming genious to separate the presentation from the content if that is desired.

Allow me to illustrate the important difference between HTML and XHTML: the <i> tag vs. the <em> tag. They do the same thing, right? Wrong! They only look the same on a web page, in a normal visual web browser. But that's not all that XHTML is for -- imagine an audio web browser, for the blind. How is it going to know what to do with that <i> tag? How do you speak "italicized"? Speaking with emphasis makes much more sense. Also, what if instead of a person, it's a computer program parsing the XHTML. <em> means that the phrase is more important than the other text -- but what does <i> mean? For all the program knows the author just felt like writing in italics for no apparant reason!

That's just one example; the entire point of XHTML is that the entire thing is designed with these kind of things in mind. Another example is tables; in HTML they're often used for page layout. In XHTML, they should only be used for tabular data; page layout should be handled with CSS. This is because in XHTML, <table> means "this is tabular data" rather than "this is arranged in rows and columns".

Also, navigation bars: in HTML, you'd see things like this: "home | foo | bar | links | goatse" -- just a bunch of hyperlinks, separated by pipes. This is wrong (although technically valid) in XHTML. Instead, you should think about what you're actually making -- a list of links. Therefore, use <ul> instead, and use CSS to make it look like the row of |-separated links (which can be done, fairly easily -- check A List Apart)

Anyway, the point of this is that a XHTML document isn't just a "web page" -- it's a semantic document that should be useful in things other than a web browser. It should (ideally) be usable on everything from a PDA browser to a printout to a powerpoint-style presentation to a text-to-speech browser. Most importantly, it should provide semantic markup for use with spiders and such. Normal HTML doesn't do this.