Forgot your password?
typodupeerror
Programming The Internet IT Technology

Why You Should Use XHTML 657

Posted by michael
from the life-not-complicated-enough-apparently dept.
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 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 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.
  • 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?
  • 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...)
  • 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...

  • Re:XHTML and XML?? (Score:5, Interesting)

    by pete-classic (75983) <hutnick@gmail.com> on Friday July 23, 2004 @02:32PM (#9782002) Homepage Journal
    Good answer ;-)

    The grandparent might also interested in the following:

    XHTML is implemented in XML. So XHTML is to XML as OpenOffice.org's writer format is to XML. (Or as HTML is to SGML, or as this post is to English.)

    People often say somthing is XML when it is really implemented in XML. Using that (misleading) terminology XHTML is XML.

    -Peter
  • 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.

  • No, XHMTL is broken (Score:3, Interesting)

    by AuMatar (183847) on Friday July 23, 2004 @02:35PM (#9782037)
    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 webmasters, but for the growtrh of the next and for the internet as a medium of free and easy communication its horrible. XHTML is broken as an HTML replacesment because it does not meet the original purpose of HTML- to be something that anyone can easily learn and use.
  • 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.
  • by Saeger (456549) <`farrellj' `at' `gmail.com'> on Friday July 23, 2004 @02:49PM (#9782197) Homepage
    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 [mozdev.org] makes XHTML/CSS validation (among other funcs) so easy that there's no excuse to be lazy about it.

    --

  • by RickL (64901) * on Friday July 23, 2004 @02:56PM (#9782288) Journal
    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.
  • by AuMatar (183847) on Friday July 23, 2004 @03:00PM (#9782330)
    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.
  • Re:XHTML and XML?? (Score:2, Interesting)

    by skamp (559446) on Friday July 23, 2004 @03:07PM (#9782399)
    Writing something that parses XHTML is a LOT simpler than writing something that parses HTML.

    How do you know that? Did you actually write both an HTML and an XHTML parser? While I didn't, I would also instinctively think that parsing a stricter language would be easier; but David Hyatt [mozillazine.org], however, who worked on Mozilla and now works on Safari, seems to think otherwise [mozillazine.org]:

    Every modern browser, including Mozilla and Safari, is much worse at XHTML than at HTML. People tend to foolishly gloss over the transition from one to the other, thinking that code you write for one will "just work" when you switch to XHTML. That simply isn't true. If you look at XHTML in both Mozilla and Safari and compare it to HTML, you'll see that it's slower, non-incremental, and generally buggier than HTML.
  • by T-Ranger (10520) <[jeffw] [at] [chebucto.ns.ca]> 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.

  • Efficiencies (Score:3, Interesting)

    by A nonymous Coward (7548) * on Friday July 23, 2004 @03:18PM (#9782532)
    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 they are doing, and that as you have said, since they have little actual editing to do, maybe, just maybe, they actually do some geeky things that you know nothing of.
  • 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.
  • Re:XHTML and XML?? (Score:1, Interesting)

    by yintercept (517362) on Friday July 23, 2004 @03:33PM (#9782718) Homepage Journal
    I will be checking out the new specs.

    One of my greatest dislikes of all of the new X-Style languages is that they all seem aimed to cutting human beings out of the web equation. The original HTML is sloppy, but most people can get a decent looking page by typing out code in a text editor or in a little tiny textarea box on a forum.

    The different HTML-Strict DTDs are nit-picking to the point that they preclude humans from writing code. For example, you have to replace all of the ampersands in a URL with an ampersand followed by "amp;". They've eleminated monoid tags; so you have to end img, meta and br tags with a "/". Each nit-picking details decrases the ability for ma and pa kettle to pound out their own web page.

    To a large extent it appears that the primary goal of the W3C is to force the market into the position where people have to buy expensive programming languages to write HTML.

    Personally, I like humans more than machines. I agree with the majority of web pages on the net that we should resist the W3C.
  • Re:Ugh (Score:4, Interesting)

    by kirkjobsluder (520465) <kirk@jobslMENCKENuder.net minus author> on Friday July 23, 2004 @03:59PM (#9783039) Homepage
    Gee, am I the only one who has been writing xhtml in vim for a while now?

    It's not that hard to do.

    1: add the doctype at the top.
    2: always close your tags.
    3: check you work with a validator.

    html tidy will also identify and clean up any mistakes.
  • by trisweb (690296) on Friday July 23, 2004 @04:12PM (#9783235) Journal
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd ">
    <html><head><title>Hello World</title></head>
    <body>
    <h1>'hello world'</h1>
    </body>
    </html>

    Know any other programming languages that can do a completely understandable and arguably human readable 'hello world' like that? Yeah, I know there are probably a few. But that's not hard, man, I'm sorry. The doctype tag is the hardest part. Try searching for 'xhtml doctype' on google and copy-paste. Not hard.

    If you know anything about software development, you'll no doubt be familiar with the idea of abstraction. You know, splitting a complex or redundant thing into parts to better understand it and make it simpler (loosely defined, anyway). XHTML does exactly the same thing. It abstracts the Content away from the Structure away from the Design. It takes away all the crap that existed in HTML4 pages from all those being mashed together, making XHTML far more readable and easier to code. If you can't see that, then you've never actually tried coding a bit of XHTML.

    "Writing out XHTML by hand is going to be a pain, even for very simple content." -- I responded to something like this earlier, but I'll say it again -- people coding XHTML are throwing away the old WYSIWYG editors in favor of a better program -- a simple text editor. XHTML is so easy to code by hand that you don't even need a program to help you do it. Any old text editor will do. Just shows again, you've never actually had experience coding XHTML. The web is moving in this direction. If you're not going with it, then stop holding it back by saying unfounded things like this.

  • by subVorkian (138658) on Friday July 23, 2004 @04:16PM (#9783312) Homepage

    The XHTML spec is far more complicated than HTML was.

    Far more complicated? I don't agree. The benefits you gain from a tighter spec are well worth the trouble of adapting to the new technology.

    For instance, changing a style within a single file and watching those changes cascade effortlessly through the site is much more elegant than the old ways. This makes updating your site easier and may actually increase adoption by mom and pop.

    I think if people see the benefits, they will invest a little energy in learning new tech.

  • Re:XHTML and XML?? (Score:4, Interesting)

    by Christianfreak (100697) on Friday July 23, 2004 @04:26PM (#9783457) Homepage Journal
    You're kidding right?

    First off, Ma and Pa Kettle haven't cranked out their own web page in notepad since about '97 or so. Nowadays they use FrontPage for that which produces something akin to code soup.

    Secondly I don't understand why new syntax precludes anyone. Learning new things is not difficult. I write valid XHTML 1 code by hand, it isn't very hard, in fact its much easier to control the elements than it used to be, and produce nice looking sites that downgrade nicely for people using broken (IE) browsers.

    It makes everyone's life easier if there is a standard that is followed. You don't expect a programming language to know what to do with invalid syntax do you? Why should your data language be any different?
  • by Anonymous Coward on Friday July 23, 2004 @04:30PM (#9783503)
    It's horribly painful to create a decent layout using strict XHTML and CSS. You can make some nice-looking things after a bit of work, such as the samples at CSS Zen Garden [csszengarden.com]. However, try looking at the CSS file for any of the nicer designs. They appear to be completely hacked together! Separating the CSS stylesheets from the XHTML source makes them even harder to understand, since you can't figure out which element has which id/class and what order the elements come in.

    For 99% of site designs, tables work perfectly well. You want some header accross the top, a sidebar with links on the left, perhaps another sidebar on the right, then some content and a footer that spans the bottom. It's very natural to perform a layout using rectangular blocks. If you look at any print publication, it's probably also laid out using blocks.

    When you're making a website, one of your main goals is to make it look good. If you just wanted to give the user annotated data, you could just give them a plain XML file.
  • 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.

  • Re:XHTML and XML?? (Score:3, Interesting)

    by DeComposer (551766) on Friday July 23, 2004 @04:48PM (#9783744) Journal
    First of all, I'm of the very-supportable impression that standards are a good thing. Few things in web design are quite as annoying as having to detect and code for different browsers.

    Second, I think we can all agree that--despite the "L" in XML and XHTML that these are not programming languages but markup languages. While there are clever things that can be done to markup, especially with XSLT and XSL:FO, markup languages are not procedural--and therefore not programming lanuguages--the way C++, Basic, or JavaScript (to name a few) are.

    Third, XML and XHTML, especially when used in conjunction with XSLT and XSL:FO, are vastly more versatile than HTML without being much harder to write. Not being programming languages, you can even create XML/XSL/XHTML documents in any text editor and validate them for free at W3C.

    Fourth, every markup language--and every programming language--I've ever encountered has reserved characters that have to be replaced by escapes. Maybe it's just me, but I've seen more than a few instances of & n b s p ;.

    The whole point is to make web pages more friendly to their audiences and, at the end of the day, you're only going to the trouble to even create a web page so that you can reach an audience.
  • Re:XHTML and XML?? (Score:1, Interesting)

    by Anonymous Coward on Friday July 23, 2004 @06:03PM (#9784497)
    Both you and the parent poster are wrong.

    It's 2004, and we still need to look at the (X)HTML source as much as ever. Sure, if you're creating some simple static webpage, a WYSIWYG editor is fine. But for any reasonably complex, dynamic website, FrontPage/Dreamweaver/etc just aren't useful.

    However XHTML makes things better for these kinds of sites. By increasing the up-front complexity mentioned by the parent poster, you greatly reduce the effort necessary to debug a problem when things go wrong. For instance, a major headache for websites that pull html from many templates is mismatched table tags. Tracking down a missing closing table tag in code you didn't write when it could be in a dozen different template files can take forever. But with XML, you're more likely to get a meaningful error message which will point you toward the real problem.

    HTML is easy to write, hard to read. XHTML adds more structure which becomes incredibly useful as the complexity of the task increases.
  • by shift1978 (245275) on Friday July 23, 2004 @06:20PM (#9784671) Homepage
    So you say that website with tables used for design are more easy to read ? Are you sure ?
    Have you ever work on the website of another person, company, project using table for design ? It sis totally impossible to maintain it without losing much time.

    Now about the goal of a website, it is not to look good but to provide information. Now if it look beautiful too it is better. But information is the main point and accessibility - I mean information for everybody (blind persons, persons using their mobile phone,...) With tables for design accessibiliy is not possible

    Foolow this link http://www.humanfactors.com/downloads/chocolateaud io.asp and listen what a blind person can ear when a website use unecessary tables.

    Moreover XHTML is more easily readable than XHTML for web-engine. With the separation of content and design you win lot's of bandwidth. Etc.

    All my websites now use XHTML and CSS and I am very happy with this. It work perfectly and I win so much time than bfore using tables. I can change the look of all my website by changing one file. Do this with table and without server languages (PHP,ASP,...).

    XHTML rox ! CSS rox ! HTML will die slowly :)
  • by devphil (51341) on Friday July 23, 2004 @07:08PM (#9785053) Homepage


    ...there are many languages out there which follow these rules, and humans always tend to hate them.

    Why should we need a semi-colon to end a statement. The line feed should be enough. Well, that's the way it was in assembly language and shell scripting, but people bitched and moaned, and statement-separators have been a part of both kinds of language ever since.

    Why should we need a closing brace. Cannot the compier SEE that it is the end of a block simply because the indenting is different? And yet, whenever Python is suggested as a language, the usual response is some language bigotry about "the indentation nazis taking over." Heck, even Stroustrup tried a variation of C++ where the try/catch blocks didn't have to be enclosed in braces, because the "try" and the "catch" made everything redundant. The compiler was just fine with it, but the people using the language clamored for the braces to be put back.

    I'll stick to Python, but I'll let the sloppy Perl coders share the same air as me. :-)

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

    by Nurgled (63197) on Friday July 23, 2004 @08:14PM (#9785521)

    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 because pre-IMG browsers will not render it at all. In addition, it can only accept plain text and not full markup, so it is impossible to provide proper fallbacks in non-trivial cases. Sadly, the Mosaic developer responsible for IMG decided that since it had already been implemented as submitted, and Mosaic was the browser of the time, it wasn't worth the trouble to rewrite the support for this element in their tag-soup parser.

    Today we have OBJECT which works as suggested by the peer review of IMG back in the day, but IMG has become so ingrained that no-one can feasibly use it. OBJECT is clearly a superior solution, supporting all kinds of object and providing multi-tiered fallback simply by nesting OBJECT elements within each other and finally nesting other elements such as IMG.

    I'm not so sure that I agree with this new "everything is potentially an image" idea, though. It seems nice in theory, but just that example of a SPAN element inside a P element shows that it's all just an awful hack. It's a good start, but it seems like they didn't really think it through properly.

The most important early product on the way to developing a good product is an imperfect version.

Working...