"Flash Rules"

I’m duplicating my comments from the post “Flash Rules” over at QuirkeyBlog here, as I think they are a pretty good summary of my thoughts on Flash and “HTML5″ at the present time. Aaron makes some great points, and is really fair with his assessment of the current situation. most of the comments are pretty balanced too, aside from the usual injection of zealotry.

I strongly encourage anyone who feels strongly about these issues to go and comment over at his blog in support of his honest attempt at cross-platform dialog.

Great perspective article. Really enjoy reading a level-headed assessment of the current opinions surrounding Flash.

Flash, as a platform, reaches across a variety of devices and environments. It isn’t just ads, video, or even Web. A lot of articles critical of Flash never mention this. I’ve been working with the platform as my primary focus for over 10 years and have only made a banner ad with Flash once (and that was many years ago). Most of the Flash work I do these days for the Web is to build up modular functionality just not possible any other way. Most of my development projects are now done outside of the browser on desktops and mobile; all using Flash Platform tech.

HTML, on the other hand, is also beginning to seed across devices and environments. Already well beyond the traditional mark-up usage it was intended for. Now that HTML5 (along with CSS3 and JavaScript) is picking up some of the functionality that has been in the Flash realm for years- it can only be a good thing as choice is fundamental to the Web.

Flash developers have no need to worry as the platform has expanded to envelope much more than what it has been known for. HTML developers should be grateful to Flash for pushing the Web forward and encouraging growth in HTML, CSS, and JavaScript. It’s mutually beneficial :)

I’ll also note that most Flash developers are also quite well-versed in other languages and platforms simply because of the nature and history of Flash. We are no strangers to HTML!

It’s really too bad we don’t see more level-thinking along these lines from the big tech sites who always seem to make it an all-out war between Flash and HTML. It’s not a war. Not even a battle. More like a one-sided quarrel that’s gone on far, far too long now.

I am humbled to have my statement included alongside so many others:

Ever since the inception of this debate, I’ve held the position that the majority of dialogue around “HTML vs. Flash” is an intentional misrepresentation of facts and usage. There is no better example of this than Steve Jobs’ counterfactual letter, “Thoughts on Flash”; a message clearly designed to provide ignorant media outlets and technology zealots with cleverly crafted soundbytes used to encourage a position against Flash as a viable platform on the web and on devices.

HTML5 is the natural progression of the HTML specification. As such, it poses no threat to the Flash Platform because HTML and Flash have always existed as complimentary technologies. Why would anyone expect HTML, as a specification, to stand still? In my opinion, it has done so for far too long and is overdue an abundance of rich, new features. Does this in any way harm Flash as a platform? Of course not; Flash advances at a much faster rate than HTML, unrestrained by standards bodies and bickering between opposing corporations. The addition of capabilities with HTML only augments embedded Flash in the browser, as these new capabilities (geolocation data, for example) can be fed into a Flash interface through local connection or via initialization variables.

I actually find it humorous that the fate of Flash is called into question at this time of great advances. Flash Player 10.1 took a long time to emerge since a massive rewrite was required to allow a good experience across desktops, mobile devices, and eventually the digital living room. Now that this foundation has been set, we are seeing some startling growth across numerous areas of platform implementation. The beginnings of which can be seen in the upcoming 3D “Molehill” APIs, the super-performant StageVideo classes, the first glimpses of multi-threading, and upcoming 64-bit runtimes across Windows, Linux, and Mac OS. This doesn’t even consider advances in the AIR runtime and associated frameworks.

It’s a great time to be a Flash developer – and a great time for HTML too!

Read more statements at ActiveTuts+

Java JSP example

1
2
3
4
5
6
7
8
9
10
11
12
13

String embedCode1 = item.getEmbedCode();
 
String expression1 = "><param";
String replacement1 = "><param name=\"wmode\" value=\"transparent\"><param";
String embedCode2 = embedCode1.replace(expression1, replacement1);
 
String expression2 = "<embed ";
String replacement2 = "<embed wmode=\"transparent\" ";
String embedCodeFinal = embedCode2.replace(expression2, replacement2);
 
<div class="embedHolder">
	<%=embedCodeFinal%>
</div>

What am I talking about? You can read up on my original article if it pleases you.

Here’s the thing… what if your application allows users to embed SWF content from YouTube, Vimeo, and other such services? What if your system generates little edit menus that happen to overlap such content? These services generally do not include the proper WMODE values to allow dynamic overlays. If you are just accepting SWF embed content, it’s a simple task to just parse the embed string and store the necessary values in your application to spit back out later using your own embed code formatting. What if there are just too many unknowns about the content your users may need to embed in the application? What if you also accept plain HTML embeds from services like Twitter and Facebook or other non-SWF content that you cannot parse attributes from so predictably? Then you need to do some more tricks to get that WMODE parameter set for any potential Flash content!

I use jQuery quite a bit when I absolutely need to deal with Javascript and like how it keeps the code from getting out of hand. It also provides a ton of extra functionality that is really useful when trying to identify certain elements in your HTML document for manipulation. I’d already tagged any user embed containing elements with a class of “embedHolder”, so using jQuery it would be super simple to identify all user embedded elements. So the original plan was to use both append() and attr() to modify any object or embed tag nested within any of these tagged container elements in order to add the necessary WMODE parameters:

1
2
3
4

$(document).ready(function(){
	$(".embedHolder object").append('<param name="wmode" value="transparent">');
	$(".embedHolder embed").attr("wmode", "transparent");
}

This doesn’t work though! It will certainly go through and modify the elements as needed, but since the SWF content has already been drawn into the viewport, the WMODE parameters are ignored. Thankfully, jQuery is super-awesome and includes both a show() and a hide() method. When you use hide() on an element, it will remove it from the viewport. Using show() will make it visible again. this effectively forces the browser to reload and redraw the SWF content, this time taking the WMODE changes into account perfectly.

1
2
3
4
5
6
7
8
9

$(document).ready(function(){
	$(".embedHolder object").append('<param name="wmode" value="transparent">');
	$(".embedHolder embed").attr("wmode", "transparent");
	$(".embedHolder").hide();
 
	//a bunch of other code you may have
 
	$(".embedHolder").show();
}

Awesome!

UPDATE 1: Errr… awesome in some browsers. As Josh points out below, the actual behavior differs quite a bit between browsers. No problem- I have a plan and will update this tomorrow with a solution. (hopefully!)

UPDATE 2: Yeah- IE is the only problem browser I’ve come across. Surprised? No.

UPDATE 3: Here is a solution for all browsers (even IE!):

1
2
3
4
5
6
7
8
9
10

$(document).ready(function(){
	$(".embedHolder object").append('<param name="wmode" value="transparent">');
	$(".embedHolder embed").attr("wmode", "transparent");
	$(".embedHolder").each(
		function () {
			var cont = '<div class="embedHolder">' + $(this).html() + '</div>';
			$(this).replaceWith(cont);
		}
	);
}

Now we are explicitly removing elements from the DOM and then reloading them into the same node, forcing the browser to redraw the SWF and activate the proper WMODE.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
<mx:Script>
<![CDATA[
 
import mx.core.mx_internal;
 
public function textHandler(e:Event):void
{
    var styleSheet:StyleSheet = new StyleSheet();
    styleSheet.setStyle("a:link", { textDecoration: "underline", color: "#30F" });
    e.currentTarget.mx_internal::styleSheet = styleSheet;
}
 
]]>
</mx:Script> 
 
 
<mx:Text initialize="this.textHandler(event)">
    <mx:htmlText>
    <![CDATA[
        You may <a href="">click</a> here.
    ]]>
    </mx:htmlText>
</mx:Text>
 
</mx:Application>

Apparently, this should not be used with any degree of reliability so far as future-proofing is concerned since the mx.core.mx_internal class may flux between versions of the Flex SDK.

Listed in the rumored Flex 4 improvements are support for CSS descendant selectors, ID selectors, and space-delimited style names. Something like this should really be handled via CSS so here’s hoping that this will soon be a much simpler process.

Not sure if I’ll ever need this in the future, but in the case that I do- I know it’s here for easy access.