Working together for standards The Web Standards Project

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 Kerri replied:

I had a meeting just today with an internal ‘client’. I’m developing a site for him (he is a Flash designer, doesn’t know much in the way of CSS). This site will be world-facing, not simply internal.

When we were discussing why a particular feature of the site should be done in XHTML+CSS, rather than Flash, he said to me, “Well, we know our audience, and not many of them will be left behind by this decision.”

First, to think that he knows “his audience” when his site is going to be available to anyone on the internet with an interest in his content, it’s simply wrong. He THINKS he knows his audience, because he knows who he wants his audience to be. But in reality, I believe hsis audience is the world.

Second, he’s perfectly willing to make his project unavailable (in the case of Flash) or difficult to access (in the case of, for example, requiring mouseovers for some features) to certain subgroups of people.

Simply presenting him with the fact that some people will be excluded from using his content is ineffective. It’s an uncomfortable political move (not supported by the higher-ups) to instill guilt in him by telling him that he’s leaving behind a good percentage of his potential users. And it’s painful to try to point to legal requirements (ADA, civil rights, etc.), because, of course, there are no clear legal rulings.

So, what do YOU say to people when they’re perfectly happy to make the decision to leave behind populations who might otherwise benefit from their sites?

#2 On August 18th, 2006 9:13 pm Tanny O'Haley replied:

Not all programmers who use Flash, use it for the whole site. I use it to meet the (I know pixel perfect) requirements of our company’s Internet compliance department. I use sIFR to change the fonts of headings so that a graphic image of all headings for each site doesn’t have to be manually created. Site owners are given a standards based CMS system (in-house custom application) and when they create a document, the document appears with the “correct” heading font. If the user doesn’t have javascript turned on or Flash, it gracefully degrades to a web based font.

Javascript is used to make a collapsing and expanding navigation tree. If the user doesn’t have javascript, the tree is displayed open for each item.

Sometimes you want to “fix” things that the CMS cannot do, I use javascript for this. If the user doesn’t have javascript turned on, the layout is not always pixel perfect, which is no big deal. But if the user does have javascript turned on, they get a slightly better experience.

Or my use of Grease Monkey to increase the size of the font used for The Web Standards Project site because the standard font is too small for me to read comfortably. Grease Monkey allows me to target specific sites and I don’t have to press + to increase the font size every time I look at this site. Here’s a case where javascript enhances accessibility.

What about video sites that use Flash to display a video. Are you saying that those sites are invalid because their business is to display videos? Just because you use javascript or AJAX/JSON doesn’t mean a site is inaccessible. It seems like you’re saying that the automobile shouldn’t have invented because people with disabilities can’t drive them.

#3 On August 18th, 2006 11:09 pm Sir Lancelot replied:

Ben I can see your judgement is clouded. Just because something doesn’t follow accessibility/usability guidelines or for that matter web standards it shouldn’t be used. That’s not the case, but I believe following these guideline/standards is a step in the right direction however small, this even includes Flash even though its accessibility/usability is limited. Not everything is designed for everyone, try to envision that! I know the WaSP mission so don’t bother mentioning it but I also know theres not point condemning applications because of its lack of these standards, rather its better to try and increase their support for standards.

On a side-note these last few entries have really made me lose respect for WaSP, and yes I know that these entries express the opinions of their individual authors but I always believed that WaSP and the people within tried to promote the use of web standards, accessibility and usability in a positive way instead of making harsh criticism about things like Flash.

#4 On August 18th, 2006 11:11 pm Odders replied:

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.

Ahh, that’s a nice bit of reasoning. That one sentence right there shows your whole motive pushing the markup method pretty strongly in the first place, which is great. And the fact you explained the motive behind some more of your reasoning (not that I agree with it all :P) throughout the article will speak for itself, and I think people will be a lot more open to considering it. At the very least they’ll see you a driver by something based on logic, and not some petty hatred.

I framed my dislike in a tone that could counterproductively poison the attitudes of potential users of his work

That one was probably the biggest moot point for me. That, and the fact that all current users got told they chose something totally inferior, didn’t sit too well. I still don’t agree with the agrument that SWFObject dosen’t fit in with the spirit of of web standards. We know that it is standards compliant to the letter, as you put it. But you have to keep in mind that the features offered SWFObject – as well the bugs it corrects – are things that definite majority of users feel are vital. Despite how strongly any developer feels about standards, when they produce a solution that has to hit a wide user base, they need certain features, and they need reliability. I am sure there are circumstances where (like internal usage) where an object embed is appropriate, if nothing else for the sake of representing the spirit of standards as closely as possible. But, if SWFObject didn’t provide the functionality it does it would not be anywhere near as popular. This shows people find that functionality important. And we have seen the Geoff has been pushing for standards compliance, and implements it where appropriate in his work. To me, this shows SWFObject does comply with the spirit of web standards to highest degree possible, while providing essential functionality.

Anyway, I think I’ll make that my final rant :P It was nice for a lot people to see the apology also, I bet you had no idea the SWFObject user base would backlash this hard when you first posted the story eh? :P And best of luck advocating web standards, so that developers are more educated on applying them, and so organsations can provide consistent implementations.

#5 On August 19th, 2006 2:44 am WaSP Member bhenick replied:

Sir Lancelot writes:

“On a side-note these last few entries have really made me lose respect for WaSP, and yes I know that these entries express the opinions of their individual authors…”

That’s author, in the singular version. If you want to identify a bad guy or raise the point of lost respect, it should be on account of me and no-one else.

“…But I always believed that WaSP and the people within tried to promote the use of web standards, accessibility and usability in a positive way instead of making harsh criticism about things like Flash.”

…And as a rule, they do. I would say more, but I’ve already stated that I’m not gong to qualify my apology.

#6 On August 19th, 2006 2:56 am WaSP Member bhenick replied:

Odders writes:

“…This shows SWFObject does comply with the spirit of web standards to highest degree possible, while providing essential functionality.”

I distinctly recall two impressions from reading the source code: annoyance at the removal of whitespace, and the complete absence of DOM API methods. Stuck etween that rock and the nearby hard place, I remember asking myself, “surely this sin’t the best that can be done?!”

Which is one of the things that makes the apology that much more overdue. If I’m so damn smart, I should’ve tried to make something better instead of complaining a bunch. ;)

#7 On August 19th, 2006 3:28 am ROBO Design replied:

I agree with with you on the inertia factor. There’s an endless loop trying to convince some web developer who always coded for IE to try other browsers. He’ll always complain “this is what most visitors use anyway”, “why is the other browser rendering differently?”. You know the rest.

I also agreewith your point on Atom and feeds in general. This is a quite interesting development of the web. Feeds have gained a lot of popularity quite fast. (X)HTML won’t be alone.

As for the main subject of the post: SWFObject. I haven’t felt compelled to use it yet. I myself use the tag, without and without JavaScript. It’s not perfect, but it did fit properly in my projects.

Flash would have a lot to gain if they’d publish some specs of SWF. Flash is good for some sites (I am thinking of movie sites, entertainment and related).

I also dislike those sites made with Flash just because their authors use Flash for everything. It’s rather stupid to see a simple Flash site which could’ve been done entirely in (X)HTML+CSS much better, and accessible.

As you said, the mindset is the problem. It’s just like with CSS: when you switch from table-based layouts you have the completely change the way you think of a layout if you want to use CSS to its full potential.

#8 On August 19th, 2006 3:55 am Odders replied:

Heh, I hate being the bastard here (sometimes like it though :P), but on the SWFObject home page Geoff does link to a nicely formatted, readable version here.

The only blatent lack of DOM API usage I noticed from memory (and a quick once over as well heh) was the use of innerHTML for the final write, as opposed to the createElement, way of doing things. (Please correct me if I have missed something more sinister). But once again, this all stems from a desire to to be as compatible as possible.

Regarding the DOM node creation methods, it is only a small minority of older browsers that do not support the DOM node creation methods. But the beauty of SWFObject is that it has been graciously provided under the super flexible MIT license, and has been written using some nice OO javascript. There is nothing stopping anyone from inheriting SWFObject, changing the method(s?) in question, and voila – WaspSWFObject :P

But these are just semantics – and I ranted again. I should really stay outta these things hahah.

#9 On August 19th, 2006 4:14 am bobby van der sluis replied:

Sorry to comment again, this is nothing personal, I just think that it is a useful discussion. An earlier made comment about not knowing if Flash should be discussed on this website at all is very illustrating: you should discuss it. If plug-ins are not on the map of the WaSP, make sure you put in on there, because you miss out on a big opportunity to inform and educate people. Now the message sounds something like: it’s pretty dirty, we don’t know and we don’t like to know.

One of the strengths of the WaSP has always been to come up with practical advice for people who have to do their everyday work, on how to build websites the right way. E.g. the WaSP has helped me out enormeously on the XHTML MIME-type discussion. Just by the WaSP’s clear position and helping guidelines, it took away my confusions and I never had any questions about this subject later.

There are a lot of confused clients and developers out there who would like to be informed by an independent standards based institute on how to implement Flash the right way. If you like it or not, plug-ins have become a part of our daily lives and their use is rising.

Now I am sorry to say that the contents of this page are again far away from practical advice. Personally I think it is time for something like a new manifest, including some guidelines and best practices on plug-ins and Flash in special:
1. When to use it and when not to use it
2. How to include it in a valid or otherwise most optimal way
3. How to create alternative content

Another thing that was bulldozered over in this discussion sofar, however should be accentuated when using plugins, is how you define your alternative content. How do you make content of type ‘black box’ or ‘rich media’ (like Adobe likes to coin it) visible and accessible to people or automated code that don’t have the right technology support. Even if the object element would have been supported perfectly, this should be a valid question to be answered.

If people who favor web standards close their eyes for other technologies because they don’t like their nature, they will too end up being responsible for breaking the web into different camps. There are a lot of people like myself who like both web standards and the correct use of plugin’s like Flash. And for some projects we do have reasons to make 100% Flash sites, however we also like to use all technologies is such way, that we are respectful to the web’s underlying markup based foundation.

#10 On August 19th, 2006 6:57 am Ravi Khalsa replied:

I have been irritated by Flash based sites for a long time. Thanks for speaking for me!

#11 On August 19th, 2006 4:40 pm WaSP Member bhenick replied:

Odders writes:

“But these [suggestions to modify the script] are just semantics – and I ranted again. I should really stay outta these things…”

Are you kidding?! Stuff like this is exactly why we finally enabled comments!

You’ve been making a terrific contribution to the thread, man.

#12 On August 19th, 2006 6:07 pm karl replied:

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.

That is a common belief which is not true. The history of embed/object is available in the archives of www-talk (the benefit of having public discussions.). Embed element was not disqualified because of browser wars, but because of patent issues which finally hit the community as a whole last year.

Another reference about the patent discussion is given by Dale, the change of name was specifically to try to avoid what is happening now. Here there is another detailed analysis of the claims.

All these troubles these days show the benefit and the need to have came up with a royalty-free patent policy for W3C work, which was not the case at this time, and is still not the case for many organizations :/.

#13 On August 20th, 2006 6:32 pm Michael McCorry replied:

My contribution: not so useful, but miplementation (see article intro) is my new favorite word. :)

#14 On August 29th, 2006 4:23 pm Accessibility: standards versus testing — lucid plot replied:

[...] If we work around all the non-standard behaviour we can find, simply for the sake of people who are using broken technology, we’re not really helping them in the long run. Adaptive technology vendors aren’t going to start following standards unless we can demonstrate that their current implementations are not good enough; and the only way that’s going to happen is if they see modern standards-compliant code that doesn’t work. This is closely related to the recent WaSP debate about how to embed Flash: should user experience always come before web standards? [...]

Return to top

Post a Reply

Comments are closed.