Working together for standards The Web Standards Project


Flash, JavaScript, UX, standards, apologia, apologies, and one man’s opinions

By Ben Henick | August 18th, 2006 | Filed in Accessibility, Authoring Tools, Browsers, Bugs, CSS, Education, Emerging Technology, HTML/XHTML, Training, Usability, Validation, Web Standards (general)

The recent discussion of plug-in implementation, here and elsewhere, points to broader issues that affect everyone who is invested in web standards adoption.

Skip to comment form

My last two posts here have engendered a lot of anger from some Flash developers, and even led to direct questioning of my professional skill. Put bluntly, I believe the attacks say at least as much about the professionalism of their authors as they do about my own.

An apology

Regardless of that criticism, I offer an unqualified apology to Geoff Stearns for denigrating his work on SWFObject. It’s one thing for me to say that I don’t like it from a standards support perspective, but I framed my dislike in a tone that could counterproductively poison the attitudes of potential users of his work.

I took far too long to concede that my detractors were pushing back for very good reasons, and I’ve remained a moving target. They talk about user experience, I change the subject to Flash abuse. They talk about progressive enhancement, I change the subject to markup. They talk about the grating attitude of web standards advocates, and I (uncharacteristically) change the subject again.

If for no other reason that I was brought up to better rhetorical skills than I’ve displayed lately, I’m writing here in an effort to set things straight.

Web browsers have unforgivably broken and poorly documented plug-in implementations

There seems to be an agreement in principle amongst the participants in this discussion that W3C was a bad actor on this, because they insisted on sanctioning an element for plug-in inclusion that ran counter to the most common contemporary implementation. What we’re looking at, then, is an artifact of the Browser Wars.

To make the mess worse, no single software vendor has stepped up and implemented <object> in a manner worthy of emulation. To hazard a guess I pose that this is because browser vendors don’t really care for Flash, and each browser vendor wants to undercut the others’ related media player titles.

If my guess is anywhere near the truth, then the obvious result is that the expressed attitudes of the responsible companies are unconscionable, and need to change without delay.

There is a time and place for any given tool

If we can agree that content can be anything that will travel across the network, then the nearer layers of the web technology stack have their own particular uses, as well: markup for structure, styling for presentation, scripting for behavior (on the client side) and logic (on the server side). Likewise, there is no good reason I can think of to publish content in Flash or PDF when XHTML+CSS will do just as well. I also see no reason to avoid using Flash when presented with any of the objectives it can accomplish with low overhead.

Tool abuse is unprofessional and inexcusable, particularly when it leads to the implementation of sites in ways that the web was never meant to handle

The web was and still is intended as a means to obtain and create content that poses minimal requirements for accessibility and usability. Yet over here we see Microsoft pushing its own unique implementation for web applications, and over there you see Adobe marketing its own substitutes for just about everything the W3C can sanction. Developers then buy in and insist on using the tools they’ve paid for to create everything they can think up, without regard for suitability to project requirements or the strengths of the web. The resulting fragmentation makes everyone a loser:

  • Developers are forced to specialize in order to maintain salable skillsets, which makes them vulnerable to shifts in market demand.
  • Users are forced into a wilderness of software in order to use the web effectively, which is confusing, time consuming, and expensive.
  • Project sponsors are forced to spend more money on software licenses and the professional services needed to stitch together all of their preferred technologies.
  • Software vendors are forced into onerous release schedules, which reduces the reliability of their products and consequently their customers’ trust.
  • Network infrastructure is forced to account for more volume and protocol support than would otherwise be the case. This raises everyone’s overhead.

One of the most important definitions of a web standard is that rights to its use are completely and permanently unencumbered

This single fact accounts for most of my personal hostility toward the SWF format. The ubiquity of Flash creates the potential for future rights abuse such as that committed by Unisys in the case of the Graphics Interchange Format, and Eolas over its submarine multimedia patents. How many times do we have to go through experiences such as those before we learn to rely on the tools that are protected from such outcomes?

The desktop publishing metaphor does not and never will apply to the web, and developers need to do everything they can to get that point across to project sponsors

The insistence on pixel-perfect layout that results from reliance on the desktop publishing metaphor eats up time and money to an extent that places effective sites beyond the reach of many potential customers for web development services. It also constrains meaningful use of the web to the personal computer platform, and sometimes printed documents. While there are those who say that mobile platforms can also be used for visiting sites, there are so many caveats on that assertion as to make it empty. (Universal support for the handheld CSS media type would be nice to have any day now.)

Web standards support should be given priority over exacting user experience requirements, if a choice must be made between the two

This is probably the most controversial of my positions, but it’s owed to my belief in the web as a universal publishing platform. In the case of broken plug-in behavior, why not put plain links to bare media files inside their calling elements and let the visitor’s default media player take care of the rest? Creating a fallback that results in a positive user experience for that case isn’t impossible.

The balance of this attitude is engendered by the fact that given thoughtful implementation and valid markup, the resulting work product can be adapted to an extraordinarily broad range of contexts. This may not seem like much to the folks who are stuck on the desktop publishing metaphor, but information published for the express purpose of being viewed anywhere, anytime, on any capable and connected platform – which is what web standards are meant to provide – appears more valuable to me than something that looks and behaves exactly as specified when viewed by a remote user in Internet Explorer on a 1024×768 LCD or plasma display.

Using JavaScript to do an end run around the need for valid markup (and the content inside it) is at best a cop-out, and at worst an ingredient of future disaster

For starters, users who disable JavaScript will arguably never see the content you originally intended. Given the number of security issues for which disabling JavaScript is the recommended remedy, this use case cannot be ignored.

Another objection I have to this practice is that it increases the scope of production. Rather than just repairing one component of a site implementation when it’s time to redesign, you run the risk of needing to fiddle with other components as well (in this case, JavaScript in addtiion to markup).

Finally, you’re forcing another support assumption on the user. While sites designed around a desktop publishing metaphor and viewed on a personal computer may not suffer as a result, every other potential use case will.

Forward compatible implementation is more valuable than you think

So much of what I fight back against is inertia: people who use Internet Explorer because they’ve always used Internet Explorer, sponsors who insist that the work product have its layout nailed down to the pixel because that’s always the way it’s been done, producing far too many templates for lack of good wireframes because the graphic designers have never needed to work from wireframes, and so on.

However, the growth in popularity of Atom and bona fide microformats suggests the web’s not going to be monopolized by static HTML forever. When the evolution to XML gathers momentum, properly implemented XHTML+CSS infosystems will be the easiest and earliest such systems to utilize the full potential of XML. Do you really want your work to be left in the dust?

If not, then you need to learn how to do that kind of work, the sooner the better.

When standards advocates are unreasonable, it’s because they’re frustrated by the willful ignorance and sloth they see in the opposing camp

In practice, standards advocates demonstrate practices that require a different mindset than was typical for several years. In effect, we’re in the uncomfortable position of telling a lot of folks that everything they know is wrong. Here are some of the results:

  • Back when Zeldman instituted the Browser Upgrade campaign, its message was immediately co-opted by several high-volume sites designed by teams who were too damned lazy to institute progressive enhancement.
  • Rather than just admit that they are contstrained in their jobs by legacy content management systems that they cannot replace, some developers claim that they deserve the same credit given to colleagues who build fully standards compliant sites.
  • Every time accessibility flaws in all-Flash sites are publicly skylined, Flash developers howl in protest… but rarely endeavor to make their sites accessible.
  • Developers who have been in the business long enough to know better bitch and moan about the shift in perspective required to learn CSS, and refuse to learn it.
  • Other so-called professionals abuse their IDE’s and bill hours even though (as I once put it) “they wouldn’t know emphasis from italics if the difference bit them on the ass.”

All of these people continue to make noise and abuse the good will of their sponsors with a degree of persistence akin to that of Netscape 4’s erstwhile market share, and you bet we’re not happy about that… especially when they attack us ad hominem in the face of the fact that the truth hurts. That happens all the time.

Your Replies

#1 On August 18th, 2006 8:08 pm