Closer To The Ideal

I am struggling to accept what Anne van Kesteren announces as the future of the web:

People are slowly starting to realize what HTML5 means and start arguing about individual things:

* No SGML
* No DOCTYPE
* No formal schema
* No versioning
* Defined error handling

It’s hard to grasp that all you ever thought was right — is wrong.

Why am I strugling to accept this? I guess because learning all this stuff was hard and now, having learned it, it is tough to let go. As she says, it is tough to accept that all you ever thought is now wrong.

On the bright side, HTML 5 will have some new tags. Kesteren has been documenting them as part of the draft proposal:

section - represents a generic document or application section. It can be used together with h1-h6 to indicate the document structure.

article - represents an independent piece of content of a document, such as a blog entry or newspaper article.

aside - represents a piece of content that is only slightly related to the rest of the page.

header - represents the header of a section.

footer - represents a footer for a section and can contain information about the author, copyright information, et cetera.

nav - represents a section of the document intended for navigation.

The input element’s type attribute now has the following new values:

* datetime
* datetime-local
* date
* month
* week
* time
* number
* range
* email
* url

While using Google to look up some of Kesteren’s old posts, I stumbled across an older discussion of HTML5, XHTML, and how best to serve these files on the web:

Sam Ruby wrote that insisting on a valid XHTML web page was too hard for people who wanted to create SVG images (that’s Scalable Vector Graphics) as part of their pages. This made no sense to me because Ruby has SVG images on his page and I know he is very smart and can surely work out any problems with validity that he might run into (even making sure his page is valid XML). But then, in the comments, he explained what he wanted and it all made sense:

The world in which I would like to live is one where my daughter could view one of the ever-growing number of SVG images that are hosted on wikipedia, and could select-copy-paste one onto her MySpace template. I would have no problem with the requirement that the SVG image itself be locally well formed, but the requirement that the enclosing page must also be well formed and served with a non-forgiving and not-universally supported MIME type is a non-starter.

Oh, yeah, now I get it. MySpace is a disaster and there are lots of websites out there that are just as bad, yet a JPEG or GIF image will still show up correctly on any of those sites. Ruby wants a world in which SVG images are as portable as JPEG or GIF. That means they have to be allowed to work on invalid pages.

On that same page, in the comments, Ruby raises the question of why the WHATWG weblog is running WordPress, which serves XHTML. Since the WHATWG exists to tell the world about HTML 5, shouldn’t its blog run HTML 5? Lachlan Hunt then explained:

Regarding the WHATWG’s WordPress blog installation and the problems with it, I have attempted to get it to output HTML5 instead of XHTML, but the major problem is that there’s XHTML empty element syntax, string-based processing and other nasty surprises littered throughout the code, that it’s just just as simple as writing a new template for it.

It’s such a fundamental flaw in the way WordPress and many other CMSs have been built. The best option is to write a CMS from scratch that uses real XML tools on the back end and serialises as HTML to output; but the amount of time and effort that would take to set up compared with the one-click installation of Word Press is just too much.

I just posted this to the wp-hackers mailist, and Alex Günsche replied:

It is true that there are XHTML snippets hardcoded in the WP core. But it would be a matter of a couple hours to find and replace that code. (This would also be required on each upgrade.) Then you would need timeto create the template, which can also range from a couple hours whentaking and adapting a simple existing theme, up to a week and more whencreating a new and sophisticated theme.

WordPress is not MVC, which is, without a doubt, its greatest flaw.