Google wants to create a new language for the web. That idea will have to be accepted by all other browser vendors. Nowadays that doesn’t just mean Microsoft, Mozilla, Apple, and Opera, but also Nokia, Samsung, RIM, and a host of minor ones. Why would they do as Google tells them?

That’s his reaction to Google’s DART project. Also check out 2ality’s post which gives an overview of DART.

I pretty much ageree with PPK here. I am sure DART is awesome. I know a lot of smart folks worked on it. But I’m not convinced the web needs another front-end language, particularly one that is pushed by a single company. Even Adobe’s cross-platform, ECMAScript 4-compliant ActionScript is rapidly losing ground to the open web.

Flash, like JavaScript, more-or-less adheres to a same-origin policy by default. Under a same-origin policy, requests for data must come from the same scheme, hostname, and port. If http://foo.example tries to request data from http://bar.example, the request will usually fail.

Same-origin policies are designed to prevent the unauthorized leakage of data to a third-party server. Without it, a script or SWF hosted on http://mightbeevil.foo could read data hosted on http://goodsite.foo and send it to http://muhahahaevilsite.foo. This kind of cross-domain activity could be used to exploit cookie and authentication data. It’s clearly a bad thing.

Recent browsers have safeguarded against these kinds of cross-site scripting exploits by preventing JavaScript from making cross-origin requests. XMLHttpRequest, for example, will throw a security exception if you attempt a cross-origin request.

Flash, meanwhile has long supported a means for enabling cross-origin requests: the policy file. The policy file is a way of white-listing requests for data or credentials from specific origins. It lives on the server from which you are requesting data, and gives the Flash player a “yay” or “nay” when asked whether the request from a specific origin should be allowed to complete.

Cross-origin restrictions, though necessary, are also quite limiting. You can’t (or couldn’t), for example, request data for a mash-up using XMLHttpRequest. Though there are workarounds — using dynamic script insertion, or using the document.domain — those workarounds also leave the DOM vulnerable to cross-site scripting.

To to mitigate the dangers of cross-site scripting while still enabling it, the W3C is developing the Cross-Origin Resource Sharing (CORS) specification. It functions similarly to Flash’s cross-domain policy file, but uses HTTP headers instead of an XML configuration file.

CORS request headers are automatically generated by conforming browsers when a script attempts a cross-domain request. Response headers must be set in the server’s configuration file, or dynamically per URL using a server-side language.

Let’s compare a sample cross-domain.xml file to how we’d achieve the same thing using CORS.

Cross-origin requests from Flash

To use the domains from our example above, if http://mightbeevil.foo made a request to data hosted on http://goodsite.foo, http://goodsite.foo would need to permit the request by including mightbeevil.foo it in its policy file. For example:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
    <allow-access-from domain="mightbeevil.foo"/>
</cross-domain-policy>

This file must be stored in the web root of http://goodsite.foo. It explicitly permits mightbeevil.foo — and permits only mightbeevil.foo — to make requests for its data (from within a Flash movie).

Cross-origin requests from the DOM

To reuse our example from above, let’s use XMLHttpRequest to make a request from http://mightbeevil.foo to http://goodsite.foo.

var xhr, onLoadHandler 

onLoadHandler = function(event){
     alert('It is done!');
}

xhr = new XMLHttpRequest();
xhr.open('GET','http://goodsite.foo/data.json');
xhr.onload = onLoadHandler;
xhr.send(null);

It looks just like a regular XHR request, except for the fact that we’re requesting data from another origin. Let’s take a look at our headers.

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding:gzip, deflate
Accept-Language:en-us,en;q=0.5
Connection:keep-alive
Host:goodsite.foo
Origin:http://mightbeevil.foo
Referer:http://mightbeevil.foo/make_cross_domain_request/
User-Agent: Awesome/9.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) FantasticEngine/8889876 Awesome Browser/9.0

Notice that our headers include Origin:http://mightbeevil.foo.

Goodsite.foo responds with the following headers.

Access-Control-Allow-Origin:http://mightbeevil.foo
Connection:Keep-Alive
Content-Length:1349
Content-Type:application/json
Date:Mon, 26 Sep 2011 04:44:50 GMT
Keep-Alive:timeout=5, max=100
Server:Apache/2.2.20

Here we see that an Access-Control-Allow-Origin response header is returned by the server. Like allow-access-from, it indicates which domain(s) are allowed to make requests. Here, we want to know whether mightbeevil.foo is allowed to request data. It is, so the request will be completed.

Acceptable values for Access-Control-Allow-Origin include an origin (scheme + host + port), a comma-separated list of origins†, or a wildcard (*). As with cross-domain.xml, if the value of Access-Control-Allow-Origin had instead been http://notevil.foo, the request would have failed. Using a wildcard allows requests from any domain.

Of course, both specifications are more complex than what I have covered here. These examples illustrate how to enable a basic cross-origin request. It is also possible with both CORS and Flash to permit or exclude custom headers. And in the case of CORS, it is possible to use methods such as PUT or DELETE if the user agent supports it.

Learn more

• Flash cross-domain policy file specification
• Cross-origin Resource Sharing
• XMLHttpRequest Level 2

† Most browsers do not yet support multiple origin values. The specification is also a working draft, and subject to change.

Now I work almost exclusively with JavaScript, HTML5, CSS, and occasionally SVG. I haven’t touched ActionScript in any serious way for close to a year. But working on those projects was “training” of sorts. And it served me well.

It’s an open secret that HTML5* evolved to kill Flash. Many of the features of HTML5 and technologies such as XMLHttpRequest, Level 2 and Cross-origin Resource Sharing have parallels in ActionScript 3.0. The front-end stack, in other words, is gunning for Flash. And it will happen sooner rather than later.

ActionScript developers may cringe at that news, but I don’t think they should. I strongly believe that AS3.0 developers are better positioned than the rest of us to be leaders in front-end stack development. Problems that most JavaScript developers are learning how to think about — reading and manipulating bitmap data, doing object hit testing, making cross-domain requests, — ActionScript developers have been doing for years.

Of course, this is all provided ActionScript developers are willing to make the switch.

To that end, I’m starting an ongoing (but occasional … perhaps very occasional) series of blog posts detailing some of the commonalities and differences between ActionScript 3.0 and the HTML5 Stack. I am calling it HTML5 for ActionScript 3.0 Devs, even though it isn’t just about HTML5.

Sometimes they’ll be deep dives. Other times they’ll be shallow ones. It is quite possible that I will misunderstand aspects of both (that’s what comments are for). My goal here is less to be comprehensive than it is to encourage developers to learn more about these topics.

*Of course, I am using “HTML5” as a short hand for HTML5, CSS3, JavaScript, the Document Object Model, Scalable Vector Graphics, and several other web technologies and specifications.

ActionScript sounds like a weird choice, right? It’s client-side, not server-side. You can’t connect to a database or create files on the fly without some sort of middleware. And why would I suggest that budding programmers learn a dying language? HTML5, CSS3, and JavaScript are going to (eventually) take over the world, right?

That stuff is true, or will be in the near term. Yet I still think ActionScript 3.0 is worth learning, and that it’s a great starter language for budding developers. Here’s why.

• ActionScript 3.0 is syntactically similar to other C-style languages. Curly braces rule! Semi-colons are awesome! Getting comfortable with how AS3 looks and works will make PHP or Java less intimidating.
• ActionScript 3.0 is strongly-typed. Strongly- (or strictly-) typed languages enforce rules for variable behavior. It’s particularly useful when debugging, and will help you understand what different variable types are and how they work across languages.
• ActionScript 3.0 is Object oriented. Objects are at the heart of several programming languages, and supported in several more. Getting comfortable with how OOP works in AS means it is easier to understand how it works in JavaScript, Ruby, PHP, and Java. In fact, ActionScript is in some ways similar to Java in how it’s structured.
• ActionScript 3.0 is a dialect of ECMAScript. So is JavaScript. It’s remarkably easy to switch between the two, which brings me to my next point.
• ActionScript 3.0 and Flash documents have a Document Object Model (DOM). Think of a Flash FLA as an HTML or XML document and ActionScript as the JavaScript that manipulates it. If you’re comfortable working with ActionScript objects and hierarchy, learning how to manipulate the HTML DOM is a breeze (and vice-versa).
• ActionScript 3.0 supports Local Shared Objects, which is similar to HTML5 storage, and other key-value based datastores. Yep. Local storage “super cookies” have been available in Flash for years now. Learning how to use them in Flash and ActionScript will help you transition to an HTML5 future. What’s more, key-value datastores are the next wave of databases. The data structure for a “NoSQL” store is similar to those for a local shared object.
• ActionScript 3.0 supports event-driven programming. Event listening and handling is critical to game development or interactive experiences in which the sequence of user input can’t be (or shouldn’t be) controlled. Knowing how to generate, add and remove elements from the stage, or when an item can be safely garbage collected are portable concepts that you can learn with ActionScript.

My point with this post isn’t to start a language holy war. I’m not even sure I like ActionScript, plus my first programming language was actually PHP. Still I recognize that the way ActionScript works and as importantly, how it’s used provides a nice foundation for beginning developers.

Our player doesn’t just simply stream video, it must also secure the content, handle reporting for our advertisers, render the video using a high performance codec to ensure premium visual quality, communicate back with the server to determine how long to buffer and what bitrate to stream, and dozens of other things that aren’t necessarily visible to the end user.

In February, I offered four reasons why you shouldn’t count Flash out just yet. Eugene Wei Hulu.com‘s Vice President of Product offers four more in his post Pardon Our Dust about Hulu’s new video player (Via New TeeVee).

Thank you Mr. Wei for writing a follow-up post for me. HTML5 is great way to deliver audio and video to the browser in a way that frees users from having to install a plug-in. What it isn’t so great for — yet — are the things that many content creators and advertisers find important: tracking, DRM and ad serving.

Here’s a business suggestion for Hulu: offer an HTML5 player as a premium upgrade. Hulu plans to charge $10 per month. What if they offered — for, say, an extra $5 or $10 — “iPad-ready” video using HTML5?

Check out Hulu’s video introducing the new player.

Lately, the day job has had me busting booty on a Flash/ActionScript project that makes considerable use of the ExternalInterface class.

ExternalInterface allows Flash to communicate with its HTML container using JavaScript. It’s a groovy feature, but one that changes the development process a bit. Unlike straight-up Flash development, ExternalInterface requires you to test interaction between the movie and its container.

One way to do this is using the Firebug console. Set up a simple debug function embedded in your HTML or in an external JavaScript file: function debug(data){ console.log(data); }. Then pass troubleshooting data to it using ExternalInterface.call('debug','data you want to write'); just as you would with trace().

I even used this technique to dump XML data to the console. Works amazingly well.

A minor drawback: compiler errors won’t be written to the console. Instead you will see a generic error message, and your movie won’t load.

Using Flash Tracer

For a more robust option, try Flash Tracer, a Firefox extension by Alessandro Crugnola. Flash Tracer uses native Flash logging to deliver trace() messages directly to the browser. To use it, you’ll need to install a debug version of the Flash Player.

Using LiveHTTPHeaders

Sometimes when sending and receiving data to and from a server, you can’t tell what’s wrong by looking at your Flash application. There could be an error in your server side code. Or perhaps there’s a problem with the data you’re sending. This is where LiveHTTPHeaders comes in handy.

LiveHTTPHeaders shows both browser-and-Flash request headers and server response headers. It also sends encoded GET and POST data from HTML forms or ActionScript URLRequest() / URLVariables() / URLLoader() operations.

This extension won’t show the actual data the server has returned. But you can use it to spot things like invisible line break characters and internal server errors.

Related posts:

• Essential Firefox Extensions
• My new favorite Firefox extensions
• Clearing LoadVars() in ActionScript
• OurIndustryIsBroken.com: Tracking site users and traffic with PHP, MySQL and ActionScript

LoadVars() can be problematic, however, if you ever find yourself reusing the same object for repeated load() or sendAndLoad() operations. As explained in the ActionScript 2.0 Language Reference:

Downloads variables from the specified URL, parses the variable data, and places the resulting variables in my_lv. Any properties in my_lv with the same names as downloaded variables are overwritten. Any properties in my_lv with different names than downloaded variables are not deleted.

In other words, if you continue reusing the same LoadVars() object, you’re going to have more data floating around than you may need at a time. Let’s take a look.

First we’ll request a file containing variables with a load() operation.

var bucket:LoadVars = new LoadVars();
bucket.load('vars.txt');

The file vars.txt looks like this:

content1=The+quick+brown+fox&content2=Jumps+over+the&content3=lazy+dog.

Each variable (that bit to the left of the = sign) becomes a property of your LoadVars object (bucket), and each variable’s value becomes a the value for that property.

If we iterate through bucket using a for loop when the variables are loaded, we’ll see that content1, content2, and content3 are now properties of bucket.

bucket.onLoad = function(){
     for(i in bucket){  trace(i+': '+bucket[i]+"\n"); }
}

Outputs:

content1: The quick brown fox
content2: Jumps over the
content3: lazy dog.
onLoad: [type Function]

Now let’s say we need to send a variable to our server and retrieve some new results. We’ll do a sendAndLoad() operation, and store the results in the same bucket object.

bucket.username = 'cleophus';
bucket.sendAndLoad('morevars.txt',bucket,"POST");

The data received from morevars.txt looks like this:

firstname=Dwayne&lastname=Wayne&major=math

If we execute another for loop, once the data is loaded, we’ll now see that there are more properties stored in LoadVars().

bucket.onLoad = function(){
     for(i in bucket){  trace(i+': '+bucket[i]+"\n"); }
}

Now outputs:

content1: The quick brown fox
content2: Jumps over the
content3: lazy dog.
username: cleophus
firstname: Dwayne
lastname: Wayne
major: math
onLoad: [type Function]

Any more load or sendAndLoad operations will only add properties to the object unless you overwrite them — or delete them.

Before deleting anything from your LoadVars object, however, copy the properties and values to another variable. Arrays and objects are a good fit here. You can create an array that only copies the variable-value pairs that you need to keep, then delete each variable from the LoadVars object, emptying it for reuse.

function turnVarsToArray(sendAndLoadObj:LoadVars):Array{
	var loadVarsArr:Array = new Array();
	for(var e in sendAndLoadObj){
		if( typeof(sendAndLoadObj[e]) !== 'function'){
			var pair:Object = {vari:e, val:sendAndLoadObj[e]};
			loadVarsArr.push(pair);
		}
          delete e;
	}
	return loadVarsArr;
}

We’re using Google Analytics for high-level analysis such as referrals and search engine traffic. But we wanted to do more robust analysis. You see our conundrum, right? How do you track “pages” and visited “links” within a single Flash movie embedded in a single HTML page?

Simple: you build your own tracking system.

For this project, I used Flash’s LoadVars() object to talk to a PHP middle layer that writes and retrieves data to and from a MySQL database.

LoadVars() allows you to send (and receive) variables from a Flash movie to (or from) a server. You need a server-side script to process that information. Variables and values are sent to the server using either GET or POST. It’s just like submitting and processing a form — and should be treated like any other user-submitted data.

When you pass data from the server back to the movie, you send it as a query string, or an encoded URL (example: ‘car1=honda%20accord&car2=chevrolet%20tahoe’). Once the variable-value pairs are loaded into the movie, you can use ActionScript to determine how the movie handles that data.

The PHP scripts and the database

There are two PHP scripts at work here. One collects the data from the movie, escapes it, and writes it to the database. The other retrieves data from the database, encodes, and returns it to the movie. We’re also using three separate database tables.

Table one contains the questions and answers contained in the movie. Each question and answer corresponds to a key. The next table tracks section visits in the aggregate. One column contains the keys from the questions and answers table. The other column keeps track of the count. I set an initial value of zero for each question-and-answer key in that column. Every time a section is visited, we update the count for that section by one. If we were using MySQL version 4.1 or later, we could have used the ON DUPLICATE KEY clause for INSERT. Instead, we’re using UPDATE syntax and adding one to the value of the count column.

The third table is where we store per-user data. We’re using server-based sessions to track visits by user. With each click, we capture the section being visited, the current session identifier, the user’s IP address and the time of the click. Collecting this user data allows us to do a few things:

• Determine where our visitors are coming from.
• Determine roughly how long people are staying on the site.
• Determine which section(s) the user has visited (and their answers).

That last portion is probably the coolest. At the end of each section of the movie, we return the user to a main menu. When that screen is loaded, a script queries the database to find which sections have been visited in that session.

Once MySQL returns those section keys, we build our query string. In my PHP code, I set each section variable equal to 1 (i.e. ‘section1=1&section22=1′). We pull this query string into our Flash movie by once again using LoadVars().

After these variables are loaded, we can use ActionScript to make the movie take a particular action. In this case, I tested to see whether the variable exists (example: if(section1){scroll_mc.gotoAndPlay(23);}). If it does, the movie goes to the scroll movie clip and plays from frame 23. If it doesn’t, the scroll movie clip plays from frame one.

All of this means we have some solid data to analyze both in terms of traffic and — because we’re tracking answers — how well our messaging is being received.

You can see the new tracking system in effect by visiting the site.

Speakers include John Maeda of of the MIT Media Lab and Craig Swann of CRASH!MEDIA. Session topics will include ActionScript 3.0, Flex and Designing with Sound.

Flashforward is produced by Lynda.com events.

You can read the rest of the post, or jump straight to the example (and maybe come back to the post afterwards).

Let’s say you have a Flash movie with a dynamic text field with an instance name of content. The ActionScript below assumes you will not be creating this text field at runtime, but that it is drawn on your stage. Set the html property to true so that it will properly display our HTML.

content.html = true; // make content accept HTML code.

You decide to load HTML into content using LoadVars(), and create a new LoadVars object.

var loadContent:LoadVars = new LoadVars(); // creates the object
loadContent.load('htmlfilename.html');           // loads the HTML

Your HTML content looks like this:

contentText=<p>This is some HTML content. And <a href="javascript:doSomething()">this</a> is a link.</p>

I should probably explain this, eh? LoadVars does what its name suggests: it loads variables. You pass the variables just as you would if you were constructing a query string for a URL.

varName1=The first variable value&varName2=The second variable value

Typically, if you were constructing a query string, you would use + instead of spaces. If you were using PHP, you would probably encode the string using urlencode(). But when using HTML, encoding the string will leave you with raw code in your text box, </> and all.

In the above example, contentText is the variable, and <p>This is some HTML content. And <a href="javascript:doSomething()">this</a> is a link.</p> is its value. Note the javascript:doSomething() function.

So back to the ActionScript … Now we’ve got to assign the value of contentText to the content box:

/*
Once the HTML document (htmlfilename.html)
finishes loading, it will execute the function below.
*/
loadContent.onLoad = function(){
      content.htmlText = this.contentText;
}

Now in the HTML file that contains your Flash movie, define a function known as doSomething().

function doSomething(){
   document.getElementById('headline').style.color = '#33ccff';
}

Now, when you click on the link in the HTML loaded into your Flash document, it will activate doSomething().

An editor’s note: If you have a question about this technique and its possible applications, DON’T ASK ME. I (probably) can’t help you. I’m not an expert on using HTML and JavaScript with Flash. I just stumbled across this on the way to something that will be greater if I can ever figure it out.

I’m partial to two methods:

1. Using JavaScript to write the object and embed tags, and providing a <noscript> alternative, such as a static image.
2. Using the object element, and embedding alternate content (perhaps a still image from the animation) within the object.

Both options validate completely — even with the invalid<embed> tag in the first version. But, because of the way Internet Explorer, handles ActiveX controls, the second method creates a user experience problem.

I can’t vouch for the accessibility of either method. But they are two more options for embedding Flash (and other multimedia) content.

Related posts

• Get ready for the next version of Internet Explorer
• Flash, validation and the latest versions of IE

• “An Indepth Look at ActionScript 3” by Daniel Dura
• “Building Commercial Sites with Streaming Content” by Daniel Kremsa
• “Cell Phone Interactivity: Harnessing the Universal Input Device” by Jacob Bullock
• “Creating Flash Lite 2 Video Applications” by James Talbot
• “Everything You Always Wanted to Know About Game Development But Were Afraid to Ask” by Francis Bourre
• “GMUNK+HOLLYFUNK06” by Bradley Grosh
• “Making IM Plugins with Flash” by Justin Everett-Church
• “Optimizing your Streaming Flash delivery” by Thierry Curis

First, the XML:

<alldots>
  <dotname id="bigDot" color="0xff0000" url="http://www.fletchermartin.com/" photos="8" />
  <dotname id="otherDot" color="0x000066" url="http://www.ajc.com/" photos="8" />
  <dotname id="thirdDot" color="0xCC0099" url="http://www.tiffanybbrown.com/" photos="0" />
</alldots>

Then the ActionScript (commented for your learning pleasure):

var dots:XML = new XML();
dots.load('bigdot.xml');

dots.onLoad = function(success:Boolean){
	if(success){
		if(dots.status == 0){
			 var dotsToXMLString:String = new String(); // initializes a new string variable
			 dotsToXMLString = dots.toString(); 		// converts dots XML object to a string and stores it in dotsToXMLString.

			 var dotsXML:XML = new XML(dotsToXMLString);// creates new XML object with the string contents from above.
			 dotsXML.parseXML(dotsToXMLString);			// parses the string from above.

			 var dotsNodes:Object = dotsXML.firstChild; // Saves the firstChild (in this case, the outermost element) as an object
			 var dotsNodesChildren:Object = dotsNodes.childNodes; // Saves the childNodes of firstChild as an object

			 for(i=0;i<dotsNodesChildren.length;i++){
				var newObj:Object = dotsNodes.childNodes[i].attributes.id; // creates a new object out of the child node's id.

				var newObjColor:Color = new Color(newObj); // creates a new color object with newObj as its target
				var theColor:Number = dotsNodes.childNodes[i].attributes.color; //retrieves the hex code value (number) of the attribute color

				newObjColor.setRGB(theColor); // sets the RGB value of newObjColor.
			}

		} else {
			trace("Problem parsing XML.");
		}
	} else{
		trace("Could not load XML");
	}
}
 

View everything in action, or download the .fla, and XML files.