Closer To The Ideal

This article is old, but the issue is still current. Way back in 2002, Drew McLellan wrote an article for A List Apart explaining how to embed Macromedia Flash movies in valid XHTML web pages (his method was called Flash Satay). This is a sticky issue, because most of the examples on the web show you techniques (for embedding Flash on a page) that are invalid. The main issue is the use of the EMBED tag, which is often still used for backwards compatibility, but which is not supported in XHTML. We’re still cleaning up our own incorrect use of the EMBED tag over at our new iHanuman site.

In 2004, Drew wrote a post on his weblog, complaining that developers still had to jump through hoops to get valid markup while delivering a smoothly functioning Flash movie to users.

The juicy part is the conversation that breaks out in the comments. John Dowdell of Macromedia asks what data would justify an investment of effort on Macromedia’s part. To which Drew responds:

Pretty much all I’ve ever heard from Macromedia on this issue is where’s the hard data? over and over again. That’s understandable. It’s an important issue, and it affects an awful lot of Macromedia customers. If Macromedia Flash were my product, earning me thousands (millions?) of dollars each year, I would be looking for answers to those questions.

But it’s not my product – it’s yours. I don’t have QA engineers, test facilities or experts in every aspect of the technology on hand. It’s not in my interest to make sure Flash can be used with liveconnect or wmode in modern web sites – only whether I can accomplish the task I need to accomplish today for the audience I’m targeting. Simply put, it’s not my problem. It’s yours. Can your product remain viable in a world where the standard mark up language excludes its use?

You guys tell me, John – have you got any hard data? I think your customers would like to see it too.

John Dowdell responded:

“But it’s not my product – it’s yours.” Actually, no… you’re attempting to describe how the various browsers invoke extensions. Going to the browser-makers’ documentation is the first step. Testing their various implementations is the next step.
…
The core, underlying problem has been that the W3C’s HTML group set their EMBED-denying spec late, a few years after the browser manufacturers and the web-development community had been using EMBED and OBJECT to invoke extensions, and the W3C never supplied a path for the real world to join their ideal world. It is a messy process to suddenly tell the real world that it is wrong.

To which Drew responds:

You mean When will it become safe to continue using Flash? ;)

I don’t believe this is purely a browser issue. Macromedia are selling a product and recommending its use on the web. Isn’t it due diligence to test it in that environment? And to keep retesting as the environment changes? There seems to be some complacency that as Flash worked fine in HTML4 pages back in 1997 it’s fine to carry on that way. I personally don’t know of any professionals build new sites using the HTML4 of 1997.

John Dowdell responds:

What you’re trying to address now is the W3C’s sudden deprecation of an existing tag. If you recommend to others that they shun EMBED, then it’s good to first test what the actual results are.

To which Drew responds:

There’s very little about the adoption of XHTML that is sudden. The recommendation itself is four years old. The fact that professional developers have already adopted XHTML means that no one is recommending EMBED be shunned. It’s been shunned. Flash is already out in the cold – we’re just looking for ways to let it back in.

Bruce Collier then sums up what is my own reaction to the debate:

I have to second Drew on this point. It’s a little surprising (and disconcerting) to hear a Macromedia employee asking the community to provide data on browser support issues, and even more surprising to think that Macromedia isn’t constantly testing these issues for themselves. “Due diligence” is a very good way to describe it.

Pointing the finger at the W3C and browser makers and saying it’s too hard isn’t really an answer either. On behalf of developers out there creating and publishing Flash content every day, please please work your butt off to improve how Flash is implemented… so we can have faith that Flash has a future on a standards-based web.

It is really worrisome that an employee at Macromedia (now Adobe) would seem so unconcerned with the issue of standards.

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.