Slashdot Mirror

← Back to Stories (view on slashdot.org)

XHTML 2.0 Working Draft

Posted by timothy on from the navigational-lists-oooh dept.

Rytsarsky writes: "W3C has released the first public working draft of XHTML 2.0. 'XHTML 2 is a markup language intended for rich, portable web-based applications. While the ancestry of XHTML 2 comes from HTML 4, XHTML 1.0, and XHTML 1.1, it is not intended to be backward compatible with its earlier versions.' Some notable changes are the introduction of navigational lists (<nl>), sectional hierarchy with <section>, and the long-awaited deprecation of <br> in favor of <line>."

4 of 45 comments (clear)

  1. a resounding "eh?" by StandardDeviant · · Score: 3, Interesting

    Most sites aren't even HTML 4 compliant, let alone XHTML 1.x compliant. That's ok, becuase most (as in, probably 75 percent or more) of all browsers out there have broken HTML 4 compliance (I include CSS support with that), so even if the sites did use Completely Correct XHTML, the fucking clients wouldn't render it as the new standard dictated. For all practical purposes, the only thing sure to work right now is HTML 3.2. It was only relatively recenly that we could sort of begin to forget about the 216-web-safe colors resulting from widespread 8bpp video adaptors and the layout restrictions of 640x480 mainstream moniter sizings. I wish I was wrong, I really do. New, logical standards are good, and I'm glad somebody's doing the work. But honestly, does anyone really expect for this to be available as a real-world development option any time in the next four-plus years? I'm sorry to be harshly realistic, but somebody please wake me up when the web's layout code is logical, clean, and supported by all the clients we have to worry about...

    This is not to say that XML is not useful as a web development tool, quite the contrary. Nothing else comes close to giving you the multiple-generated-format flexibility (parse it to WML, parse it to HTML, parse it to PDF, parse it to VoxML, parse it to ...) needed to support all the crazy things people are using to access http resources these days. (The irony here is that as mainstream browsers have stabilized/stagnated, a combinatorial explosion of types of clients has taken place. The idyllic world of infinite permiability of information promised, in essence, by XML is a long way off... but it's close enough to be tantalizing. I can't wait for the day when I can really do just about anything from a web terminal that is my cellphone that I can do now sitting here in front of my workstation.)

    --

    News for Geeks in Austin, TX
  2. Did I miss it or... by Slipped_Disk · · Score: 2, Interesting

    Is there no tag or equivalent in this standard?

    I didnt have a DTD to grep through since they havent released it yet, but I hope there's still a convenient way to place images on a page.

    Anyone care to point out the glaringly obvious (yet overlooked on my part) location of this in the WD?

    Much Appreciated,

    --
    /~mikeg
  3. my biased take on this by f00zbll · · Score: 2, Interesting
    It's good to see XHTML move forward spec wise. In previous jobs where scraping other sites was a significant part of the job, HTML made life hell. Lately I've been thinking that moving to a combination of XML + realtime translation + XHTML conformant output. When I first started designing and writing web pages, a lot of the work was mundane text edits. I can see the value of using XML as the content storage format and having a lightweight web-based application for editing the content. This gets rid of several challenges from my biased perspective:
    1. don't need a complicated RDBMS driven content management system
    2. people can read XML fairly easy
    3. there are free xml editors available
    4. header/footer includes can be described in the XML as Metadata and maybe reduce maintenance. now a programmer doesn't have to get involved in changing an image map and image if that is in the xml
    5. easier for search engines
    6. easier for scraping applications
    7. more conformant to standards

    of course people will complain XML is bloated or slow or 100 other things, but having worked with a couple different content management systems, it would make frequent edits easier. It gives more power to non-technical people who want to change their site and free up HTML coders from doing retarded text edits. Plus it might help the adoption of semantic web and slowly move the industry towards a format that describes the content is greater detail. Generating conformant XHTML from XML is straight forward from personal experience. If getting millions of website to change was as easy as writing a new XHTML spec, the web would become a slightly more organized space.

  4. Security by Sir+Runcible+Spoon · · Score: 2, Interesting
    I would like to see any new standard for markup languages include security features. On a quick scan through I see no mention of it.

    When a web based application is displaying content aquired from other sources a great deal of effort is required to render the content harmless. In this article on kuro5hin it details the efforts by Yahoo to ensure that malicious javascript is not rendered in web mail.

    I think the markup language should allow the page designer to disable potentially dangerous features such as javascript within particular frames (or other elements), but still allow it to work within the page as a whole.

    <IFRAME SECURITY="scripting=no,images=yes" SRC="...">
    </IFRAME>