Why You Should Use XHTML 657
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."
Funny quote (Score:5, Informative)
Re:XHTML and XML?? (Score:2, Informative)
Re:XHTML and XML?? (Score:2, Informative)
Why You Should Use XHTML 2.0 ???? (Score:5, Informative)
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 [xml-dev.com] for more info.
Comment removed (Score:5, Informative)
Re:XHTML and XML?? (Score:3, Informative)
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?? (Score:5, Informative)
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. (Score:5, Informative)
Re:File this in the Irony category (Score:2, Informative)
There were two good articles on alistapart.com [alistapart.com] about bringing /. up to code.
one [alistapart.com] and two [alistapart.com]
Inertia is an ugly thing.XML vs. XHTML vs. HTML (Score:2, Informative)
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:
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 [drmoviemovie.com]
Tomorrow's media behemoth -- today's independent voice.
XML on web sites sucks (Score:4, Informative)
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? (Score:5, Informative)
For those who didn't RTFA the parent post had, it restructures
* 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? (Score:1, Informative)
Re:XML vs. XHTML vs. HTML (Score:2, Informative)
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.
Re:/. should lead the way (Score:3, Informative)
*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 (Score:3, Informative)
HTML 4 was worse for the average guy than previous incarnations, but XHTML is terrible for them.
Re:File this in the Irony category (Score:4, Informative)
Re:You have to wonder... (Score:2, Informative)
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?? (Score:5, Informative)
Re:on slashdot? (Score:2, Informative)
since text compresses really well, those savings will probably be quite a bit less...
CGI.pm (Score:4, Informative)
Ah portability..
Re:why you *should* use XHTML (Score:3, Informative)
- 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?? (Score:3, Informative)
Re:on slashdot? (Score:4, Informative)
Re:Funny quote (Score:4, Informative)
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?? (Score:3, Informative)
I always thought it was a good way to think of the relationship.
Re:XHTML and XML?? (Score:4, Informative)
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... (Score:3, Informative)
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 (Score:3, Informative)
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... (Score:1, Informative)
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 [w3.org] 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 [w3.org] 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 [w3.org] 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 [hixie.ch] by Ian Hickson.
Re:OK, ya got me (Score:3, Informative)
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 [alistapart.com])
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.