"Web standards are not a religion, they're tools that offer a spectrum of choices and approaches."

Powerful tool, especially when used by artists who understand the scripting aspects. Some standards folks have a theological problem with Flash. But web standards are not a religion, they're tools that offer a spectrum of choices and approaches. Flash does certain things that XML plus CSS plus the DOM can't do, just as QuickTime does things other Internet technologies can't do. Religiously anti-Flash geeks who can look at the work of The Chopping Block (http://choppingblock.com/) or one9ine (http://one9ine.com/), for instance, and see nothing of value in it, are either aesthetically impaired or in denial.

Other people bust on Flash because of accessibility concerns, and those are as important to me as I know they are to you. Macromedia has addressed many of them in the MX release and is working on the few it hasn't licked. From an accessibility point of view, the challenge with Flash is, how can you deliver the same information and a comparable experience to those who cannot view SWF-formatted content? The information part is do-able if you understand Flash MX. The comparable experience part is another story, and in some cases it may not be possible, in the same way that you can't deliver a movie experience through a newspaper.

From a standards point of view, the main problem with Flash or any other embedded technology is, how can you embed it in a way that works and also validates? And the answer is, you mainly can't.

Drew McLellan showed that you could embed Flash using only the standard XHTML object element and valid, W3C-approved attributes (http://www.alistapart.com/stories/flashsatay/). That's the way Flash ought to be inserted in web pages, and it works for most users in most browsers. But it's unpredictable: it fails for some IE/Windows users; it also fails for some Mozilla users. Now, the object tag dates back to the mid-1990s, and every browser should support it reliably ... but they don't necessarily do that.

No developer who goes to the trouble of creating a Flash-based user experience wants to see it fail merely to prove a point about browser standards compliance or lack thereof. So for the foreseeable future, many Flash artists - even those who care about web standards - will likely use the proprietary, non-compliant "publishing" code that Flash generates by default. Which is kind of a shame. You run into the same problems embedding any rich media object, not just Flash.

"Many Flash artists - even those who care about web standards - will likely use the proprietary, non-compliant "publishing" code that Flash generates by default."

Does the fact that a cunning workaround/ hack is needed to allow a massively popular technology like Flash to be embedded and validate, indicate that the W3C is out-of-step with what people want to do? (I'm also thinking here of the panic over XHTML 2 recently.)

I wouldn't go that far. The W3C comes at these things from a scientific point of view: how should the web be built? By what premises could we create a unified, logical architecture for this powerful medium? Designers and developers come at it a completely different way, based on their day-to-day tasks: how can I make this work? I'm on a deadline and I need to solve this problem today.

There is a tension between those two approaches, but useful synthesis often results from such tensions - as long as the non-scientists have a voice in what the W3C creates. That's why the W3C publishes its ideas as working drafts, solicits community feedback, and changes what it has created in response to that feedback. For instance, the new draft of XHTML 2 clearly shows that the W3C is listening to the community's feedback. Not as keenly as Macromedia or Adobe might listen to its users, perhaps, but it is listening.

"The W3C's failure to make that simple compromise with a widely accepted practice might lead some to dismiss the organization and its works, but that would be a tragic mistake."

In my book I get into my theory about why the W3C never included the EMBED element in any HTML or XHTML specification, even though skrillions of professionals used that tag on millions of websites. I wish they had overcome whatever theoretical problems they had with the EMBED tag and simply gone ahead and put into the specs, in the same way they allowed, say bgcolor in the HTML and XHTML Transitional specs.