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.

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.

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: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: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.

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: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?