Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×

HTML to be 'Incrementally Evolved' 359

MrDrBob writes "It has been decided that HTML is going to be incrementally updated, as the W3C believe that their efforts with XHTML are going unnoticed or unused by many websites out there. HTML is going to be worked on in parallel with XHTML (but with no dependencies), with the W3C trying to evolve HTML to a point where it's easier and logical for everybody to transition to XHTML. However, their work is still going to attempt to improve HTML in itself, with work on forms moving towards transitioning into XForms, but bearing in mind the work done by Webforms. In addition, the W3C's HTML validator is going to get improved, with Tim Berners-Lee wanting it to 'check (even) more stuff, be (even) more helpful, and prioritize carefully its errors, warning and mild chidings'. This looks like a nice step forward for the W3C, and will hopefully leave all the squabbling and procrastination behind."
This discussion has been archived. No new comments can be posted.

HTML to be 'Incrementally Evolved'

Comments Filter:
  • Re:Advantages? (Score:3, Informative)

    by Ford Prefect ( 8777 ) on Saturday October 28, 2006 @12:03PM (#16622700) Homepage
    To laymen like me, this sounds rather cryptic. Could any of you web gurus please elaborate, and/or list other advantages of XHTML?

    With it being XML, it's easier to read with other tools - using an XML library makes it trivially easy to write code to turn an XHTML web-page into a highly structured, tree-like associative array which contains everything the original page contains.

    In layman-speak - instead of mashing through the 'view source' equivalent (one big string), it becomes a mightily detailed tree, with every section of the page as another branch, twig or leaf. And to keep with the arboreal metaphor - when one has finished with one's web-page topiary, pruning or grafting, it's really easy to convert it back into XHTML - without losing anything in the process.

  • Re:Advantages? (Score:3, Informative)

    by metalhed77 ( 250273 ) <andrewvc@gmaCOUGARil.com minus cat> on Saturday October 28, 2006 @12:11PM (#16622768) Homepage
    The advantage of XHTML is that it's easier for machines (and developers) to process and work with after it's written. Additionally it supports emerging useful new standards such as XForms, and other XML processing tools.

    The disadvantage of XHTML is that it's harder to write initially and has stricter rules. Most people write broken HTML 4 transitional pages that, quite honestly, work fine for their audience (web only).

    Parsing HTML is a bitch, working with it is, quite simply difficult. Additionally XHTML supports embedding other XML formats than XHTML within it, like MathML (an way to display formatted math equations) SVG (XML Vector Graphics) and any other arbitrary XML based format in an easy to understand way via namespacing.

    There's a whole suite of tools built around XML (XPath and XSLT for example) that enable one to deal with MathML and SVG as easily as XHTML. It makes things simpler.

    XHTML is, however, a lot harder to write. HTML tolerates a lot of errors, XHTML technically tolerates none, though browsers usually overlook this.

    For my job, where I have to create sometimes copious amounts of HTML that will be seen only by IE or Firefox on windows or a mac, and often times be deleted within a few months, I just write HTML4 transitional and don't really worry about validating. I test both browsers and leave it at that.

    For my personal site, or shit that I have extra time to do I write XHTML because I like to make neat, clean things, but honestly there's never a tangible payoff from it for most applications.

    I will say this however, people who know XHTML are the people who know how to really write a web page. The people who've never heard of it are the ones that are a bitch to work with and slow you down with their ugly ass tag soup pages with no CSS.
  • by YA_Python_dev ( 885173 ) on Saturday October 28, 2006 @12:31PM (#16622968) Journal

    I believe that this is a response to the actions of the WHATWG (Web Hypertext Application Technology Working Group) [whatwg.org] (X)HTML 5 [whatwg.org] and to Bjoern Hoehrmann leaving the W3C QA [w3.org].

    So it's not a new pie-in-the-sky idea like XForms or XHTML2, but something much more likely to be useful to web developers that need to work in a world where IE is (still) the biggest fish.

  • by oyenstikker ( 536040 ) <[gro.enrybs] [ta] [todhsals]> on Saturday October 28, 2006 @12:38PM (#16623012) Homepage Journal
    If your web site is part of a federal contract, it has to be compliant.
    http://en.wikipedia.org/wiki/Section_508 [wikipedia.org]
  • by boywanders ( 1019526 ) on Saturday October 28, 2006 @12:48PM (#16623106)
    One of the best texts I've read on this subject can be found here... http://www.hixie.ch/advocacy/xhtml [hixie.ch]
  • by Denyer ( 717613 ) on Saturday October 28, 2006 @01:15PM (#16623368)
    Without iframes (currently supported by IE, Firefox and Opera, at least) 4.01 Strict isn't workable for most sites that rely on third-party content for advertising -- eg, ads from Amazon. And that's a large chunk of the web.
  • > Isn't XHTML suppose to be a transition path to XML?

    No, no, and still no. It is a specific application of XML.
  • by isomeme ( 177414 ) <cdberry@gmail.com> on Saturday October 28, 2006 @01:45PM (#16623582) Journal
    Small changes can be devastating. Example: why does XHTML backslashes in hr or br tags. These are completely unnecessary requirements.
    Those aren't backslashes \, they are forward slashes /. And they're required because XHTML is a standards-compliant XML binding, and all valid XML documents must be well-formed. Well-formedness includes the requirement that all elements be closed. The <tag/> syntax is just shorthand for <tag></tag>.

    This requirement isn't just bureaucratic mumbo jumbo. Ensuring that all (valid) XML documents follow rules like this is what makes them so easy to parse quickly and unambiguously.

    XHML did not take off because who would want to wade through thousands of pages in HTML written during the last decade and make those changes?
    There are automated tools (e.g., Tidy) that will do most of the work for static pages. But there really aren't "thousands of pages" to deal with; the HTML to XHTML conversion process is pretty simple [about.com].

    The real problems with XHTML are:

    1. It makes some common idioms, notably including embedded Javascript code, much more awkward to write correctly.
    2. There's no payoff for most sites.
    Item 2 is the real killer. If everyone is happily parsing "tag soup" HTML, which is often not compliant to any standard, why jump through the hoops (however easy those jumps might be) to comply with a standard that brings no immediate benefit?
  • by handslikesnakes ( 659012 ) <wfwdzqqgqiq@NosPam.mailinator.com> on Saturday October 28, 2006 @01:46PM (#16623590)
    You didn't read the document, did you? You've got the W3C's blessing to serve XHTML as text/html, but there are differences in the way Javascript and CSS are processed when it's served on a page as application/xhtml+xml.

"The one charm of marriage is that it makes a life of deception a neccessity." - Oscar Wilde

Working...