Slashdot Mirror


XHTML 2.0 Working Draft

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>."

2 of 45 comments (clear)

  1. Re:a resounding "eh?" by Fweeky · · Score: 3, Insightful

    CSS 1 is about 6 years old, it's only seriously been usable for the last couple of years. Just because a standard isn't used much or handled properly doesn't mean it won't be eventually, or that the standard is worthless and hence shouldn't have been created.

    XHTML is already quite popular, because it provides a path to XML without breaking legacy clients. The top three clients already support parsing XML and rendering closely to the standards when it's served with the right Content-Type.

    XHTML 2 is another step towards this, loosing the legacy crap of HTML 4 and fixing problems without worrying about backwards compatibility. Hell, stick to the basics and you can provide for most of the tags for *current* clients with a bit of CSS.

    This is only a working draft, anyway. I wouldn't expect it to reach recommendation stage this year. Don't forget, they need two interoperable implimentations of each feature to even be concidered :)

  2. We send <object> for to have your advice... by Mad+Bad+Rabbit · · Score: 2, Insightful

    "Fweeky" writes:

    No more <img> or <embed>. They're replaced by the technically superior <object>. Let's hope certain companies can actually be bothered to impliment it properly.

    I do not get a secure fuzzy feeling about this element, when I read the relevant w3 spec, and see:

    Most user agents have built-in mechanisms for processing common data types such as text, GIF images, colors, fonts, and a handful of graphic elements. To process data types they don't support natively, user agents generally run external applications. The object element allows authors to control whether data should be processed externally or by some program, specified by the author, that processes the data within the user agent.

    So, instead of the relatively safe and well-defined <img> tag, user agents must now support a strange new <object> tag, which (at some unknown author's whim) may decide to run external applications and feed them arbitrary untrusted data.

    The w3 example shows the user agent happily downloading and running some unknown chunk of Python code, in the blind hope that it does nothing more "display a clock"!

    At a minimum, this means the user agent will need a lot of security configuration, to specify which MIME types it's allowed to handle at all, and exactly which external applications should be allowed to process them. Even then, I predict an amazing new ecosystem of exotic exploits.

    >;K

    --
    >;k