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

Comments

Re:LINE tag long-awaited?

[ivan256]

Yeah, exactly, everybody was clamoring for two extra bytes? Really, the poeple who look at the code at this level probably don't care, and everybody else uses a WYSIWYGOIE editor and hense doesn't care.

Besides BR makes sense, and LINE doesn't. Why not NL, or NEWLINE, or CR? LINE seems like a better replacement for HR then BR to me.

Re:LINE tag long-awaited?

[merriam]

Read the definition, and you'll find it's not about the name of the tag. It's about the structure. Lines are now marked up like paragraphs -- they are not separated by empty tags.

Hmm...

[Karma Farmer]

So, when is Slashdot going to start offering XHTML 2.0 as a page rendering option? Actually, when is Slashdot going to start offering any sort of valid HTML as a page rendering option?

Re:Hmm...

[pnatural]

You kids!

Back in my day, we had to parse ugly, non-conforming HTML by hand for every site and we liked it! None of this fancy-shmancy "valid" or "conformant" SML for us, no-siree.

I've said it before and I'll say it again, give a kid a parser and he'll never learn how to parse himself.

a resounding "eh?"

[StandardDeviant]

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

Re:a resounding "eh?"

[Fweeky]

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 :)

Re:Welcome changes

[satanami69]

But what would the second one look like in XHTML2.0?

Did I miss it or...

[Slipped_Disk]

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,

Re:Did I miss it or...

[smileyy]

I'm assuming you meant the img element. See the object element instead. That's what you'd use to embed media in the page.

Main changes

[Fweeky]

For those who don't like reading WD's:

• Navigation Lists (<nl>), with a default rendering not unlike a DHTML menu. This will likely be controlable by CSS using display: and :hover as seen on CSS/Edge
• <q> becomes <quote>, a new <dfn> element, and <b> and <i> have been completely removed. <br> is going in favour of <line> which will help with DOM and CSS. <hr> is still there for some reason. (Text Module).
• New <section> element. <h1> and friends are still in the draft, but are accompanied by a new <h> element to go with each (nestable) <section>.
• <a> is still here; no XLink in this draft, despite it being a recommendation.
• Forms are now replaced by XForms, also a Working Draft.
• 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.
• Frames replaced by XFrames (nothing public yet).
• A few more global attributes, and the use of XML Events for scripting events.

Also, for those interested in such things, the CSS 2.1 Working Draft has been released too.

Re:Main changes

[Rytsarsky]

Frames replaced by XFrames (nothing public yet).

An XFrames Working Draft has been released. See http://www.w3.org/TR/xframes/. XML Events look really fun, too.

Re:Main changes

[Fweeky]

no XLink in this draft, despite it being a recommendation.

People wanting to know why might find "What is the scope of using XLink?" interesting.

my biased take on this

[f00zbll]

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.

Security

[Sir Runcible Spoon]

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>

That's it?

[booch]

Seems like if they're going to make it backwards incompatible, they should change a lot more. For example, are nested tables really the best way to lay out a page? Can't we come up with something better than that? (Without hard-coding coordinates -- I'd like something like the GTK or Swing layout methods.) How about the script and noscript tags? Any chance we can stop having to put comments around the script code? How about separating the 2 distinct uses of anchor tags?

Re:That's it?

[Fweeky]

Seems like if they're going to make it backwards incompatible,

Not entirely, clients shouldn't need particularly huge modifications to support it. Certainly with Mozilla it's mostly some CSS work.

For example, are nested tables really the best way to lay out a page?

This is what CSS is for.

Go poke around the CSS3 working drafts, and maybe join www-style if you want to discuss it with clueful people.

How about the script and noscript tags?

What about them? <noscript> may be removed in favour or JS/DOM/CSS, but it's unlikely. <script> may be replaced by <link>, but again probably unlikely given that it makes it harder and less reliable to use client side scripting (a good thing? Maybe, but I'd be wary of pushing yet more ways of things going wrong).

Any chance we can stop having to put comments around the script code?

Um, from XHTML 1.0 it's been explicitly stated that you should not do this, since UA's are allowed/expected to strip the comments.

CDATA is the proper way to do this if you must; comment hacks are available if you want to hide from broken clients, but typically you should be using <link> for your stylesheets and <script> for your scripts if they're complex enough to require such hacks. Think of it as a handy code smell ;)

How about separating the 2 distinct uses of anchor tags?

What distinct uses? As links and named anchors in a page? We already have that; just apply an id attribute to any element on the page and it should work as if it was an <a name="foo">.

We send <object> for to have your advice...

[Mad Bad Rabbit]

"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

Re:We send for to have your advice...

[Fweeky]

Um, is nothing new; it was in HTML 4 and looks much the same.

It's effectively an img/embed tag which can be nested to allow the UA to fall back if it doesn't support something.

The draft's example includes showing the use of embedding an applet - so what? If the UA wants to execute it outside a sandbox, that's no the W3C's problem, just like Java or ActiveX security or Flash's security isn't their problem. If Python applets were ever to appear I'm sure they'd be secured similarly.