Don’t View This In IE

I haven’t been blogging as much recently, partly because I’ve been working to read more — I’m a little more than a third of the way through The Stand right now — but another reason is because I’ve been busy tinkering with the back-side of the blog. Specifically, I’ve been writing a new theme.

The purpose is of course to attempt to describe the sentiment of my blog more clearly through its appearance. I’m not a designer, but I think the new look accomplishes that, at least for me. More importantly than that, it was an attempt to take a project from start to finish, something that the string of flights of fancy I’ve abandoned over the years indicates is not something I do very often. Even more importantly than that, it was a chance to see if I could do the whole web-designer thing; I know that I’ll never be a real web-designer — I don’t have the eye for it — but having some sense of aesthetic appeal is useful in my field. And even more importantly than that, it was a chance for me to practice what I preach; I’ve been espousing HTML5 and its semantic goodies for a while, and there are new features of CSS that I think are fantastic that I’ve always wanted to exploit, so this was a chance to work with both of those things.

A consequence of this, is that my new design isn’t supported by IE1. If you’re viewing this page in IE, it might look like I’m still using the WordPress theme vostok which I’ve been using for quite some time now — if I did my job correctly — and that’s because I special cased you fools so you wouldn’t have to witness the horror that is the new design sans awesomeness. That said, I’ve tested the new design in IE9 and it looks almost perfect so when that one comes out, you’ll be able to appreciate the new design. For the rest of you, I’d like to discuss briefly a few of the features of the new blog I like. Geekery follows.

Read the rest of this article

Footnotes

  1. And all the multitudes rejoiced. [↩]

Divided Purpose

A List Apart published an article yesterday about the “unwebbability” of many written documents, and calls for XML to save the day.

I actually discussed that idea, albeit tangentially, in my last post about HTML5 vs XHTML2. The one thing few people emphasize anymore is that The Internet is not the same as The Web. The lingua franca of the web is HTML1 but XML is probably better for the internet at large.

The article tries to argue that HTML isn’t capable of semantically representing many formats, though the one they deconstruct in particular is the typical screenplay format2.

Most of the arguments against representing screenplays don’t hold much water to me; specifically, the idea that using class names to indicate semantic meaning is insufficient seems odd. Provided there’s an accepted microformat that people follow, class names are equivalent to xml elements in terms of semantic meaning. They are both simply tokens that indicate meaning to those accepting of those particular tokens.

But, accepting their assertion that class names are unacceptable as a retainer of semantic tokens, they fail to understand that XML does not have more inherent semantics than HTML, it only has greater extensibility of semantics.

This is a point that bears repeating, in slightly different words. An XML document has no semantic meaning without a predefined and shared document structure.

We could create an XML derivative Screenplay Markup Language (SML) but it would be utterly useless on The Web. It would be great on The Internet as an open format that could be freely exchanged, and perhaps even transformed into HTML that would mimic the visuals of the real thing, but SML would be useless on The Web.

The Internet is not for the presentation of documents, so XML is ideal. But if you want to display something on The Web, HTML is the way to go. It’s really not that complicated.

Footnotes

  1. A phrase which is mocked in the article, but is nonetheless true. [↩]
  2. Actually, they pick on John August’s Scrippets tool that allows screenplays to be easily written and displayed on blogs, which is a little harsh because it’s a great tool for people who write about screenwriting. [↩]

Standards For Standards Sake

This post gets nerdy enough that you might want to steer clear. I also don’t go too out of my way to explain the jargon of the subject, so be forewarned.

A few days ago, it was announced that the W3C was discontinuing work on XHTML2, which was planned to be the next big thing for the web; it was going to bring real semantics to the web while improving the extensibility and accessibility of the content on the web. I say ‘the content on the web’ rather than ‘HTML’ because XHTML2 was not going to be HTML. It was not backwards compatible with HTML. In other words, it was doomed to fail.

People saw the faults of the XHTML2 standard years ago and began working on incremental changes to HTML that would improve the semantics — perhaps not as much as XHTML2 could theoretically improve them — of the HTML content and introduce numerous new APIs that enhance what can be done in the browser while retaining backwards compatibility1. These improvements, along with adjustments to the HTML4 spec to align it to reality, are now known as HTML5.

Perhaps XHTML2 would have been better overall, perhaps not. That is a moot point now. HTML5 is happening, and XHTML2 isn’t.

But Shane McCarron, one of the people who worked on XHTML2 and the associated standards, decided to attack everyone he could in a post filled with a bunch of useless arguments.

The primary design principle for [HTML5] is “codify everything in use on the net, everywhere, no matter how broken, as long as Hixie has seen it at least once and thinks it is useful”.

These sorts of meaningless assertions, with an ad hominem thrown in for good measure, contribute nothing to the discussion. I’ve found Ian Hickson’s attitude on the HTML5 mailing list to be very brusque at times, but that has nothing to do with what the standard is about. Not only that, but the HTML5 spec does much more than codify existing behaviour; certainly it does that, but that is because the earlier specs were underspecified resulting in every browser doing things slightly differently.

But beyond this codification, the spec introduces a background process system for JavaScript execution, canvas elements for advanced graphical rendering, the video and audio elements to allow audio and video to be played in the browser without a plugin, with greater control and more openness, and that’s only a subset of the enhancements HTML5 brings. I don’t see how those things, which were specified before any browser implemented any of it, are mere codification of de facto behaviour.

There are between 5 and 15 actual user agent implementors in the world. There are millions of web content authors. How is it that the 15 (I’m feeling magnaminous) are more important than the millions?

This isn’t even the argument from popularity, it’s the argument from potential popularity. I’m a web content author. I wouldn’t want to write the content using the complexities defined in the XHTML2 spec. I was even one of those people that was fooled by the XHTML1 marketing that XML was somehow inherently better than SGML, and I still blanched at the sight of some of the things coming out of the XHTML2 working group.

In fact, of the millions of web content authors, I’m pretty sure that at most 15 (I’m feeling magnanimous) would be willing to work within the XHTML2 environment.

The people writing most websites are, unsurprisingly, writers. And whether they’re technologically savvy or not, the cognitive load that XHTML2, and all its associated extensions, would place on them is an unnecessary burden.

I know that some of the features of XHTML2 are useful for the machine-readability of websites, but you have to measure that against the extra effort required by content producers, text editors, and everything else involved in creating web content, to generate XHTML2 rather than HTML5. Machines will process things faster a month from now, and can use smarter algorithms to detect and discern human generated content. Humans don’t have that luxury.

But Shane doesn’t seem to understand that:

It was [Tim Berners-Lee] who decided to irreparably damage the brand(s) of the W3C by ceding control of the web to the WHATWG. What [was he] thinking? I assume [he was] under pressure from the browser vendors. I assume those 4 out of your ~400 members were saying “hey, we don’t want to implement XML-based semantic web. It’s haaaaaard (insert whine here)”.

I’m not a browser developer, but if I were I wouldn’t mind switching to a purely XML based system like XHTML2. It’s certainly easier to parse than the mess that is (the underspecified) HTML. Except that if I did that, I would no longer be a browser developer. I’d be someone that writes code, designed to behave as a browser, that is used by no-one.

Vendors possibly preferred to extend HTML4 rather than start over with XHTML2 but the difficulty of it would have been only one facet of the issue.

And developers like writing code. A well-defined spec, a text-editor, and a compiler makes many a developer salivate. And computers will always get faster. Those aren’t the blocking points, in my opinion. The thing that killed XHTML2 was the millions of voices crying out for improvements to the web who were at best amused and most often bemused by the complexities of XHTML2.

There are lots of other cheap shots taken throughout that post, but I’ve already shown you the gravest offenses; pointing out each individual baseless attack, accusation, and logical fallacy would only waste my time.

The facts are these. XHTML2 has been in development since before HTML5 was brought up as an idea. HTML5 is now in use in browsers everywhere with more and more of the spec being implemented with every new browser release. XHTML2 probably has a few experimental features that you can play with in Firefox. XHTML2 lost. You can blame that on the vendors for not implementing your ideas, but the fact is your ideas were shit. If they were good, if they were what users wanted, browser vendors would put more effort into implementing them.

HTML5 is not “shackling the web content developers into the tag-soup architecture of the 90′s.” Tag Soup was never about the language, it was about the philosophy. Did C++ shackle C developers into “goto architecture?” HTML5 was about giving web content developers what they actually want, not a bunch of buzzwords and disingenuous attacks. It’s not as if HTML5 is ready for prime-time. IE still doesn’t support most of HTML5, but people are out there experimenting with HTML5 because it’s cool.

XHTML2 is standards for standards sake. Nobody’s using it. Nobody ever will. So let’s all get over it2.

Footnotes

  1. It does introduce new elements which will not function correctly with an HTML4 browser, but nothing old would be broken. [↩]
  2. I admit that this is a bit of a departure for me. I’ve been one of the silent (but full-throated) proponents of JavaScript2/ECMAScript 4 over ECMAScript 3.1/ECMAScript 5. But there are distinct differences here. First, ES4 was backwards compatible. Second, ES4 brought demonstrable advances to the JavaScript environment, whereas XHTML2 seems to mostly work towards normalizing the substructure of HTML without offering any inherent advances, only allowable advances. That said, the irony of me being such a staunch attacker of XHTML2 while such a staunch defender of ES4 is not lost on me. And it goes without saying that, at this point, I’ve gotten over the ES4/ES5 schism and am happy to be working towards advancing to ES-Harmony. [↩]