XHTML2 vs HTML5

[nshiell]

Ok ok I thought the whole idea of XHTML was so we could leave the non-xml, messy, non-semantic HTML technology in the past and develop web apps based on a decent XML language?

We have two standards in development and I think that reviving the font tag and attribute minimised tags cannot be a good thing.

Don't get me wrong, HTML5 has some cool JavaScript novelties but that should not be part of a markup language spec?

I've made my innitial thoughts known, now what are yours?

[rpgfan3233]

This has been debated (http://xhtml.com/en/future/x-html-5-versus-xhtml-2/) and discussed (http://xhtml.com/en/future/conversation-with-xhtml-2-team/) more than a few times (http://xhtml.com/en/future/conversation-with-x-html-5-team/).

While those three articles are a bit old, they still are somewhat relevant. I'm personally a fan of the approach that XHTML 2.0 takes, but there are some points where it has gotten into a bit of trouble, such as the age-old issue of elements vs. attributes and the issue of semantic information in the form of @role vs. RDFa vs. <insert another one>.

X/HTML5 is not without its own issues of course. For example, reintroducing elements such as B, I and FONT with different semantic meanings is a questionable practice. The spec also adds more elements like ASIDE, AUDIO and VIDEO, which are also of questionable value in my opinion. I'm not against the canvas API, but the CANVAS element itself is of limited use. Why can't the API itself be used with other elements? I've also questioned the use of AUDIO and VIDEO compared to OBJECT... I'm sure there have been justifications, but I haven't run across any.

There is also the issue of tag soup in X/HTML5. Using the HTML serialisation, you can omit certain tags just as you can when using versions of HTML before HTML5. For authors, this can be a problem when maintaining the markup. For browser vendors, HTML5 is different from previous versions in that it explains exactly how to handle...everything. I think the goal of previous versions was freedom... After all, not just browsers use markup. Not all user-agents are required to handle markup the same way. I don't really know much about HTML5 itself other than what I've read about it because, to be perfectly honest, it is a gigantic specification that changes relatively frequently.

Despite the fact that XHTML 2.0 seems cleaner, X/HTML5 features are being implemented. Then again, the XHTML WG seems to be in a slight state of turmoil, so it is probably a good thing that the browser vendors haven't jumped into things. Last time I checked, they didn't have any rationale for using attributes instead of elements and vice-versa, and some other issues are a result of that problem. The decision to integrate XForms and XML Events into the language the way the spec is currently specifying creates another issue...it is more difficult than ever to create a grammar. Also, do the events match up to DOM Level 3 or DOM Level 2 (I think this one was partially resolved, but I can't remember for sure)? There are all sorts of things preventing the XHTML WG from moving forward.

As for X/HTML5, I haven't followed that at all, so I can't really say anything about the progress there. I see fewer benefits to it than XHTML 2.0 based upon what I've read (yes, I've even read articles in favour of X/HTML5).

XHTML 2.0 FTW! :p

[NogDog]

What about XHTML5?
(http://www.w3.org/TR/2009/WD-html5-20090212/introduction.html#html-vs-xhtml)

[Jeff Mott]

Neither HTML nor XHTML is more or less semantic than the other. You can write semantic HTML, and you can write non-semantic XHTML. The only practical benefit from XHTML—in theory—is that you can use other markup languages such as MathML. I say in theory because IE6, IE7 and IE8 don't support true XHTML. That means IE is still parsing your XHTML page as if it were regular HTML. That's why when using XHTML, we must stick to the HTML compatibility guidelines.

Edit: Also, no standard is considering reviving the font tag.

[rpgfan3233]

Edit: Also, no standard is considering reviving the font tag.

Well, that's one good thing. Last I knew, the FONT element was going to be included for WYSIWYG editors only, and authors were discouraged from using it...which honestly didn't make much sense at the time anyway.

[Jeff Mott]

Last I knew, the FONT element was going to be included for WYSIWYG editors only, and authors were discouraged from using it...which honestly didn't make much sense at the time anyway.You're right. That makes no sense. ;)