Semantic Flash: Slippery When Wet
Issue № 233

Semantic Flash: Slippery When Wet

There’s a belief within the web standards community that Flash is part of a different world. While all approaches have limitations and drawbacks, Flash has been scorned to the point that many refuse to acknowledge its benefits. Ultimately, this has led to the creation of a virtual separation among web designers; those who use Flash use it exclusively (leading to a saturation of full-screen, “Skip Intro”-rich Flash sites on the web) and those who don’t ever give it a second thought.

Article Continues Below

Although the brilliant option of the hybrid (part Flash, part HTML) site had always existed, it’s never really made it far past the typical Flash intro on a corporate homepage. Throughout the history of Flash on the web, the technology has always been intended to be embedded within HTML. Yet it has often seemed a foreign concept to use the two technologies to complement one another.

A not-so-“swft” change#section1

Eventually, a few web designers and developers realized that there were ways to use each technology to its advantage. Over the last several years, there has been a resurgence in the proper use of technology. Debates on semantics abound. JavaScript—and more importantly, unobtrusive DOM scripting—has seen a revival unmatched since the bad old days of DHTML. Most delightfully, Flash is also getting its due. Granted, it’s not as popular as the typical Web 2.Ohwhatsthebigdeal ingredients. Yet.

Slowly but surely, Flash is finding its way into the standardista’s toolkit, and it’s happening in a very exciting way. There’s no need to convince Mr. Web Standards that he should start building full-scale Flash sites. Flash is easily making a new home for itself, not as an alternative, but as a supplement.

sIFR is the perfect example. Shaun Inman, Mike Davidson, and Mark Wubben have done an excellent job in recognizing powerful combinations—semantic content markup with HTML, beautiful font-rendering from Flash, and client-side document transformation with JavaScript—and created a smart and efficient tool for others.

Need more evidence? Take a look at SlideShowPro. Todd Dominey leveraged a task that Flash does well—parsing XML—and created a modular device that is incredibly easy to install and use.

Still a skeptic? Did you know that Flash can detect the presence of a screen reader? Want more? Feel free to check out Flickr, Yahoo! Maps, Google Analytics, or Consider the surface scratched.

Hand in hand#section2

Notice that none of these examples focus on a sole technique. It’s not to say that Flash—or the other methods, for that matter—aren’t useful as standalones, but collaboration can be even more powerful.

Audience participation#section3

Successful integration is obviously possible. So how can you start integrating Flash into your workflow? The first step is to change your mindset. If you can accept that Flash is more than an all-or-nothing deal, half the battle is already won.

Let’s test this theory in the wild. Say you’re working for a nifty Web 2.0 client who rates CDs. You know they subscribe to the stereotypical Ajax-y goodness, so you’ve been kind enough to design as such. You present a set of designs for their “Ratings” page, a part of which looks like this:

Preview of proposed design

Figure 1. A comp of the proposed website design

You know they’ll be entering content into some sort of CMS, so your goal is to create as automated a process as possible. Taking this to the next step (templating), let’s see this page in action.

Savvy readers will have noticed that there’s something missing in the last file: the reflection. While there might be some contention as to why you’d want to do this in the first place, it’s no secret that the shiny floor technique is stereotypically “Web 2.0.” Let’s just say that the client requested it, and you were accommodating enough to oblige.

Your client is employing your services because they can’t justify the expense of a full-time designer, so it’s your job to make them as self-sustaining as you possibly can. They have access to CD cover artwork, but don’t have the knowledge required to perform image manipulation, not to mention the fact that your previous experience with clients tells you that manual editing usually leads to disaster.

You have three options:

  1. Suggest hiring a full-time graphic designer.
  2. Instruct the client on manually editing files.
  3. Find some way to automate the procedure.

Hiring a dedicated person often works best, but there are times when it’s not as beneficial or not feasible. Unless you have a particularly sharp client, option two should be prohibited. That leaves one more: automation.

The idea behind automation is that a set of standard rules can be applied to many instances. Like Photoshop actions or any batch operation, the biggest obstacle is describing what you would like to accomplish. Once you can verbalize that, the syntax part is easy.

With this example, there should be a way to describe creating a reflection. Essentially, a reflection is a mirror version of an original image, but with a bit more transparency. If only there was a way to manipulate the properties of an image…

Enter Flash. (And its long-lost brother, JavaScript.)

A good foundation should always be the first goal. By using semantic HTML, you can be sure that your content is accessible to all types of users, regardless of which user agent is present or plug-in enabled.

I decided to jump into Flash next because it suits my preferred workflow. Before starting any dynamic tasks, I like to test them out statically. If it works with one hard-coded instance, it shouldn’t be too difficult to get it working with many instances. Without writing any code, I first try and verbalize what I need to do in plain English:

  1. Duplicate the image. I’ll need one copy to be the actual image, and another copy to serve as the reflection.
  2. Rotate the reflection by 180°. Typical reflection logic.
  3. Flip the reflection around the y-axis. Rotating alone won’t cut it. The image has to be flipped in order to pull off the illusion.
  4. Lower the opacity of the reflection. Real world reflections are seldom as strong as the image itself. For the sake of believability, turn the intensity down a notch.
  5. Position the reflection at the correct coordinates, relative to the original image. Because rotation and mirroring alter the registration point of the image, some basic math skills should help to calculate where the reflection should go.

After determining the steps, a quick lookup in the ActionScript dictionary helps to translate words into code. This isn’t a primer on writing ActionScript, so I won’t focus on explaining the code, but for the curious, here’s the magic (one layer, one frame file, all code as frame 1 actions): (Line wraps marked » —Ed.)

Stage.align = "TL";
Stage.scaleMode = "noScale";
Stage.showMenu = false;_root.stop();// ===== cover
_root.createEmptyMovieClip("cover", 1);// local testing
//_root.cover.loadMovie("cover.jpg") _root.cover.loadMovie(_root.jpg);
_root.cover._x = _root.cover._y = 0;// ===== reflection
_root.createEmptyMovieClip("reflection", 2);// local testing
_root.reflection._rotation = 180;
_root.reflection._xscale = -100;
_root.reflection._alpha = 25;
_root.reflection._x = 0;
_root.reflection._y = 277;// ===== mask
_root.attachMovie("mask", "mask", 100);
_root.mask._y = 139;

The example works well with a hard-coded file, but how can we make it work with a number of files? Luckily, all of the content is already accessible within the markup. Using some clever DOM scripting, we can send Flash all the info it needs, and let it do all the grunt work for us. Following the same coding technique, let’s work out what needs to happen to the DOM:

  1. Locate and store references to all of the images on the page. Conveniently, there’s a built-in method for that (document.getElementsByTagName).
  2. Dynamically create Flash files and pass the SWF references to the appropriate images as a variable.
  3. Replace the original images with the newly created Flash files, and insert them into the pages in the correct positions. Small loops and the formidable SWFObject make this happen.

And, for the hungry: (Line wraps marked » —Ed.)

window.onload = function(){   
  if(!document.getElementsByTagName || » 
!document.getElementById) { return; } 
  var covers = document.getElementsByTagName('img'); 
    for(var i = 0; i < covers.length; i++){
      var newflash, newflash_param;  
      newflash_div = document.createElement('div');
      newflash_div.className = 'shiny';  
      covers<i>.parentNode.insertBefore »
(newflash_div, covers<i>);
      var reflections = new SWFObject("covers.swf", »
"mymovie", "138", "211", "7", "#dbd8b7");
      reflections.addVariable('jpg', covers<i> »
    }    while(covers.length > 0){

Have a look at the automated reflection example.

(If you’re brave, here are the source files for experimentation.)

A myriad of possibilities could arise from the marriage of these technologies. I’ve already mentioned a few, and the newest one to hit the stores—pardon the self-promotion—is swfIR. As the technique that directly inspired this article, it uses the same logic to apply a wealth of options to static content.

And there you have it: a few examples and a detailed walkthrough of HTML, Flash, and JavaScript working together to produce a technique that is automated, efficient, beautiful (depending on who you ask) and client-friendly. Though it’s already implied, it’s worth explicitly stating that this is just one sample of the endless possibilities for using Flash in a web standards context. I’ll be discussing additional possibilities in a continuing series on the perks of “Semantic Flash.” Stay tuned!

64 Reader Comments

  1. I’m viewing this article in a browser with javascript enabled, but without flash installed. In this instance I don’t get the original image, so my experience is worse than the static version. With javascript off it looks like the original example. Perhaps some javascript detection of flash is in order?
    Also, the link to the original ratings example should be

  2. “@Damian”: Thanks for bringing up that point. There are a wealth of ways to code this example differently, and many ways to improve the usability and accessibility of it. What I wanted to get across was the _theory_ of the example, not the code itself. I tried to streamline it so that it’s most easily understood. Were this a deliverable for a client, there should be multiple improvements to ensure a consistent experience among different user types. I felt that adding those things would have complicated the point, so I chose to omit them, but they are still very important within a practical setting. Like you mentioned, a very basic way to improve upon this would be to build in a check to see if Flash is installed.

  3. It seems to me that the easiest, most cross-platform way to achieve the reflection is to do it server side with imagemagick or a similar library. It’s trivial to do in your scripting language of choice (python, PHP, perl, ruby) and removes the requirement for flash on the client side.

    While there may be legitimate uses of flash in an xhtml-based site, I really don’t think this is one of them. In my opinion, flash should always be an option of last resort, when there is simply no other feasible way to achieve one’s goals. sIFR, on the other hand, seems like a legitimate use. It’s something that doesn’t affect the accessibility of the site for those without flash, and does something that can’t really be done well in any other way (you could render an image server-side, but that causes other problems and you lose the accessibility of the text).

  4. Doesn’t it make more sense to simply flip around the x-axis, rather than rotate 180°, then flip around the y-axis?

  5. As it happens there is a small Javascript file that can take care of image reflection (reflection.js)

    The fundamental problem with Flash, and this is insurmountable, is that all the content is locked away in an unparsable proprietary format. This is so completely against the whole foundations of the internet that we should all think carefully before implementing a Flash solution.

    One of the key features of the so-called Web 2.0 sites, that of easy exchange and enhancement of content would not have been possible if everything was locked away in an .swf file.

  6. I really strongly disagree with what Ross was saying. Content is not *locked* away in a swf. The swf should/could be simply the way of displaying the content.

    In the majority of my Flash projects all information/content is held externally and loaded as/when required.

    By his reasoning php/asp/ruby or any other server side language is _locking away the content_ as you can not access its source.

    Whereas we all know this isnt true as these server side languages simply facilitate the transition of information from your server to the client.
    Which when used properly is exactly what Flash does.

    Also for any Flash/Javascript/Clientside developers reading I recently “created a flash debugger script”: which links into “Firebug”: so you can easily see what is going on within the client.

  7. That’s simply not true, you use your server side language to produce your content which you can then view the source code for. If I use a server side language to create an image it’s rendered as an image with an img tag and the same goes for any other created content.

    How do you view the source of an swf file?

  8. I’m on a 64bit version of GNU/Linux. There is no official version of flash that supports a 64bit OS. I use one of the FOSS flash players, which sometimes works, and sometimes doesn’t. In this case it doesn’t, which you think would be okay… except actually it removes the ordinary image too! Not only do I not see the pretty reflection, I don’t see the cover at all.

    This should not be acceptable for a public website.

  9. bq. And how do you save the image as a JPEG file?

    It may not be possible in the example, but I would think a few extra lines of ActionScript and you could customize flash’s contextual menu and provide a much more descriptive link to a high res version, maybe even a zip version.

    With Flash you could actually make the enhanced image “more” accessible to those with Flash leaving the default image and browser contextual menu for those without.

    bq. How do you view the source of an swf file?

    For some people this is an advantage, they don’t want people downloading their images for use willy nilly all over the internet. If that doesn’t fly though, my question is why do you need to view the source? When viewing the example source I see three images, which is what I see in the rendered page. Sure the inline images are not the fancy version, but for the large majority of internet users, who cares?

  10. The only problem I have with this new method (and I checked out the swfIR page, it’s the same there, not just in this example) is that the original image loads first and is displayed, before being replaced by the flash movie (at least on my setup). This may be confusing for some users, and reveals the “magic” behind the trick. I think for swfIR to catch on, even given all of the concerns raised so far, it needs to hide the original image before replacing it with flash.

  11. “@Micah”:

    bq. In my opinion, flash should always be an option of last resort, when there is simply no other feasible way to achieve one’s goals.

    Obviously, I disagree. Flash is a technology, just like XHTML, and should be used where appropriate. If it fits as a solution, it may very well and should be the first option.

    bq. sIFR, on the other hand, seems like a legitimate use. It’s something that doesn’t affect the accessibility of the site for those without flash, and does something that can’t really be done well in any other way (you could render an image server-side, but that causes other problems and you lose the accessibility of the text).

    If sIFR is a legitimate use, then why isn’t other use of Flash? sIFR didn’t originally launch fully supporting accessibility, but those features were built in retroactively as part of their initiative to make it better. sIFR is a great technique, not only because of what it can do, but because it shows that the features are available in Flash and ready to exploit. It’s the responsibility of the designers and developers to implement them.

    “@Anson”: That’s certainly one way to do it. They both require a line of Actionscript each, so it’s just a matter of preference.

    “@Dannii”: Please see “my previous comment about degradation”:

  12. My problem is that at work (government) all flash is blocked no matter what, even if we create it. Makes most sites unusable that have implemented flash in anyway even if the site checks for flash being supported. Our browsers support flash, but the firewall lets nothing through.

    This solution looks o.k. in principle, but won’t be one I’ll be trying out.

  13. I can do this trick automatically using RMagick or any other GraphicsMagick/ImageMagick wrapper. Unless I’m forced to deploy to a shared host that refuses to work with me on making these libraries available I don’t need to add a potential browser compatability headache into this scenario.

    B+ for effort though. I personally don’t have a problem using Flash where it enhances the user experience but I always want to have a fallback and I never want my non-Flash work to be noticeably distinct. The only demands I want to put on my users is that they use a modestly capable web browser and enable Javascript when they come visiting my rich-interface web applications.

  14. I love this technique, and think it has a lot of potential. Yes, there is some fleshing out to do, and sure some of these things can already be accomplished through imagemajick etc. This seems to be more of a designers answer to such a problem.

  15. I don’t like these kind of content-replace solutions because they show the original content first, causing an ugly flicker after the page has loaded and the enhanced content kicks in.

    Most people probably don’t worry about this flicker, but to me, it’s too much of an irritation to implement such a solution.

  16. Sure you can do work arounds, add accessibility or right click capabilities on top of flash. But why not render an html image and have those capabilities baked in?

    Processing the images server side and rendering them inline provides all the accesibility and functionality that the browser/html/css provide. Each designer/developer shouldn’t have to roll their own(potentially differing) solutions, and the user should get the same usage/functionality they expect from page to page and site to site.

  17. I left HTML development for Flash development long ago, and have never looked back, so perhaps I am a tad biased, but then again, so is everyone here. “Traditional” Web developers’ misconceptions about Flash are so old, so wrong, so ignorant, it’s just sad and tired. I usually ignore it as white noise, but I’ll rise to the bait this time. I guess I’m just bored.

    In no particular order:
    Flash is not all about annoying banner ads, just like JavaScript is not all about annoying pop-ups. The fact that Flash is turned off on some computers is not its fault, it’s the fault of the above-mentioned misconceptions. Even still, Flash has the largest installed base of any plug-in out there; expect that to rise with Adobe’s support. Unlike HTML, Flash is consistently cross browser, cross platform; I encounter a browser/platform issue maybe once a year in my work, and it’s usually due to the inconsistencies of the way different browsers/platforms handle Flash within the HTML, not due to Flash itself (e.g. for full-window, scalable sites, Firefox is buggy if you include a Doctype tag). Unlike CSS, Flash can handle 100% heights flawlessly. Unlike “traditional” web development, Flash can live outside the browser, with or without Web connectivity, on kiosks, CD-ROMs, desktop applications, phones, and a growing list of other devices (note: browser kiosk modes are not the same thing). As far as I know, Flash Remoting is the fastest server-client communication protocol out there. Flash right-click menus are fully programmable/customizable. Flash (Flash 8, that is) font rendering is much clearer and sharper than any browser text. Flash can render any font you have (yes, this is a big deal, even if you don’t understand why). Text can be selectable…or it can be not-selectable…unlike HTML, you have the freedom to decide. Flash content can be exposed to search engines (although that requires specialized knowledge…but then again, so does HTML, so what’s the big deal?). Flash can provide “deep-linking” to internal content. Flash can tap into the browser Back/Forward buttons.

    I think I had better stop. Oh yes, one more thing: the example in the article was just that: an example. It is not a definitive solution, nor is it the best solution, by the author’s own admission. The flicker is not inherent to Flash, but to the specific way that solution was programmed.

  18. “James”:#21: You can certainly accomplish the same end result using other methods, like ImageMagick. However, the true value of doing it client-side is that you’re only _styling_ the content. Much like CSS, the original content (the image) is untouched. If someone wants to download and use your image somewhere else, what good is it if it’s already manipulated server-side with rotation, a shadow and on a less than desirable background?

    “Blaise”:#24: The flicker is caused by the @window.onload@ handler. It can definitely be solved through other methods, one example being Simon Willison’s “addLoadEvent”: In the example, I left it out for the sake of brevity, but it’s certainly a way to improve the script.

  19. In this example you the image is loaded twice, but in Flash 8 using BitmapData you can “clone” the original image, flip it, apply a gradient mask and place it under the original. Thus creating a reflection but only loading once.

    I noticed the comments on serverside technology, but that is the problem right there. What happens if you want this technique on a localized kiosk? Working with clients in the corporate training enviroment I found one thing very quickly and that is these modules will never have access to the internet in its normal sense.

    Overall this article is a great example of how Flash can be used while at the same time it shouldn’t be used for everything and the same goes for every other technology.

  20. Thats good and all, but even if people got Flash, what about the places that block all of Flash, like Kendall Conrad says? They would signal “flash detected”, but no content would show up.

  21. In this particular example I don’t see why you’d have to replace the original image. You only want to add a mirror image, so why not leave it to that. That way people who don’t have a Flash-enabled browser still can see the original images, others see the original and the newly added reflection.

  22. “Matthew”: :

    bq. I noticed the comments on serverside technology, but that is the problem right there. What happens if you want this technique on a localized kiosk? Working with clients in the corporate training enviroment I found one thing very quickly and that is these modules will never have access to the internet in its normal sense.

    When I say server-side, that doesn’t necessarily mean on the internet. Your content is being served by some sort of CMS. That CMS has to be run by some sort of server, whether it’s accessed across the internet, an intranet, or locally. In all cases there is a serverside language which could modify the image. If there isn’t a CMS, that means that your cotent is completely static and can just prep all of the images before you deploy.


    bq. James: You can certainly accomplish the same end result using other methods, like ImageMagick. However, the true value of doing it client-side is that you’re only styling the content. Much like CSS, the original content (the image) is untouched. If someone wants to download and use your image somewhere else, what good is it if it’s already manipulated server-side with rotation, a shadow and on a less than desirable background?

    That’s a good point, however I think our primary goal as web designers is to make our content as accessible and stylish as possible for as many people as possible. I don’t think our primary goal is to make it simple for users to download and use elsewhere our content. Doing the manipulation serverside allows for every single (graphical—sorry lynx users) to see the reflection, instead of only those with flash (which, as noted earlier, excludes 64-bit linux users, as well as many mobile users). Now whether something like a reflection for images is valuable is another discussion entirely 😉

  23. Great article. The first time I saw Flash and used it, it was called Future Splash. MSN used it for really cool menus and buttons. In contrast, the Simpson’s site was a full-screen experience.

    Both uses have their place on the web.

    Using Flash as content is how I see it best in most situations. Google, and Yahoo both see this as well as you pointed out.

    The message is to use whatever technology makes it easiest to get the job done. Flash is certainly the easiest way to handle your example for most web designers. Sure, you can do it on the server, but that is not as accessible and easy to use.

    By the way, I’m looking for a full-time designer/developer who thinks this way and uses all technologies to create the best designs.

  24. bq. The message is to use whatever technology makes it easiest to get the job done. Flash is certainly the easiest way to handle your example for most web designers. Sure, you can do it on the server, but that is not as accessible and easy to use.

    The problem is that this technology is _less_ accessible than server side image creation, not more. Since presumably web 2.0 reflections are a useful thing on a site (why else would you go through all this bother?) we want all of our users to see them. With flash only those who have flash can see them, while the rest of your viewers see the plain images. How is this a better result than server-side manipulation, where all of your users will be able to see the images?

    Certainly ease-of-use of any technology is important. However, there is a point where an easy to use technology simply does not get the job done as well as a slightly-more-difficult to use technology. I don’t feel that we should immediately jump on the simplest technology. Instead we need to evaluate the advantages and disadvantages of each, and come up with a conclusion that takes other factors into consideration than just ease of use.

  25. “RE: Booorrriiinnnggg”:

    Small screens are an issue I don’t think are adequately accounted for apart from some form of content negotiation. Sure you can save some pixels using the Flash solution when a non-Flash device comes along, but I don’t know that the savings really improves the experience any for people on these devices. On my Cingular 8125 I turn images off completely since they tend to cause loads of problems on almost every site I browse to.

    In the end I think content negotiation, extended support for the media attribute for link elements and the @media CSS selector are the best solutions for handheld devices. But that’s a whole other issue: “ALA – Pockect-Sized Design”:

  26. It never ceases to amaze me how some people will make assumptions about Flash that simply aren’t true. The best (and perhaps the only good) argument against using this technique is simply saying something like “I’d rather just stick to nice, simple IMG tags”.

    Any talk of content getting “locked away in proprietary formats” is bunk. First of all, the SWF file format is open… not proprietary. Second of all, what’s the downside again? I don’t get it. You’re complaining because you can’t right-click to download the image you probably don’t even have the rights to? If the creator wants to let you do this, they can easily add a much *more* functional right-click menu which allows you to download even a high resolution version of the image (as mentioned by a previous commenter).

    I don’t mind debates like these. I really don’t. I just wish naysayers would stick to the points which are actually valid and meaningful in the real world (of which there are always a few).

  27. Checking if flash is installed is not enough. In fact I don’t know if there’s anyway that javascript could check to detect the causes of my problem, where flash is installed, isn’t blocked by anything, but just simply doesn’t work.
    In any case, it’s not future proof. What if Adobe _never_ decide to support 64 bit systems? Unlike using some fancy DOM feature or html tag which all browsers will support eventually (even if it takes 10 years), it’s very possibly that this will remain broken forever.

  28. For specialized cases, (i.e., my employer) I find Flash is a way to break out from the mundane. My company is more than a decade behind the times and just now discovering CSS and Javascript. ALL of my clients are on dial-up and old browsers. Our server is ruled by the IS department on the other side of the building, no server-side technology allowed.

    The only option I currently have to develop better services for my clients comes in the form of Flash (Hooray! We are at a 90% adoption rate for Flash Player 7!) and Javascript. While I was aware of SlideShowPro, sIFR is going to open up a whole new design element for my clients.

    While I see the downsides for those who develop for a general audience, it should also be noted that Flash is a powerful tool and a real, deliverable solution for the few of us remaining in the dark ages of server technology resources.

  29. “Micah Wylde”:#32:

    bq. I think our primary goal as web designers is to make our content as accessible and stylish as possible.

    Really? _Stylish_? I agree with the first part of that statement, but I definitely don’t feel that a web designer’s goal is to make content stylish. Design is so subjective that, if that was the end goal, we’d all be overworked and underpaid. Design is about communicating effectively, not drawing pretty pictures, but that’s another discussion in itself.

    In “another comment”:#34, you state that:

    bq. The problem is that this technology is *less* accessible than server side image creation.

    I’m not sure how you came to that conclusion. An HTML(Hypertext Markup Language) image is accessible through its @alt@ text, and the same options can be enabled from within Flash. Accessibility comes from the markup, not from where the image was generated.

    bq. With flash only those who have flash can see them, while the rest of your viewers see the plain images.

    Isn’t that textbook “progressive enhancement”:

  30. There was no way for the browser to tell that the flash file wasn’t being served because the plugin was there…

    I wonder if there is a way for javascript to ask a SWFObject if it’s file was loaded. Then it could have an interval and if the file didn’t load it could unreplace the flash content with the original image file.

    This is an intresting way of doing things. mirroring may not be the best example as this kind of image manipulation is fairly easily done server side, however things like smooth scaleing and complex masking and a whole host of other things that flash can do and HTML can’t do as well make it a technique worth refineing.
    AJAX has done alot for non flash multimedia but it dose not mean that one shouldn’t use flash when it is the best solution.

  31. Why are so many people here missing the point of the article by nitpicking apart the example? The author has admitted that this was not meant for a production level, but to illustrate the point. While yes, before delivering to a client their should be enhancements made to the JS and the Flash file to add things such as flicker reduction by adding the event when the DOM is loaded and not wait for the page to finish loading, Flash detection, better right click functionality, etc. but I don’t think it’s necessary for an ALA article to give a full production level in order to prove Flash’s benefits.

    That said, I wouldn’t frown upon it if someone took the time to improve on the example so that it was production level. 🙂

  32. I’m not sure why flash is the best option for many circumstances mentioned by other respondents. One brought up smooth, scalable images. SVG is the way to go there. I’ve always seen Flash’s strong suit being in animations and compact, graphics-intensive web apps (i.e. Google Finance). Maybe it’s because I’m a Linux advocate and don’t like depending on proprietary technologies.

  33. you are doing that the hard way… DOM is DUM with a visual tool such as flash.
    why not build a custom flash file that takes a jpg (from the URL of the swf file object code) and loads it in a movie clip which is flipped and faded?

    thats just what I would do, it would be much simpler, would not involve javascript and would alow the image to be displayed if they don’t have flash installed.

    learn flash properly, you are seriously doing this the hard way but awesome article none the less 😉

    – Oliver

  34. Just wanted to put my two pen’orth in with regards to Flash and accessiblity. People with learning disabilities, for example, find improved access when there is richer content such as subtitled video, animations and graphically rich interfaces.

    While much of this can be delivered through XHTML / CSS / JS, Flash provides an excellent way to create a more immersive, responsive and, therefore, accessible user interface for this user group. That’s not to say that entire flash sites a la fashion houses are a good idea, but that some element of flash on a page can help communicate to a wider audience.

    As has been pointed out, Flash’s accessibility comes down as much to the skill of the programmer as it does the nature of the technology itself and, as this applies to all web design technologies, I don’t see why Flash can’t be regarded as another valid tool in the web designer’s arsenal if implemented properly.

  35. “Mike Davidson claims”: that ‘the SWF file format is open”¦ not proprietary’. For what meanings of ‘open’ and ‘proprietary’ is this statement true? The SWF file format is owned by Adobe. They licence it to developers who wish to make software that exports to SWF. “They do not licence it to developers it to people who wish to make SWF players”: . That is why GNash (the GNU Flash player) must be produced by a slow and painstaking process of clean room reverse engineering.

  36. One more example. When planning my portfolio site “ (”: , I wanted a synergy between the lightness and usability of web standards and the powerful media display of flash. I am using JavaScript, xml, dynamic flash, and php for the seamless display of all information into one page. It works for several reasons:

    ** Portfolio content for both the site’s flash and its accessible no-flash version is updated very easy with php-script xml edits.

    ** Images are read, resized, thumbnailed, and added directly from an ftp directory with a php/xml script.

    ** Search engines read the content of the entire site into one page, with higher performance in pertinent searches, more than if it was split in several pages.

    ** Loading time is much faster since everything is a single page and users browse other sections while the heavier, flash part, loading simultaneously is loaded and ready by the time the visitor gets to that section.

    There are many ways to combine these technologies, and incorporating semantic flash can add some fantastic benefits that cannot be refuted.

    P.S. AmfPHP is another tool that is now used to connect flash with php for CMS and application purporses.

  37. Well, let’s see what semmantic flash wants to acomplish:

    * In ausence of flash and javascript, static content
    * Standard compliant
    * Search engine friendly
    * Crossbrowser

    It’s this possible?

  38. “Yaoltzin Gómez”:#53: If I’m understanding your question correctly, there are many sites out there that can achieve the ability to integrate Flash into a standards site.The “web.burza”: site is one example of a site that contains all of the attributes you mentioned. Is that what you mean?

  39. I think “Brian”: sums up the point very nicely: swell example, but give us _perfect_ and _useful_.

    Because I certainly can’t do it myself.

    And that’s ultimately what it comes down to, when you point out the chasm between web and Flash designers. Many posters have raised the objection that Flash is convoluted. Poor argument. Stick to the simple fact that it’s hard.

    It would take me at least 6 months to gain proficiency in Flash. And even with that commitment, I may never have the knack for animation or the artistic flare to excel at it.

    Also, it’s expensive. Five years ago, I bought Flash 4 to bulk up my resume. Two-hundred dollars of obsolete, sitting on my shelf. That skill set is dead, unless I pay for an upgrade and hope that I learn faster than the next version can come out.

    Whereas, the HTML I’ve been using all these years is free to program, and as the “other article from this issue”: proves, my crappy code from five years ago is just as relevant as my sleek code of today.

    Deceptively simple evangelizing of Flash obscures the fact that deceptively simple tools like “sIFR”: and “swfIR”: took _teams_ of skilled professionals to architect. So when I–the tech guy–want to tweak it, I end up just like “Tor”: is…

    Obviously thrilled with the concept, but reduced to screaming about two minor technical points that I can’t fix myself.

  40. Very true and thoughtful analysis of the current love/hate-Flash situation. Completely agree.

    The only point I would add is that Flash’s biggest problem is being a proprietary system. Any way you look at it – Adobe controls it. It is and will be hard a format maintained by just one company to truly become a standard.

    And then there is PDF, also from Adobe, that is somewhat of a standard. So – it’s not hopeless.

    It will be interesting to observe and see how things go. IMHO, current status-quo will be kept. Neither AJAX or Flash (with its Flex wing) be able to win over. Both will stay and people utilizing them smartly in proper cases, will win – just like this article says.

  41. We’ve been using Flash as an enhancer to websites for about a year now and are pretty darn happy with the results. We start with a basic HTML/CSS site and then take blocks of the site and add in Flash elements that include varying levels of interaction. For users without JS or Flash, they get the fully functional (and still good-looking site), but users with Flash and JS will get the added interaction available in the Flash pieces.

    Here are two sites that we’ve done this way:
    “Moose Racing”:

    In the past, we’ve felt the pain of building all-Flash sites (SEO, maintainability, etc) and have learned our lesson. This solution allows us to provide our clients with the best of both worlds.

  42. bq. Forgive me if I’ve completely missed the point but using flash just adds something you don’t need. What’s wrong with the javascript approach that everyone else is using. Surely less is more.

    Of course you could do this without Flash, but that’s not the point. Dan is simply showing us that Flash can nicely compliment an XHTML site when applied intelligently. It’s simply up to us, the designers, to be smart and take advantage of Flash’s strengths.

  43. This was said by someone else above but I think it went unnoticed so I’d like to reiterate it. There’s no need to replace the entire image (in this case) with flash. Admittedly, since it was an example, in general there may be no other option. But in this case, and any other case where the “semantic flash” is only adding to the existing content, wouldn’t it be smoother and degrade better if the reflection was added below the regular image? This would solve the complaints about not being able to right click as well as the blinking replacement. (Of course, it doesn’t stop someone from downloading the image itself if that’s what you actually wanted. But that really annoys me so I won’t consider it.) Of course, you have to make sure that you had a place holder of the same size (could just be a solid background color) so that the page doesn’t have to adjust dramatically (and cause even more confusion for users who don’t care how cool your reflection is).

  44. Specialized applications such as google analitics, yes, use flash or whatever means necessary to get the job done. You are more or less is control. “Get the plugin or else find a different solution”. For the the rest stick with xhtml and server site solutions.

  45. There is no such thing as “unnecessary use of flash”. Flash is not against everything the internet was intended for. It is a front end tool that allows for more dynamic presentation of materials from the simple and flashy (movie websites) to advanced portals (read:

    I would think in 2007 we had gotten passed this anti-Flash debate. It’s so obviously skewed by a bias against the “hype”, “style” and “flash” (pun intended) that the application brings.

  46. Just wanted to throw my hat in the ring.

    Leaving along the issues of when/whether to use Flash, here is how we have been approaching the challenges of semantic static content powering a richer interface

    From time to time on client projects we have encountered technology limitations that have constrained us from utilizing a server-side solution. Systems like this have been lifesavers in crunches of that sort.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA

Nothing Fails Like Success

Our own @zeldman paints the complicated catch-22 that our free, democratized web has with our money-making capitalist roots. As creators, how do we untangle this web? #LetsFixThis