Both ActionScript and the front-end stack have mechanisms for sending data from a page or movie to a server without requiring a page refresh. In most browsers, we can use the XMLHttpRequest object. In Flash, that role is filled by a combination of the URLRequest, URLVariables, and URLLoader classes.

I know you’re probably thinking “Why are you writing about this now? XMLHttpRequest has been around for more than half a decade!” True, but XMLHttpRequest, Level 2 (XHR2) is still an emerging standard.

XHR2 is a huge expansion of the XMLHttpRequest API. It adds several new features — such as progress events, binary data, and cross-origin requests — and brings much of what Flash currently does to the browser natively.

In this post, I will give a quick rundown of sending basic text data using URLVariables, URLRequest, and URLLoader and how it compares to the new FormData interface. In a future post, we’ll look at sending files and binary data using both techniques.

Sending data with URLVariables

The example below is one you might create using FlashBuilder to create a Flash movie programmatically. The flash.display.Sprite class is imported by default. Since we’re going to make network requests, we will also import all flash.net.* classes.

package
{
	import flash.display.Sprite; // imported by default
	import flash.net.* // imports URL classes

	public class URLVars extends Sprite
	{
		public function URLVars()
		{
			/* create a new URLRequest object */
			var req:URLRequest = new URLRequest();

			/* create a new URLVariables object */
			var dataObj:URLVariables = new URLVariables();

			/* Create a new URLLoader */
			var fxhr:URLLoader = new URLLoader();

			/* Add object property-value pairs */
			dataObj.name = 'Jane Doe';
			dataObj.address = '1313 Mockingbird Lane';
			dataObj.City = 'Beverly Hills';
			dataObj.State = 'CA';
			dataObj.ZIP = '90210';
			dataObj.Country = 'United States';

			/* define the URL for the request */
			req.url = '/script';

			/* Set the request method. */
			req.method = URLRequestMethod.POST;

			/* Attach the data object to the request */
			req.data = dataObj;

			/* Make the request */
			fxhr.load(req);

		}
	}
}

When this request is made, the Flash user agent will automatically include a Content-Type: application/x-www-form-urlencoded request header since all of the fields included are plain text. If one of the included fields had been a file (using the FileReference or FileReferenceList classes), Flash would instead send a Content-Type: multipart/form-data header.

Sending data with a FormData object

Now let’s take a look at sending that same data using a FormData object.

/*
Create a new FormData object. This is
analogous to the URLVariables() object
*/
var data = new FormData();

/* Append each field as key, value */
data.append('Name','Jane Doe');
data.append('Address','1313 Mockingbird Lane');
data.append('City','Beverly Hills');
data.append('State','CA');
data.append('ZIP','90210');
data.append('Country','United States');

/*
Create a new XMLHttpRequest object,
which is analogous to the URLRequest object.
*/
var xhr = new XMLHttpRequest();

/* Open the connection, and set the method. */
xhr.open('POST','/script');

/*
Send the data. Roughly equivalent
to fxhr.load( req );
*/
xhr.send( data );

Notice again here that we are not setting a Content-Type request header as we would have to with XHR1. When you use a FormData object to send data, the browser will automatically include a Content-Type: multipart/form-data header. This is also why and how we can now (well, we will soon be able to) use XMLHttpRequest to send binary data and files.

Browser support

Browser support for XHR2 isn’t as far along as we’d like. Chrome and Firefox support most of the specification. At Opera, our development team is diligently working to bundle support into a future release. Microsoft plans to include support in Internet Explorer 10 scheduled for a 2012 release.

In the meantime, we can continue to send text data via XHR using URL-encoded strings. I’ll take a look at file uploads in an future post.

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.

Custom events are especially important in game development. Let’s say we were developing Pong using JavaScript. We might fire a bounce event when the ball reaches the side edges of the screen. And we might dispatch an out_of_bounds event if the ball gets past our paddle. Ultimately, they help keep us from misusing native DOM events.

Using custom events requires a shift in thinking about how you architect a game. But they’re terribly useful, and supported in the latest versions of every modern browser.

How to use? A simple snippet follows:

For more, consult the media events section of the HTML5 specification.

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.

classList makes it much easier to work with elements and class names. With it, you can:

• Add, remove, and toggle classes;
• Retrieve the class name at a specified index; or
• Check whether an element contains a particular class.

classList returns a DOMTokenList — a space-separated list of tokens — containing the class names currently applied to the element.

Its syntax is simple: elementNode.classList.methodname(arg) where methodname is either add(), remove(), toggle(), contains(), or item() and arg is either a numeric index (in the case of item() ), or a class name. classList also has a length property, which tells you how many class names have been applied to the element.

Let’s look at some examples.

LetsPretendWeAreBuildingANewsSite.net

Pretend we’re building the home page of a news web site. This means we have lots of lists of stories, each styled slightly differently based on their section and prominence. We’re also going to allow users to hide some lists of headlines. Which ones can be hidden is determined by a class name.

One of our home page lists, then, has three class names: hardnews (as opposed to say, celebrity gossip), business, and removable. The markup looks like this:

<ul id="bizheadlines" class="hardnews business removable">
	<li>Coca-Cola posts a Q3 profit</li>
	<li>Justin Timberlake invests in MySpace</li>
	<li>Google tries to get social (again) with Google+</li>
	<li>Southwest and AirTran airlines to merge</li>
	<li>Stocks can't decide whether they're up or down</li>
</ul>

Retrieving all classes on an element

If we wanted to retrieve all class names on our list, that’s an easy enough task:

var biz = document.getElementById('bizheadlines'); // could also use document.querySelector('#bizheadlines');
var bizclasses = biz.classList;
console.log(bizclasses)

The code above would write hardnews business removable to the JavaScript console.

Retrieving all class names on an element is only somewhat useful. You would typically use this to test whether the element has a class at all, or whether classList is supported by the browser. If document.body.classList == undefined, for example, you know that it is unsupported in that browser.

Retrieving a class name by index

Instead, let’s try retrieving the third class name in the list. Here we’d use item(n), where n is an integer between 0 and the number of classes minus 1 (element.classList.length - 1).

var biz = document.getElementById('bizheadlines');
var bizclasses = biz.classList;
console.log( bizclasses.item(2) )

Executing the above writes removable to the console. If a class name does not exist at that index, the value of bizclasses.item(2) would be null instead.

Adding a class name

Now, the real fun of classList is the ability to add, remove and toggle the class names of an element. So let’s say one of our users wants to hide our list. They can do that because we’ve specified that it is removable with the removable class. But removable only says that it can be removed. We need to add another class (hide) in order to remove the list from view. Meet the add() method.

var biz = document.getElementById('bizheadlines');
biz.classList.add('hide');

In order for this to work, of course, .hide must be defined in our CSS: .hide{display:none;}.

Note that you can’t add a list of space-separated values to classList. For example, document.body.classList.add('sports sectionfront') won’t work. You must instead add them one at a time, or use className.

Removing a class name

To remove a class name (maybe our user wants to restore that list of headlines) use the remove() method. It, like add(), accepts a class name as a parameter.

var biz = document.getElementById('bizheadlines');
biz.classList.remove('hide');

Here too, you need to remove classes one by one, or use className.

Toggling classes

Of course, since we’re just adding and removing a class name, we could just toggle it. As you’d expect, this is where we’d use the toggle() method.

var biz = document.getElementById('bizheadlines');
biz.classList.toggle('hide');

If the element does not contain the hide class, toggle() will add it. If it does, invoking toggle() will remove it.

Checking whether a particular class exists

What if you wanted to show a message only when the user tries to close a hard news headline list? Then you would want to check whether the element in question has a hardnews class. This is where the contains() method comes in handy.

// Get all removable lists of headlines
var removable = document.querySelectorAll('.removable');

var clickhandler = function(e){
	// if the current target has a 'hardnews' class
	if( e.target.classList.contains('hardnews') ){
		var cont = confirm("Hiding this will make you a less informed citizen. Are you sure?");

		if(cont){
			e.target.classList.add('hide');
		} else{}
	}
}

// apply the click handler
for( var i=0; i < removable.length; i++){
	removable[i].onclick = clickhandler;
}

In the above example, we have applied a click handler to all removable lists. If a user tries to remove a hard news section, we ask for confirmation. If they confirm, we will hide it. Otherwise, we won't.

See classList in action

Though decidedly not a news web site home page, you can get a sense of how these methods can be used together in this classList demo.

Browser support

Here's the caveat: classList is not yet supported in iOS Safari, or Internet Explorer 9 (it's unclear whether support will be available in IE10). In those cases, you will still need to use className or getAttribute('class') and manipulate it using JavaScript string methods and regular expressions. ]]> http://tiffanybbrown.com/2011/08/15/class-manipulation-with-classlist/feed/ 0 http://tiffanybbrown.com/2011/08/12/meet-the-selectors-api/ http://tiffanybbrown.com/2011/08/12/meet-the-selectors-api/#comments Fri, 12 Aug 2011 12:00:44 +0000 tiffany http://tiffanybbrown.com/?p=6125 DOM Scripting is sometimes clunky. Consider the retrieval of elements with a particular class name. The code might look like this:

var p = document.getElementsByTagName('p');
var newsitems = [];
var i;
for(i = 0; i < p.length; i++){
  if( p[i].className == 'newsitem' ){
     newsitems.push( p[i] );
  }
}

In the example above, we’ve retrieved all elements in the document using document.getElementsByTagName(). Then we’ve iterated over them, checking for the presence of the desired class name.

It’s ugly, right? That᾿s even more true when you look at the elegant, CSS-style selectors of libraries like jQuery and MooTools.

Code like that above is why the W3C developed a Selectors API. It consists of two methods on the document object: querySelector() and querySelectorAll().

querySelector() and querySelectorAll() both accept any CSS selector that the browser supports. All recent browser releases support both methods, though Internet Explorer 8 is limited to CSS2 selectors.

querySelectorAll(), as its name suggests, returns a node list of elements matching the given selector. querySelector() only returns the first matching element. You can pass any CSS selector as an argument, including ones like the adjacent sibling combinator and nth-child() if the browser supports it.

Let's re-write the above code using querySelectorAll().

var newsitems = document.querySelectorAll('.newsitem');

That’s much more concise. The newsitems variable contains only those elements with the newsitem class. Using the Selectors API greatly simplifies the code we need to use when interacting with the DOM.

Learn more

• Selectors API Level 1 Specification
• Selectors API Level 2 Specification
• CSS Selectors Level 3 Specification
• CSS Cascading Style Sheets Level 2 Revision 1 Specification

• Eloquent JavaScript
• JavaScript from the Mozilla Developer Center
• Microsoft’s Scripting Guide for Internet Explorer
• WebKit DOM Reference
• Opera Documentation (Look under Documentation → Web Specifications Support then choose the top-most Presto engine listed, currently 2.8)
• High Performance JavaScript by Nicholas C. Zakas et al. Buy from Amazon.com
• Pro JavaScript Techniques by John Resig Buy from Amazon.com
• Annotated ECMAScript 5.1 Specification

The progress event is fired as the browser loads more of the media file. It may not be fired reliably, however. Chrome, for example, will not fire the progress event if it has cached the video file.

Only Firefox provides a means to calculate the amount of the video that has been loaded. The progress event object includes total and loaded properties that reflect the total size of the video file, and the amount the browser has retrieved from the server. This is also a reflection of how each browser handles video downloads.

Firefox requests partial content on the initial page load, then pauses downloading until the play event is fired. After the play event is fired — whether when the user clicks the ‘play’ button or the video tag has the autoplay attribute — Firefox resumes downloading the video file.

Safari, Chrome, and Opera conversely, download the entire video on page load — they automatically buffer by default. Opera and Chrome, however, will make the video available for play almost immediately, while Safari takes several seconds to download a larger portion of the file. Firefox will behave similarly if when the autobuffer attribute is present.

Presumably because they auto-buffer video, neither Safari, Chrome, nor Opera offer a means by which to detect either the video’s size, nor how much of the video has loaded.

Some example code for handling the progress event (assuming we’re wrapping this video element in a <div> tag with an id of ‘container’). This will return the percentage of the video loaded in Firefox (and other browsers that don’t auto-buffer), and fail silently in other browsers.

var container = document.getElementById('container');
var video = document.createElement(video);
// only Firefox and Opera support Ogg ... oh yeah Chrome does too.
video.setAttribute('src','movie.ogv');
function progressHandler(e){
      if(e.total && e.loaded){
           // percentage of video loaded
          var proportion = Math.round( e.loaded / e.total );
          return proportion * 100;
      } else {
           // do nothing because we're autobuffering.
      }
}
video.addEventListener('progress',progressHandler,false);
container.appendChild(video);

Luckily for us, there is a very easy way to reveal the methods and properties of just about any element in the DOM. Experienced JavaScript developers probably know this. It’s possibly one of the most useful things you can know about using JavaScript: use a for-loop to reveal an object’s unknown properties and methods.

Let’s assume you have a div with an id value of “test.” Let’s also assume that you have Firebug, for Firefox installed (and enabled), or that you have enabled developer tools in Safari (this may work with Opera‘s Dragonfly as well).

To find out the properties and methods, for “test,” you would use the following code:

var p; // initialize this variable.

var testElement = document.getElementById('test');

for(p in testElement){
     console.log( p +': '+testElement[p] ); // using array notation for objects, which works just fine.
}

In Firebug, the output will look a bit like this:

That’s a list of every property and every method — and whether or not it’s a native part of the DOM (as supported by the browser) — available for this object.

Similarly, you can do the same thing with an event. Consider:

function clickHandler(evt){
      var p;
      for(p in evt){
            console.log( p+': '+evt[p] );
      }
}
testElement.addEventListener('click',clickHandler,false);

The code above would reveal all of the properties of the event listener (note that in Internet Explorer, you would use the attachEvent() method). This is how I learned that in Firefox, the progress event of the video element contains both “total” and “loaded” properties — which will come in handy for creating a loading progress display.

Now if you don’t use Firefox with Firebug, Safari (or Opera), you can also output the data to a <div> in your HTML page.

Web applications should have the ability to manipulate as wide as possible a range of user input, including files that a user may wish to upload to a remote server or manipulate inside a rich web application. This specification defines the basic representations for files, lists of files, errors raised by access to files, and programmatic ways to read files. The interfaces and API defined in this specification can be used with other interfaces and APIs exposed to the web platform.

From File API working draft by Arun Ranganathan of Mozilla Corporation.

This API, if adopted by major browser vendors will allow client-side file manipulation and asynchronous uploads.

As far as I know, asynchronous uploads are only possible now using a combination of Flash and JavaScript such as SWFUpload. Flickr’s uploader uses a similar technique. Client-side file processing is impossible without a plug-in.

/http:\/\/[\-\.\/\w]{1,256}(|\/)/gi

Having delivered a talk on how to write your own JavaScript library (detailed notes) at the conference, Dmitry shared his thoughts on the new library over breakfast the next morning. “Just what the world needs—another sucky JavaScript library,” he said. When I asked him what made it ‘sucky’, he elaborated. “It’s a JavaScript library written by Java developers who clearly don’t get JavaScript.”

For the rest of the day, to anyone who would listen, Dmitry cited example after example of the terrible code he had found when he went digging through Closure. His biggest fear, he told me, was that people would switch from truly excellent JavaScript libraries like jQuery to Closure on the strength of the Google name.

The post continues with examples of how Google gets it wrong with Closure. But as importantly, they’re excellent tips and tricks that every web developer can use to produce faster, better JavaScript.

Closure Compiler, Closure Library, Closure Templates, and Closure Inspector all started as 20% projects and hundreds of Googlers have contributed thousands of patches. Today, each Closure Tool has grown to be a key part of the JavaScript infrastructure behind web apps at Google. That’s why we’re particularly excited (and humbled) to open source them to encourage and support web development outside Google. We want to hear what you think, but more importantly, we want to see what you make. So have at it and have fun!

• Closure Library API Documentation
• Closure Compiler
• Closure Templates

A transcript isn’t available yet.