Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Programming The Internet IT Technology

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."
This discussion has been archived. No new comments can be posted.

Why You Should Use XHTML

Comments Filter:
  • by Anonymous Coward on Friday July 23, 2004 @02:18PM (#9781841)
    Slashdot isn't even valid regular HTML, let alone XHTML, and they're running a story on why we should be using XHTML? I'd laugh if it weren't so sad.
  • by ViolentGreen ( 704134 ) on Friday July 23, 2004 @02:18PM (#9781847)
    Can someone please explain the differences between XHTML an XML?
    • Re:XHTML and XML?? (Score:2, Informative)

      by Ambrose ( 16701 )
      XHTML is HTML redone in XML. So XHTML is an XML "language", like MathML, SVG, etc.
    • Re:XHTML and XML?? (Score:2, Informative)

      by gregarican ( 694358 )
      XML is a data definition language. XHTML is not.
    • Re:XHTML and XML?? (Score:5, Informative)

      by typhoonius ( 611834 ) on Friday July 23, 2004 @02:26PM (#9781929)

      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?? (Score:3, Informative)

      by volteface ( 798935 )
      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?? (Score:5, Informative)

      by Kentamanos ( 320208 ) on Friday July 23, 2004 @02:28PM (#9781958)
      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 :)).
    • Re:XHTML and XML?? (Score:5, Informative)

      by JeanPaulBob ( 585149 ) on Friday July 23, 2004 @03:37PM (#9782757)
      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:

      <street>Mulholland Dr.</street>
      info for another person

      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.
  • by Dozix007 ( 690662 ) on Friday July 23, 2004 @02:19PM (#9781858)
    You have to wonder if Microsoft will be implimenting this new standard in IE. I have done some webdevelopment and have really noticed that they rarely impliment any of the standards in there browser. Not to mention that they are on the board that approves these standards :P
    • by RickL ( 64901 ) *
      The implementation issues primarily affect the generation of XHTML rather than displaying it. As long as IE or any other browser doesn't choke on things like '<br />', they won't have any problems. Because the rules of XHTML are so strict, parsing is greatly simplified.

      Now, the question is will Microsoft's various tools that generate HTML be able to generate valid XHTML. Considering the quality of HTML that Microsoft Word generates, I suspect it will have trouble meeting *any* standard.
  • on slashdot? (Score:5, Insightful)

    by einstein ( 10761 ) on Friday July 23, 2004 @02:21PM (#9781870) Homepage Journal
    anyone else amused that this article was posted on slashdot? a site who's HTML is so bad they've blocked validator? I'm amused.
    • Re:on slashdot? (Score:5, Insightful)

      by LincolnQ ( 648660 ) on Friday July 23, 2004 @02:28PM (#9781960)
      Yes. It is starting to really bug me. They could save a lot of bandwidth [] and make their page far more viewable with stylesheets if they moved the code into proper CSS and XHTML.

      • Re:on slashdot? (Score:5, Informative)

        by MP3Chuck ( 652277 ) on Friday July 23, 2004 @02:38PM (#9782067) Homepage Journal
        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? (Score:3, Insightful)

          by Saeger ( 456549 )
          * Savings per day with caching the CSS files: ~14 GB bandwidth

          Sure, that's a lot of bandwidth, but not in dollar terms.

          Large sites pay less than a dollar per gigabyte xfer'd. So, /. would save less than 5 grand per year. That's a lot of money to me and you, but maybe not to the guy(s) who don't want to overhaul a big site that's "not broken".


          • Re:on slashdot? (Score:5, Insightful)

            by liquidsin ( 398151 ) on Friday July 23, 2004 @03:08PM (#9782407) Homepage
            The "editors" here are supposed to be geeks. Every geek I know is all about doing their preferred geeky thing in the most efficient way possible. You'd think they'd want to do it just to say "yeah, we rewrote the site and saved 14GB of transfer PER DAY". Not only does it save them money, it saves the users load times. Besides, it's not like they have any actual editing to do.
            • Efficiencies (Score:3, Interesting)

              doing their preferred geeky thing in the most efficient way possible

              Now maybe your preferred geeky thing is minimizing bandwidth over the short term.

              And maybe others' geeky things include minimizing over a longer term.

              I could spend $10K in time to save $5K/year in expenses, or $10K on some other effort that will have a better long term payoff.

              The "editors" here ARE in fact geeks, and they know what they are doing behind the scenes, which you do not. Maybe you should assume they have some idea of what
        • Re:on slashdot? (Score:4, Insightful)

          by jCaT ( 1320 ) on Friday July 23, 2004 @03:05PM (#9782379)
          14gb * 30 days = 420gb, which equates to about 1.5mbit sustained per month. With what slashdot is paying for bandwidth, that SHOULD be about $150 a month. Not exactly an amazing drop for them in price. It's not hard to see why they haven't bothered.

          However, It sounds like are working on getting slashdot to be more standards compliant. []

      • Re:on slashdot? (Score:4, Informative)

        by blanks ( 108019 ) on Friday July 23, 2004 @04:27PM (#9783462) Homepage Journal
        Its been done Its happening now shtml?tid=4&tid=24&tid=28 Big update in next few months in the cvs 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.
  • Funny quote (Score:5, Informative)

    by slashdevslashtty ( 712925 ) <> on Friday July 23, 2004 @02:21PM (#9781871)
    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 (Score:4, Informative)

      by JamesKPolk ( 13313 ) on Friday July 23, 2004 @04:27PM (#9783471) Homepage
      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.
  • by gnuman99 ( 746007 ) on Friday July 23, 2004 @02:21PM (#9781882)
    Maybe we should use XHTML because HTML is ancient and broken? Furtheremore, CSS must be pushed to replace most of the format specifications. XHTML+CSS actually simplify the rules by which browsers format text.
    • No, XHMTL is broken (Score:3, Interesting)

      by AuMatar ( 183847 )
      You forget the original purpose of HTML. HTML's purpose, and the reason it grew so quikly, was to be an easily understood markup language that could be used by less technical people. The reason so many people were able to make their own homepages and grow the web like they did was that HTML could be easily learned.

      Now we have XHTML and CSS. Neither of these are easy to learn. Neither of them is easy to use. Less technical people are incapable of using either. This is great for job security for webmas
      • Actually, Berners-Lee has been quoted as saying he never imagined people would hand-write HTML, but that people would use HTML editors. Unfortunately, Berners-Lee didn't foresee the horrible mess than most HTML editors (hello, FrontPage, you bastard child, I'm talking to you!) would produce. Blech.

        Am I the only one who can see value in an HTML '5' that would clean up the problems with HTML 4.01, and add some easy-to-use ideas from CSS?
        • by AuMatar ( 183847 )
          He also didn't forsee the rise of blogs, forums, etc. I write more html for forum and blog posts than I do for websites. Sometimes quite complicated html for tables. I suppose I could use an editor, save the file, open it in a text editor, and paste the result in the form, but that seems like more work than just writing the html in most cases.
      • by T-Ranger ( 10520 ) <> on Friday July 23, 2004 @03:09PM (#9782436) Homepage
        I dont know that that was HTMLs purpose. I keep hearing people say that, and it being "easy" may be true, but I dont know that that was its goal.

        HTML is NOT easy. Writing a valid HTML documenta 20-30 lines long by hand is possible, but for any non-trivial page it is near impossible. (that there are no good HTML editors is besides the point). Any website containing more then 1 page should use some kind of automation to create HTML, be that continiously generated dynamic pages, or generating the HTML once per change. Spreading the rumor that HTML is easy to learn and that anyone can, and should, use HTML is a disservice to humanity.

        If you are a non-technical person, or even a technical person whose job is not specificly HTML creation software writing, then you should not generate HTML by hand. Use some kind of CMS. Use some HTML editor. Use Docbook and "compile" HTML.

        Why are Wiki's popular? Because they use a markup language that actually is easy, one that is hard to screw up.

        Please, pleae, please, dont continue to spread the lie that HTML is easy enough for anyone to learn.

      • by Lethyos ( 408045 )

        Now we have XHTML and CSS. Neither of these are easy to learn.

        We also have C, Perl, Fortran, Lisp, and so on and so on and so on... and they are all difficult to use. You actually have to sit down, open a book, read, learn, and think. Can somebody tell me why XHTML should be anything different?

        First of all, XHTML is easily recognizable to anyone who knows HTML. I don't know where you get off saying it's harder than HTML. As for CSS, it's a hell of a lot easier than messing with tens if not hundreds

  • by Defiler ( 1693 ) * on Friday July 23, 2004 @02:22PM (#9781888)
    I've been using XHTML for some time, but only in the modes that safely fall back to HTML for browsers that don't "speak" XHTML.
    I have to wonder if 2.0 is going to catch on. Internet Explorer isn't likely to support it any time soon, and nobody wants to code two versions of every web application.
    Still, good FAQ on that site. I learned some details that had been hazy.
  • Mozilla composer (Score:4, Insightful)

    by Danathar ( 267989 ) on Friday July 23, 2004 @02:23PM (#9781901) Journal
    It would be nice if Mozilla composer could save in XHTML....I'd gladly use it if more editors would save in XHTML format.
  • by pohl ( 872 ) on Friday July 23, 2004 @02:24PM (#9781904) Homepage
    With all the time we spend hearing about alternatives to IE around here, you would think that slashdot would be compliant to at least some W3C standard. If /. were some tiny hobby weblog this would be forgivable, but /. could use the size of it's audience to actually lead. Why not do it?
    • 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
  • by ( 562495 ) on Friday July 23, 2004 @02:24PM (#9781910) Homepage
    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.
    • by JimDabell ( 42870 ) on Friday July 23, 2004 @02:34PM (#9782020) Homepage

      Something better would be to use pure XML for creating content and then let the browser apply a CSS to present the content.

      No, that would be very much worse. The whole point of a publically specified XML application like XHTML is that everybody understand what the element types mean. If you go around inventing your own element types, nobody will no what you mean. Google understands <h1> as being more important than normal text. It won't understand <my-fancy-heading> in the same way.

    • Its a good thing for giant websites and businesses. Its needlessly complex for small websites. And its something that non-technical people won't understand at all. As I posted in another thread- the point of HTML was to be an easy to use markup language for the masses, so anyone could make a webpage. XHTML is beyond most non-programmer's capabilities.
      • by Stuart Gibson ( 544632 ) on Friday July 23, 2004 @03:04PM (#9782377) Homepage
        OK, I'm sure you're trolling, but how is XHTML any harder to understand than HTML 4?

        Since they use practically identical tags and are structured in the same way, a well written (ie compliant) HTML 4 page will comply to XHTML with a change of doctype and a few minor tweaks (<br> to <br /> etc).

        Anyone who is in any way competent with HTML can switch to XHTML with no problem. In fact, for less technical people, XHTML will be easier to understand as the reams of presentation code will have been shifted to the CSS file, making the underlying (X)HTML easier to read and understand document structure.

        If I'm completely off base about where you're coming from, please enlighten me.

    • Even though this site doesn't use XHTML 2.0, it does show the importance, and the amazing things that can be done when content and presentation have properly been seperated.
      CSS Zen Garden [] ... if you haven't seen it, check it out!!
  • So Slow ... (Score:3, Interesting)

    by johnhennessy ( 94737 ) on Friday July 23, 2004 @02:24PM (#9781917)
    (Before I'm completely slaughtered for complaining about performance, a disclaimer: I haven't done strict benchmarks)

    Is it my imagination or are XSLT transforms very slow. I know this will depend on what engine you use to transform, but during the course of designing a website for a friend I tried several Java based transforms to go from XML to an XHTML page.

    Why are these operations so slow - I thought XML (and therefore XHTML) was supposed to be straight forward and easy to parse.

    In my limited experience XHTMLs benefits seem to be "weakened" by parsers/transformers that are still a bit away from maturity (speed-wise).

    (Hint: if anyone knows a lean, mean transformer nows the time...)
    • by laird ( 2705 ) <lairdp@gmai[ ]om ['l.c' in gap]> on Friday July 23, 2004 @02:34PM (#9782028) Journal
      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.
      • by Kentamanos ( 320208 ) on Friday July 23, 2004 @02:39PM (#9782070)
        You guys are both essentially complaining about the speed of XSLT transforms. While XHTML makes "HTML" a valid XSLT target target document (in other words, it makes HTML XML compliant), nobody is forcing you to use XSLT.

        XHTML is still completely valid on its own. It's a HELL of a lot easier to validate for one thing. Ever looked at the sourcecode to HTML validators?
      • As the other poster said, your complaint mostly applies to the XSLT transform engines.

        But keep in mind that the industry heavyweights who back these standards are all in the business of selling you hardware.

        IBM, Sun, etc see a slow app as an opportunity to sell computers. If you can lower the cost to produce applications significantly by using XML, you can afford to buy more computers from IBM, HP, Dell, Sunc, etc.
    • MSXML is fast!

      If that isn't suitable for religious, other reasons, then I believe that Saxon is now fairly fast provided you can keep it in memory; being Java based, start up times can be a bit pants.

      Beyond that, you might need to take care with how you write you XSL as this can impact performance, and also your XSLT transformer might provide a way to store "compiled" XSLT's (MSXML does).
  • I dont know... (Score:3, Interesting)

    by boomgopher ( 627124 ) on Friday July 23, 2004 @02:25PM (#9781925) Journal
    I dif XML and all, but things like replacing <img> tags with stuff like:

    <p src="map.png"><span src="map.gif">Exit from station...</span></p>

    seems a bit too... anal? or purist/academic at best.

    I suppose it's a moot point if MS/Macromedia/Adobe comes out with a great XHTML2.0 WYSIWYG editor, then 95% of the developers out there wouldn't even care...

    • The IMG tag is perfectly acceptable [] in XHTML.
    • Re:I dont know... (Score:2, Insightful)

      by renderhead ( 206057 )
      This is only a problem for pre-existing code and for people who already know HTML. If I were teaching a brand new user to write markup, this method makes just as much sense as the img tag, if not more.

      I've given people introductory "crash courses" in HTML before, and they often go something like this: "A tag is used to format content. Except for the img tag. That one IS content. And you should always close your tags. Except the img tag. It stands alone because it's an object not a formatting tag."

      Not terr
    • The examples you gave are not equivalent. The equivalent of:
      <img src="foo.png" alt="foo" />
      <p src="foo.png">foo</p>

      The complicated example you gave is merely an example of how you can provide multiple fallbacks.

    • The history of IMG (Score:3, Interesting)

      by Nurgled ( 63197 )

      Now that every browser anyone would dream of using supports IMG in some form, even if it's just replacing the element with the contents of the ALT element, it's easy to forget about its heritage and not correctly shame the creators of this, one-broken-always-broken element.

      IMG was added to Mosaic back in the day, and after it was implemented it was submitted for peer review. The "peers" correctly noted that the use of an 'alt' attribute to handle browsers which cannot display the image is inadequate becaus

  • Standards work now (Score:3, Insightful)

    by cubicledrone ( 681598 ) on Friday July 23, 2004 @02:26PM (#9781935)
    The reason most HTML is not valid is because browsers have generally not supported CSS completely, which makes it necessary to replace DIVs with tables, add huge browser functions to Javascripts, etc.

    Now, Safari, Mozilla and Opera support about 98% of CSS-1 and parts of CSS-2, so it becomes possible to actually develop a working web site without spending 10 hours of testing and debugging (yes, debugging HTML) for every one hour of actual development.
    • It'd help if the CSS box model wasn't almost totally useless and broken, too. To say nothing of it's support on browsers (ie, minimal and varying between implementations), which makes it even more useless in reality than it is in theory.
  • It's always the way. (Score:5, Informative)

    by caluml ( 551744 ) <slashdot@spamgoe ... minus poet> on Friday July 23, 2004 @02:28PM (#9781969) Homepage
    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"
    " al.dtd">
    <html xmlns="">

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

    <stylesheet version="1.0"
    &am p;n bsp; <template match="/">
    <copy-of select="."/>

    Note that this file must be on the same site as the document referring to it.
    • Not wishing to defend MS in anyway [and suffer the Wrath Of /.] but although I find it a total PITA making websites work with the various vintages of MSIE, IE6 isn't too bad..... I'm not saying its good, and obviously it *should* be much better, but even if MS had continued browser development and created a 100% CSS1, CSS2 and XHTML 1.x compliant IE7, we'd *still* have people running older versions so we'd *still* have to code websites to work with those versions.

      The thing that I find takes the most time
  • Ugh (Score:2, Insightful)

    by jandrese ( 485 ) *
    Man, do you remember when writing a webpage by hand was easy? Back in 1996 or so when just about anybody with a text editor and a link to that excellent Netscape HTML manual [] could write a decent page without spending hours poring over obtuse documentation []?

    Now you have to figure out what Doctype to set, learn CSS, enter some sort of weird workaround for IE, etc... Worse, HTML used to be fairly forgiving for the author so Newbies could get a decent page without spending hours and hours trying to figure out
    • Re:Ugh (Score:3, Insightful)

      by Ambrose ( 16701 )
      It is because HTML is so lax that we have the browser support nightmare we're in today. I would trade making it harder for the average newb to make a web page for consistent (or at least predictable) rendering across browsers.

      Not to mention accessibility. The vast majority of sites out there are all but completely useless to the blind, or those who require very large print, or who are browsing on PDAs, cellphones, or other small devices.

      The new standards are a Good Thing, and if that means gramma can't
      • Re:Ugh (Score:3, Insightful)

        by jandrese ( 485 ) *
        My big point was that the original web standards were pretty egalitarian, with just about anybody with a good (or not so good idea) able to toss up a halfway decent looking page. Nowadays the standards are becoming rather elitist, and unless you're already a master of XML and know the W3C's technical jargon well enough to read their documentation, you stand little chance of just picking up XHTML from reading the documentation.

        I know the pages won't be very accessable, but the kind of people who need th
    • Re:Ugh (Score:4, Insightful)

      by JohnnyCannuk ( 19863 ) on Friday July 23, 2004 @02:40PM (#9782088)
      Do you remember that web pages in 1996 look like shit?

      Do remember that web development these days cannot rely on simple static text?

      Do you realize that with HTML/XHTML editing tools around these days, it doesn't matter?

      Right tool for the job, my friend. A text editor is for writing static text. HTML/XHTML tools are used for making web pages and interfaces.

      Just because there's "doc types and CSS" out there doesn't mean you have to use them - go ahead and write crappy looking pages in notepad, just becasue you can. But if you are going to do proper, standard, stylish web development that is a good experience for the user, you may need to know some of this stuff.

      Clearly you aren't a web developer.

      • Oh, pu-lease! (Score:3, Insightful)

        by Goldenhawk ( 242867 )
        • Do you remember that web pages in 1996 look like shit?

          Do remember that web development these days cannot rely on simple static text?

          Do you realize that with HTML/XHTML editing tools around these days, it doesn't matter?

          Right tool for the job, my friend. A text editor is for writing static text. HTML/XHTML tools are used for making web pages and interfaces.

        Oh please.

        Do I remember? Yeah, I've been coding HTML by hand since 1995, and my pages looked pretty messy back then. But it wasn't the HTML -

      • Re:Ugh (Score:4, Insightful)

        by trisweb ( 690296 ) on Friday July 23, 2004 @03:42PM (#9782820) Journal

        Clearly you aren't a web developer.

        Most of the web developers I know (and I know a lot) started out using tools like Dreamweaver and GoLive etc, which now output decent XHTML, but now they are starting to move toward XHTML and CSS in their designs (which are some [] of [] the [] best [] on the net, might I add), and they're switching to using text editors exclusively for writing the code, plus your standard graphics programs for the images. I do the same.

        The great thing about XHTML is that is separates the content from the design, which in turn makes your code beautiful and easy to write and maintain. I was looking at an XHTML page I had written the other day, and I thought, gee, I could just put this up as plain text and people would still understand it. It was free of all that contextual crap (tables, font tags, one-pixel spacer images) that heavily-designed HTML pages of two years ago were full of. So no, a text editor is not just for writing static text. I use mine for every aspect of the design process, though, admittedly ConTEXT [] is not notepad, it's pretty close. And I would contest that the sites I develop aren't crappy looking.

        You may be able to design sites with a tailored WYSIWYG HTML editor, but you usally have little control over how everything fits together, and it results in messy code that is hard to understand. If that works for you, then fine, great. All I can say is that you better "know some of this stuff" and how to do it without your XHTML editor -- learn it in notepad -- and then, once you see what was output by your editor, and if you have any respect for the XHTML standard and the ideals that the W3C had in mind when they thought of it, I have a feeling you won't go back.

    • Re:Ugh (Score:3, Insightful)

      by BlaKnail ( 545030 )
      "Worse, HTML used to be fairly forgiving for the author so Newbies could get a decent page without spending hours and hours trying to figure out why their page is coming up blank or trying to figure out why the validator is complaining at them."

      HTML being forgiving is a bad thing. Sure, it's easier for the average person to crank out a homepage, but without strict standards, we ended up with a myriad of browser incompatibilities and mountains of sloppy coding that can't be parsed correctly.

      XML and XHTML
    • I learnt basic HTML in 1996 from a three-page magazine article, learnt a bit more (tables, lists, etc) from an NCSA tutorial, that's all I use nowadays. I'm not going to bother learning any of these new-fangled standards until the average browser won't support HTML 3.
    • Re:Ugh (Score:4, Interesting)

      by Kentamanos ( 320208 ) on Friday July 23, 2004 @02:42PM (#9782121)
      I would argue learning XHTML is easier than HTML since the rules are a LOT more straightforward.
  • 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

    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 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 separ

    • "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
  • by kindbud ( 90044 ) on Friday July 23, 2004 @02:33PM (#9782016) Homepage
    Meaning it is to be used for document structuring which is why it does not have presentation elements.

    That's what they said about HTML in 1992. Look what happened to it when it got popular: bastardized so badly with presentation elements that it lost almost all of its structuring features. Remember <fig>? It was obsoleted before it even made it out of draft status because commercial browser vendors (*cough* Netscape *cough*) pushed <img align> on everyone instead, because it was quick and easy. That's just one example. Who's to say this new XHTML won't be spoiled the same way? We could say "Use HTML if precise control over layout is needed" but back in the HTML days, we were saying "use PDF if precise control is needed" and we were ignored, and HTML was destroyed so badly that XHTML is now needed to fill the role HTML had to abandon.

    What's to prevent lather/rinse/repeat?
    • We've now come full circle. First there was SGML, which is a "general purpose markup language for representing documents". Then HTML. Then XML. Now, XHTML, which is a "general purpose markup language for representing documents". What's wrong with this picture.

      "Structured documents" for public distribution usually don't work. The problem is that the costs of tagging are incurred by different people than those who benefit from it. Unless you have some enforcement agency that makes people tag their data

  • by beejay54 ( 781673 ) on Friday July 23, 2004 @02:41PM (#9782100) Homepage
    I think that so long as the WYSIWYG community keeps implementing these standards into their applications, web developers will follow suit. The latest version of Dreamweaver codes excellent XHTML and almost forces designers/developers to use CSS to incorperate presentation elements out of the box. For those who code 100% manually XHTML is an easy thing to tackle. The big issue it seems is that, like many web developers out there, I am getting quite sick of the frustration in multiple browser support. While it may be the most popular browser, IE is quite possibly one of the worst for supporting standards. I don't mind Microsoft trying to develop their own web standards so long as they are 'implementable' in other browsers/systems, but that never happens.
  • by JimDabell ( 42870 ) on Friday July 23, 2004 @02:42PM (#9782112) Homepage

    The only version of XHTML that is suitable for transmission as text/html is XHTML 1.0 following Appendix C. XHTML transmitted in this fashion doesn't have any of the benefits of mixed namespaces, stricter parsing, etc.

    You get these benefits when you serve XHTML as application/xhtml+xml, and your visitors use browsers that support those features (such visitors are extremely rare - SVG isn't even in main Mozilla builds yet). But many legacy user-agents require text/html. Search engines would probably be the most important ones.

    So unless you are willing to set up content-negotiation, sending different document types to different browsers, and unless you have a niche market that use browsers that understand these new features, you really aren't going to get anything from XHTML. Not for a few years, anyway.

  • Sending XHTML as text/html Considered Harmful []

    Besides which, XHTML 1.1 and 2.0 aren't even vaguely backward-compatible.

  • by hey ( 83763 ) on Friday July 23, 2004 @02:47PM (#9782179) Journal
    Regular HTML:

    <img src=logo.gif width=10 height=10>


    <img src="logo.gif" width="10" height="10">

    I hate those extra quotes. Why is this progress!?

  • I've been "coding" to XHTML transitional for a few years now, and have noticed recently that a lot of the sites being created or redesigned now are also opting for it rather than the old HTML401.

    There's really not much to it:

    • All tags are lowercase, which is easier to type anyway
    • All attributes have to be "quoted" for sanity
    • All tags have to be terminated, like this lists </li> which makes the browsers job of rendering much easier since it doesn't have to play the guessing game. This is especially handy on lowend devices like PDAs.
    • All the old bandwidth-wasting presentation elements (like <FONT>) are now CSS presentation ATTRIBUTES of any element by using id= class= and style=

    Firefox's WebDeveloper extension [] makes XHTML/CSS validation (among other funcs) so easy that there's no excuse to be lazy about it.


  • by orthogonal ( 588627 ) on Friday July 23, 2004 @02:58PM (#9782313) Journal
    Also they have a FAQ about why you should use XHTML over HTML.
    Meaning it is to be used for document structuring which is why it does not have presentation elements.

    What! No <blink> tag?? No

    No way I using it!11!1 I'm a serious web designer!

    (This comment looks best at 717x913 resolution, using Internet Explorer for the security holes and that essential <marquee> tag. Page designed in Microsoft Word, because that HTML stuff makes my head swim. Enhanced with buggy JavaScript we stole off some Russian porn site, to resize your browser window, make its controls inaccessible, ensure the "security" of our images by disabling right-click, and to reject any browsers other than Netscape 4.72 and IE 5.5. Please bookmark this comment and come back when we've made the entire comment one big Flash animation completely inaccessible to anyone not running Flash or running Flash but on dial-up. PS: we appreciate your business.)
  • by Llevar ( 788850 ) on Friday July 23, 2004 @03:18PM (#9782535)

    HTML versus XML and the related set of schemas, including XHTML, can be compared to building with Lego versus real construction materials. HTML comes out of the realm of the old web where everyone and their uncle can be a so-called "web designer", a title anyone in the industry knows to actually refer to a graphic artist who draws buttons and banners. Coding in HTML revolves around nudging table cells by a few pixels this way or that way and hoping that all falls in place on that old piece of crap browser that half of the customers of your company are still using for some reason. HTML can be written by a 5-year-old. Some see this as an advantage, those who use it professionally can't see it as anything but a shame. I've known my fair share of web developers, being one myself, and the number of them who know anyhing about actual software development is probably less than one percent of the total.

    XML, and all the web-related schemas and standards like XHTML, on the other hand, provide you with an ability to present very complex business domains over the internet. Anyone wno knows anything about programming will say that jumbling all your data, along with it's structure, along with it's presentation is a terrible way to write software. The new standards allow one to keep data separate (XML), structure separate (XHTML), and presentation separate (CSS). While it's admittedly more complex than the regular HTML it lets you do so much more with your data. Switch stylesheets and bam, your site looks completely different. Switch XSL stylesheets and you can serve the same data in completely different ways on a PC, a PDA, or a mobile phone.

    Lastly I want to bring up that web clients are often used as front ends for company intranets and while it's going to be a while until web developers (and consumers!!!) will be able to enjoy the benefits of the move to XML on www those benefits can already be reaped in the controlled environment of your company intranet.

  • Displaying XHTML (Score:3, Interesting)

    by Brian Blessed ( 258910 ) on Friday July 23, 2004 @03:25PM (#9782630)
    Does anyone know if this revision will specify more precisely how it should be displayed by a web browser?

    The problem I've found with fully using XHTML+CSS for web pages is that it is not possible to layout pages that will scale accurately as the font size is increased. So much for accessibility!

    I wonder why it was decided that it would be useful for text that doesn't fit, to run-over other text and elements on the same page.
    It would be better if we could tell the browser that when elements expand the other parts of the page must move out of the way.

    - Brian.
  • (Score:4, Informative)

    by mishan ( 146987 ) on Friday July 23, 2004 @03:58PM (#9783034) Homepage
    I don't know about you guys, but my pages are already written in XHTML 1.0 and, thanks to, all I need to get my pages up to the XHTML 2.0 spec is a newer version of which would be provided through a newer Perl distribution.

    Ah portability..
  • Tranesterification (Score:4, Insightful)

    by Graymalkin ( 13732 ) * on Friday July 23, 2004 @04:07PM (#9783165)
    One huge problem I've encountered trying to switch pages from HTML 4.01 to XHTML is more established engines tend to hail from the HTML 3.2 days (Slashcode) and have not evolved much since. Forum software is often the worst in my experience, everything is littered with tables and fixed size elements. A lot of people host their sites on vhosts and many of those don't support things like HTML::Template, Mason, or Smarty. As such most coders just write their own template system which may or may not handle newer web standards.

    Since many sites are using crappy HTML they want to spice up they tend to use equally crappy JavaScript to add little stylistic features. I think many people are surprised when they hit up a CSS tutorial and figure out they can replace their stylistic JavaScript with CSS and have much better performing web pages.

    I'd love to see more sites using XHTML, even transitional XHTML, with CSS for styling and layout purposes. Documents end up much more flexible and quite a bit smaller. It is also easier for end users to override the page's CSS with their own to either make elements more legible or friendlier for their output device (PDA, cell phone, screen reader).

    Coders of CMS engines: Please use sane template systems so it is easier for your poor end users to make their pages better comply with web standards. Also don't wrap stuff in tables, not everyone uses tables to lay out their pages! Presentation logic is fine and dandy but don't hard code layout elements, let the users decide! Thank You.
  • by Frobozz0 ( 247160 ) on Friday July 23, 2004 @04:31PM (#9783522)
    As much as I like the work of W3C, it's as if they are stuck in a time warp where they could actually effect development patterns. It's not 1994 any more, and there's so much existing infrastructure in HTML 4.0 (or similar) code and horrible Ineternet Explorer interpretation of that code that little will happen for YEARS. The lead time on their final specifications are probably at 5 or 6 years now.

    Don't get me wrong-- they're doing the right thing, but it's as if they could shout at the top of their lungs that MathML and SVG should be standard and no one will care. Oh wait, nobody does. How many browsers support either "out of the box?" If you were to add up their market share it would be in the single digits.

    It's time we just realize, as web developers and designers, that we are stuck with a horribly inefficient means to share information that is worsened by the lackluster industry movement required for change in the way we get at that information.

    I'd say this is a new thing, but it's not. Look at any industry and the same thing always occurs.

"I don't believe in sweeping social change being manifested by one person, unless he has an atomic weapon." -- Howard Chaykin