On Saturday, Google Politics & Elections posted an interesting infographic about search trends over the last week related to the four remaining GOP Presidential candidates.

Here’s the infographic:

From Google Politics & Elections

Overall, pretty nice. It makes good use of color, highlights the important details, and avoids loading the graphic with needless frills, pointless content, etc.

The one problem, though, is that it’s simply an image. While it’s nice to look at, it’s kind of boring.

Some CSS3 Up In Here

So as I was internally complaining about how boring the image qua image is, it occurred to me that some simple CSS3 flourishes could really make this nice.

Check Out the Example (note: you’ll need a more recent version of Webkit or Firefox for this to work…)

In this experiment, I’m using a few things I’ve not messed with much in the past: keyframes and the flex-box model.

Flex-Box Model

If you’re a web designer, you’ve no doubt spent endless hours trying to coax HTML and CSS to do simple things like expand “columns” a particular percentage in width and height. This is a horrible nightmare to endure, and it usually ends in a lot of hacks and more cursing, just to get content to line up correctly.

Enter the flex-box model. WIth the flex-box model, you can create dynamic, “flexible” areas of content that not only “flex” to fill space based on your precise specification, but can also have intrinsic relationships to other elements.

In my example, I used the flex-box model to handle laying out the “name” and “percentage” content in each candidate’s “bar.” Here’s the HTML:

<div class="bar">
    <img src... />
    <div class="name">Newt Gingrich</div>
    <div class="total">+688%</div>
</div>

Very simple. In fact, the flex-box doesn’t really require much in the way of mark-up…you can easily use the basic structures that you would normally implement.

Since there’s nothing special about the markup, the real magic happens in CSS:

// flex box styles for "bar" container
.bar {
    display: -webkit-box;
    display: -moz-box;
}
// flex box styles for "name" content
.name {
    -webkit-box-flex: 1;
    -moz-box-flex:1;
}

That’s it? Yep, that’s it. When we add “display:box;” to the parent element, we are telling it that it should behave according to the flex-box model. By default, this will lay out all of its children along the horizontal axis. Notice we didn’t have to float anything. That is awesome.

And for the “name” content, we’ve added the “box-flex” attribute and given it a value of “1″. This tells the individual item that not only should it be laid out horizontally with its siblings, but that moreover it should take up additional space. Since we’ve applied “box-flex” to only 1 element, this will take up any remaining space in the parent–if other siblings had “box-flex” as well, the value of “1″ would change in relation to the box-flex of the other siblings.

In essence, what this does it to give us a really nice horizontal layout of 3 items (the image, the “name” and the “percentage”) without needing floats, positioning, or any other nonsense. Since “name” is the only content with “box-flex” assigned, it will greedily gobble up the remaining space left over in the parent, resulting in a nice right-alignment of the variable-width “percentage” content. Did I mention no floats? Hooray.

Keyframe Animations

Besides the super-sweet flex-box utilization, this example also uses the super-fancy keyframe animation specification. What are keyframes? Think about when you used to create animations in Flash, and you created keyframes at specified points along a timeline where you wanted specific events to occur. Keyframes in CSS3 animations are very similar.

In this example, I wanted to animate the background of the main content area (the gradients behind each candidate). WIth the keyframe specification, this is stupid simple. Here’s some CSS:

@-webkit-keyframes expanding {
    0%   { width:0;}
    100% { width:100%;}
}
.bar {
    -webkit-animation-iteration-count: 1;
    -webkit-animation-name: expanding;
    -webkit-animation-duration: .25s;
    -webkit-animation-timing-function:ease-in-out;
    -webkit-animation-fill-mode: forwards;
}

This is a bit more involved than the flex-box model, so let’s take a look piece by piece.

The first chunk of code is where we define the keyframe to be used in the animation. You use the @-webkit-keyframes directive, and then provide a name (“expanding”, in this example). Then, within the object, you simply define the style rules that should be applied at each “frame” of the animation. In this example, we have a very simple definition. At the start of the animation (0%), the width of the element will be 0; at the end (100%) the width will be 100%. The cool part is that the browser takes care of the animation in between each keyframe, and this is why we get the horizontal bar “expansion” animation in this example.

The next chunk of code is how we 1.) apply the keyframe specification to the particular element (“animation-name”) and 2.) additionally configure how the animation will behave, such as the duration, why kind of timing function should be applied, how many times the animation should run, etc.

Pretty cool stuff.

Some Caveats

Unfortunately, support in browsers for some of the cooler stuff in this demo is currently pretty limited. To the best of my knowledge, both the flex-box and keyframe specification are only implemented in Webkit and Firefox.

Moreover, I didn’t bother with a graceful degradation to other browsers. So if you open this example in IE, Opera, etc., you’re out of luck. If you feel like implementing a graceful degradation, feel free to grab the source from GitHub.

Wrapping Up

While a lot of these features are still not yet ready for primetime, I think this example shows ways in which these new aspects of CSS3 can help to improve the experience of the internet. Does this application of CSS3 radically improve the infographic? Probably not. However, it does show the promise of how simple interactivity can be added without much pain at all.

Step 1: Install Ruby

To get SASS setup, you’ll first need to install Ruby and Ruby Gems (SASS is bundled with something called “Compass”, and Compass is a “Gem” that can be added into Ruby). You can go the painful route and install Ruby and then add Gems into it. However, if you’re stupid about these things, you can do what I did and just grab the Ruby 1.92 installer–it comes pre-built with Gems already configured.

Get the Ruby 1.92 Installer

When prompted, choose “”Add Ruby executables to you PATH”

I installed to the default directory on Windows (C:\Ruby192\)

Step 2: Setup Compass

Now that Ruby is installed, the next step is to get Compass (e.g., SASS) setup. This step actually took me the longest, simply because I’m stupid about command-line stuff. So here’s a play-by-play of what to do (this is for Windows…I assume Mac is similar), just in case you suffer from a similar level of stupidity:

• Open a new Command Shell (Start -> Run -> type “cmd”)
• Navigate to your Ruby installation directory (cd/ruby192)
• Type “gem install compass –pre” – if it works, you should see a bunch of text appear about things being installed, configured, and what not.
• BTW, we’re using “–pre” to get a beta version (0.11) of Compass. This is necessary, as the latest non-beta will break when compiling.

Step 3: Done!

You’re done. The next step is to actually start customizing some sassy stylesheets!

Check it out

While browsing these old files, I found the source code for the very first web site that I ever made.

As a disclaimer, this site is very rough.  I had no idea about HTML–so it’s basically an export from Photoshop to the web.  But as rough as it is, it was where I got my start, and so this site will always have a special place in my heart.  Plus, it was something that I made for good friends, so that’s an added bonus

Anyway, check it out when you have a chance, and marvel at the awesomeness!

Add cool stuff.  Like Pay-Pal plugins.  Like RSS readers.  Like Firebug.

It was the bees’ knees, and looked like it was going to gobble up all the stragglers that IE left in its “who cares about the experience” attitude toward the internet.

But then Chrome came along.  It was sleek.  It was fast.  And best of all, it brought some fresher-than-Firefox ideas to browsing.

Better, fresher ideas.  Like tabs-on-top.  Like better architecture for faster…everything.  Like not-having-to-upgrade-every-2.5-seconds.

So I’ve been using Chrome alot lately.  Sure, it’s different.  But what I’ve found is that it’s better.  Sure, it doesn’t have Firebug (which is probably the only reason whatsoever that I continue to use Firefox).  But every version gets better.  And faster.  And awesomer.

And Firefox?  Perhaps its my groaning, Vista-laden PC, but Firefox hates everything.  It’s slow, it freezes, it crashes…and very few of the plugins that I depend on for Firefox to be awesome can keep up with the releases.

And the things I’ve been seeing for v4 are less than impressive.  The other day I watched a video on their “new” feature for 4–tabs on top.

Tabs on top.

Hmmm…where have I seen that before?  Oh yeah, every other browser to update its version in the last 6 months.

Now in all fairness, tabs on top makes sense, and the logic in the video–IMO–is pretty well founded.  But it just feels like a lot of far too little and way too late.

Obviously, I’m going to keep using Firefox in some capacity.  There’s the perennial issue of cross-browser compatibility that I always have to wrangle for my work, and Firebug still destroys Chrome’s girly development tools. However, I see our paths steadily diverging, and see little opportunities for them to entwine again.

My idea on this is to use the versioning as a way to push incremental database schema changes in a systematic way.  For example, you could easily define a complex series of schema updates that take the user’s database version (whatever it might be) directly to the most current version.  However, this seems like an undue amount of work to me.  Rather, I think that maintaining a procedural update history of each version makes more sense.

Here’s the idea.  Let’s say that we’re building a blog.  Perhaps version 1 of our database is very simple: just a “posts” table that captures title, content, publishdate, and author.

VERSION 1
posts
      postid
      title
      content
      publishdate
      author

But let’s say in version 2, we add two more tables (comments and categories, for example).

VERSION 1          --->    VERSION 2
posts                      posts
      postid                    postid
      title                     title
      content                   content
      publishdate               publishdate
      author                    author
                           comments
                                commentid
                                content
                                author
                                publishdate
                                postid
                           categories
                                categoryid
                                category

Now our approach is increasing in complexity, for not only do we need to give new users the full version 2 schema, but we also need to upgrade version 1 users to the new schema without destroying their existing data.

But let’s push this out into the future a bit.  Perhaps by version 3, we’ve added a few more tables.  Now we have to give new users the version 3 schema and upgrade BOTH version 2 and potential version 1 users to the new schema, taking into the account the discrepencies between version 1 and 2, and between both 1 and 3 and 2 and 3.

VERSION 1          --->    VERSION 3
posts                      posts
      postid                    postid
      title                     title
      content                   content
      publishdate               publishdate
      author                    author
                           comments
                                commentid
                                content
                                author
                                publishdate
                                postid
                           categories
                                categoryid
                                category
                           tags
                                tagid
                                tag
                           bloginfo
                                title
                                owner
                                tagline

VERSION 2          --->    VERSION 3
posts                      posts
      postid                    postid
      title                     title
      content                   content
      publishdate               publishdate
      author                    author
comments                   comments
      commentid                 commentid
      content                   content
      author                    author
      publishdate               publishdate
      postid                    postid
categories                 categories
      categoryid                categoryid
      category                  category
                           tags
                                tagid
                                tag
                           bloginfo
                                title
                                owner
                                tagline

Oh, and we just realized we need to add an additional column to our original “posts” table, so version 3.1 increases the complexity yet again.

How do we manage this?  Do we write a full complement of schema updates to get each version (1, 2, and 3) to the current version (3.1)?  If we do, this will be a lot of code.  Do we simply write a bunch of clunky “if exists” procedures in our sql to account for gaps in our schemas at any stage in the versioning?  It’s a better solution, but is still lacking, IMO, because it doesn’t really show how the changes are occurring across versions.  If something goes wrong at some point, it’s not immediately obvious where the discrepancy originated.

So my solution is to manage the version updates through incremental upgrades to the newest version by way of any versions in between.  Therefore, if our current version is 3.1, a user with the 1.0 version will be upgraded to 3.1 by first upgrading to 2, then to 3, then to 3.1.  While this requires a bit more effort than the “if exists” SQL-based solution, it provides an immediate version history, providing great introspection into how each version is related to the previous, and to the next.  Let’s look at how this plays out:

First, I create an array representing the complete version history of the database:

this.apphistory    =    ['1.00','2.00','3.00','3.10'];
this.appversion    =    '3.10';

Then, upon each opening of the database, I invoke a custom method “setSchema” which checks the current version of the database against the current “official” version of the database, and handles the incremental updates if needed:

setSchema = function() {
     // set array for holding our sql statements; sql lite can only process one statement at a time
     var sql    = new Array();
     // get history object-- returns current version and whether version is equal to the "official" or current version
     var history = this.getHistory();
     // if client db version is not equal to current appversion, start iterative update
     var ver = history.iscurrent ? this.appversion : history.current;
     if(!history.iscurrent) {
          switch(ver) {
               case '1.00':
                    sql[0]    =    "create table  comments(commentid,content,author,publishdate,postid);";
                    break;
               case '2.00':
                    sql[0]    =    "create table categories(categoryid,category)";
                    sql[1]    =    "create table tags(tagid,tag)";
                    break;
               case '3.00':
                    sql[0]     =   "alter table posts add created";
                    sql[1]    =    "alter table posts add updated";
                    break;
               // default will be a snapshot of the current version of the schema;
               default:
                    sql[0]    =    "create table posts(postid integer primary key  autoincrement,title,publishdate,author,content,created,updated);";
                    sql[1]    =    "create table  comments(commentid,content,author,publishdate,postid);";
                    sql[2]    =    "create table categories(categoryid,category)";
                    sql[3]    =    "create table tags(tagid,tag)";
                    sql[4]    =    "create table bloginfo(name,owner,tagline)";
          }
          this.database.transaction(function (t) {
          for(var i=0;i<sql.length;i++) {
               t.executeSql(sql[i]);
          }
      });
      this.setVersion();
   }
}

What’s basically happening here is that the “default” case will always have what the “official” version of the database should be.  In this case, this is the “3.10″ version of the database.  So if any new users come to the site, they will get the full-on copy of this database written to their client.  If, however, they have a previous version of the database, they don’t need a full upgrade to the 3.1.  Rather, they only need incremental changes to get them to the current database version.  Therefore, if the client has a “2.00″ database version, they will execute SQL statements to get them to the “3.00″ version, and on the next pass of this method, they will get the final incremental change to “3.10.”

And in the future, when additional tables or columns are added/modified, the “default” case can be updated to include the changes, and a case for “3.10″ can be added to manage the incremental change to the newest version.

As I mentioned before, this is perhaps not the prettiest way to manage this.  The thing I like, however, is how explicitly it defines the relationships between the versions.  With a quick glance, we can see what changes are occurring from version to version.  And, because this is an iterative process, we don’t have to worry about updating the “version 2.00″ case to get the client database directly to the newest version (imagine doing that for 50 versions…yikes!). Rather, because the upgrade from 2.00 to 3.00 will ALWAYS be the same, we only have to worry about keeping the newest and most recent versions synched, as this process will take any previous version iteratively through to the official current version.

Enter Web SQL databases.  As the name implies, Web SQL databases are, well, client-based SQL databases (SQL Lite, to be exact) that can be levered through JavaScript.  Each “origin” can have a number of databases, each of which has a unique name and version (more about this later).  If you use something like the Developer Tools in Chrome, you can see these databases in action–including the databases themselves, child tables, and any data that has been added to the tables.

Working with Web SQL

The doorway to creating and using Web SQL databases is the openDatabase() method.  It doesn’t matter if you’re creating a new database, or creating a connection to an existing one: this is the first thing you’ll do, and here’s what it looks like:

this.database = openDatabase('Blog',"",'A Blog to Rule the World',2000000);

The openDatabase() method takes 4 required arguments:

1. Name: Any valid string, including the empty string, is acceptable.  Database names must be unique, however, and should be evaluated in a case-sensitive manner
2. Version: The version of the database to open
3. Display Name: A friendly name that the browser can use (in prompts, etc.)
4. Estimated Size: Each database has a default  maximum size, and users will be prompted to allow this to increase if the data exceeds the default quota.  Specifying a particular value here can avoid this annoyance by telling the browser up front what the total size might eventually be, short-circuiting the otherwise annoying prompts at each incremental increase (e.g., at 5, 10, 15, 20MB…)

Additionally, there is an optional 5th argument– callback method.  This callback method will be invoked if the database is created (not opened), and per the spec should be used to invoke the changeVersion() method to set the appropriate version of the database.  If no callback method is specified, the database will be created with whatever version is specified in the openDatabase() method invocation.

Now that we’ve got an open connection to our database, let’s do some stuff to it!

SQL Transactions

The core of working with your now-open connection is the Web SQL transaction() method.  [There's also the "readTransaction()" method, which allows for read-only access].  This method takes 1-3 arguments, including the following:

1. SQLTransactionCallback: This is required, and is the executeSql method that will actually execute the sql command (more on this later)
2. SQLTransactionCallback: Optional callback method to handle transaction errors.  This method passes both the transaction, and an error object which contains, among other things, a message describing the error
3. SQLVoidCallback: Optional callback method executed upon a successful transaction

A really cool part about the transaction() method is that it provides the ability for rollback.  This is why, in short, the actual execution of the SQL is wrapped in a transaction.  It’s kind of a pain if you don’t care about rollbacks, but if you don’t care about rollbacks, maybe you don’t care about data integrity

Here’s what a transaction might look like:

database.transaction(
     function(t){
        //execute sql here...
     }
);

Executing SQL

Now that we’ve created a transaction() method wrapper, we can actually get down to running some SQL.  This is accomplished by the aptly named executeSQL() method.  This method takes up to 4 arguments:

1. SQLStatement: A valid string representation of the SQL to be executed (this, obviously, is required)
2. Argument Array: An array of arguments to be matched in SQL statement (more about this later)
3. SQLStatementCallback: An optional callback method to be invoked on successful execution of the SQL statement–this method passes the transaction and result set from the query…so it’s pretty important to specify if you want to return data from the database…
4. SQLStatementErrorCallback: An optional callback method to be invoked when the executeSql() method fails–this method passes the transaction and error object

So let’s say we want to create a new table called “posts” with a few columns.  Our full transaction/executeSql() statement might look like this:

database.transaction(
     function(t) {
          t.executeSql("create table posts(postid integer primary key autoincrement,title,publishdate,author,content);";
     }
)

One thing to note, especially relating to schema creation, is that in SQL Lite, only one SQL statement can be executed per request.  So for example, if you’re trying to create multiple tables at one time (like when you’re building the schema for your database), you’ll have to pass the SQL statement for each table creation to an individual executeSql() method.  To streamline this, I simply create an array of SQL statements, and then iterate over them in a loop.  I’m sure there are other fine ways to accomplish this as well, but this works for me.

Preventing SQL Injection

If you’re a web developer, you should always be aware of the possibility of SQL injection, and do all that you can to prevent it.  Because of the way that Web Sql is structured, it’s probably a pretty big temptation to build SQL statements on the fly.  DON’T DO IT. This just opens the door to SQL injection, and because this is all happening in JavaScript, it would not be hard to identify where SQL is being dynamically generated and exploit it.

To help prevent SQL injection, the 2nd argument of the executeSQL() method, the Arguments array, allows you to specify “placeholders” in your SQL that can be substituted at execution time with scrubbed and validated data.  It works like this:

var sql = "insert into posts (title,content,publishdate,author) values (?,?,?,?,?)";
var val = new Array(t,c,p,a);
var executeSql(sql,val);

As you can see, in the actual SQL statement, I used “?” to specify my argument’s placeholders.  Then, I created a new array containing my scrubbed values coming from the client.  Then, I simply passed both to my executeSql method, and it works brilliantly.  Simple.  Of course, since I’m passing an array and not a key/value pair object, the order of the arguments compared to the placeholders is EXTREMELY important.  Just keep that in mind

Finally…Getting Some Data

So far, we’ve seen how to establish a database connection, create transactions, and then execute SQL against the database.  Now let’s talk about what to do with the data once we get it.

If you’ll remember, the executeSql() method provides an optional (although recommended) callback method that returns a results object from the executed SQL.  This object contains the following:

• insertedId:  This is the id of the row that a SQL execution inserted, if any.  If multiple rows were inserted, it returns the id of the last inserted row.  Very handy.
• rowsAffected:  This is the number of rows affected by the SQL execution.
• rows:  An object containing any rows returned from the SQL execution

Once you’ve got the “rows” object to work with, you can retrieve an individual row’s data like so:

var row     = results.rows.item(num);
var title   = row.title;
var author  = row.author;
var content = row.content;

As you can see, each “column” in the row can simply be accessed by its name in the object.  Pretty simple, huh?

So What’s the Point?

As we’ve seen, working with Web SQL databases is pretty straightforward.  If you’re familiar with anonymous functions, and have a good grasp of general SQL, this is easy stuff.   Plus, because it is SQL based, the concepts involved with managing the data and database structure are no big deal, and you can concentrate more on developing the connections, error-handling, etc.

But on a more conceptual level, what’s the point of this?  After all, this is still a client-based solution.  If the user goes nuclear on their client history settings, any databases will be wiped out.  If this data, in that sense, is still so “temporary,” why bother with it?

Obviously, Web SQL databases are not intended to be replacements for server-based solutions.  On some level, data does need to be managed in a controlled, secure, and “permanent” way.  Web SQL is not going to change that.  What it will change, however, is how application development happens.

For example, consider the present situation.  If you’re developing an application that needs to regularly (let’s say once a minute) save data states for your users, the way to do this is through either clunky cookies (blah) or regular server-side hits to save records to a managed database.  While this works, it’s expensive.  Depending on the size of the data and amount of traffic, this could result in thousands and thousands of remote requests hitting every couple seconds.  If you have the hardware to handle this, it’s not a big deal.  But if you don’t, it can take it’s toll.

So what if you could reduce this by a quarter? Or half?  Or a 75%?  Imagine this:  instead of hitting the server every minute to save a data state, you could instead change the schedule to once every 5 minutes.  During those 5 minutes you could still have the same routine running, only in this scenario it would be saving the data state to the client Web SQL database.  Then, after 5 minutes, a protocol could transfer the saved datastates from client to server.  This will be entirely seemless to the user, and will save load on the server by making the requests less frequent.

Or imagine making your applications available offline.  When connected, the client machine could maintain a synchronized set of data with the remote server.  Then, when the client goes offline, they could continue working with the application, utilizing the data from their machine’s synched data from the server.  Then, when they are available to get online again, the client data repository could be resynched with the remote server, pushing any new or modified data.  While the experience between offline and online states would be different in some ways, the very ability to be able to work online and offline in a more or less seamless manner is a radical paradigm shift for web-based applications, and opens up the doors of some very exciting possibilities.

The Demo

Ok, enough of this post.  If you’re interested in learning more, be sure to check out the W3C spec of this.

Also, be sure to check out my demo (use Chrome…).  It’s a simple blog manager that allows you to create, edit and delete posts.  Check it out!!

In HTML5, this becomes a reality. Enter Server-Sent Events. In a nutshell, server-sent events “enable servers to push data to Web pages over HTTP or using dedicated server-push protocols.” This means, basically, that the client doesn’t have to keep asking for information: the server will notify the client when new information is available.

In it’s present state, server-sent events are only available for Opera and Chrome (6) dev releases. Additionally, they are currently implemented in two different ways. For Opera, the technology utilizes a DOM element (), while Chrome is entirely JS based. For this overview, I’ll be concentrating on the Chrome implementation.

For the example I worked up, I’ve created a simple chat interface. The basic idea is that two people share usernames, entering them into their respective client interfaces. When each chat message is sent, the record is saved to a database on the server, and an independent page continues to query the db for new data pertaining to the chat session. If new data exists, it pushes it to the clients’ interfaces.

The Code

So first things first. Let’s create our EventSource, the base object that we’ll utilize to make the magic happen:

serverevent = new EventSource("serversent_helper.cfm");
serverevent.addEventListener('message', onMessageHandler);

This is easy enough to see what’s happening. Basically, I define a new EventSource, and pass to it the server-side page that will manage the pushing of data. Finally, I add a listener to the “onmessage” event of the EventSource, which then in turn calls a user-defined function to do whatever with the data from the server (an event object is passed in the callback method).

That’s it. Seriously, pretty simple. From here, the rest is basically getting the data from the server to be in the proper format to work with the EventSource. And this is where it gets a little murky. Per the spec, the data pushed from the server has to be in a very specific format. To be honest, I spent more time than I’d care to admit on this. But it was a good lesson.

There’s a lot in the spec about this, so I’ll only cover the most important details. This is from serversent_helper.cfm, the source specified in the EventSource invocation:

           writeoutput("data:"&serializejson(message)&chr(10));
           writeoutput("id:"&qmessages.messageid&chr(10));

What I’m not showing you is the queries I used to create and retrieve data from the chat sessions. Assuming that a chat to be pushed exists, this is the code that generates the data pushed to the client.

First, notice the content declaration of “text/event-stream“. This is incredibly important. If your content is not in this format, the push from the server will not work.

Next, notice the output sections. Per the spec, data pushed should be in the following format: “data: [string]“. It is the combination of “data:” and an accompanying string that makes the push work. Without it, nothing will happen. Following the “data:” declaration, I’ve also set “id:”. This is important because you can optionally tag each push with an id which will then be subsequently passed as a header in future interactions between the client and server. Specifically, the header “Last-Event-ID” will be used, so if a connection is lost, the last-used id can be processed when the connection is restored, picking up where it left off.

Finally, notice the newline characters at the end of each line (“chr(10)” in ColdFusion, “\n” in other languages). This is EXTREMELY important because the “field names” of the response are processed on the basis of the newline characters. In this example, if I did not put the newline character after the “data” block, my response would look like {…jsonstring…}id:numeric, rather than just {…jsonstring…}. Additionally, the Last-Event-ID would not get set.

And yes, you can use JSON, so not problems at all pushing complex data objects

Additional Methods and Considerations

I didn’t use these in my demo, but thought I’d point them out anyway. Besides the “onmessage” event, you can also add listeners to the following exposed events from EventSource:

1. onopen – fires when connection between server and client is created
2. onerror – fires when there’s an error in the connection

And in addition to the url and Last-Event-ID, the readyState attribute is available from EventSource. As its name implies, readyState represents the current state of the connection, and can take the following values:

1. CONNECTING = 0
2. OPEN = 1
3. CLOSED = 2

Wrapping Up

As mentioned earlier, because of the relative newness of EventSource, its implementation is severely limited. However, I think it is a pretty cool idea and I can think of lots of potential uses for this, specifically in relation to connection-less data pushing. I’m excited to see how this develops as the spec is more well-defined and more browsers begin to implement it.

A note about the demo. It definitely works, but there are a few things to keep in mind:

1. It will ONLY work with the latest dev version of Chrome (v. 6). If you try it in any other browser, it will be quite disappointing
2. Because it’s just a quick demo, you’ll have to arrange a chat with someone with the same dev version of Chrome, and you’ll have to coordinate the usernames that you’ll use to try it out, given that the chat sessions are based on user-entered names
3. Sure, I could have made a static example…but I thought the chat would show off the tech a bit more…so sue me!!!

As with the other items we’ve been exploring in our look at HTML5-related technologies, Notifications are really easy to work with.  A word of warning, however.  Right now, this is only implemented in Chrome, and the W3C spec is itself based upon a webkit-specific API.  So in order to make these work right now, you have to use the Chromium API, not the W3C spec.  The fundamental principles are precisely the same (since the latter is based on the former), but has some minor differences.

So now for the obligatory example–let’s get my (or someone else’s…) most recent Twitter post and display a notification.

First, let’s create a reference to the Notifications object:

var notification = window.webkitNotifications;

(Notice the “webkit” syntax)

Now that we have a reference to our Notifications interface, let’s handle the entering and submitting of a Twitter username:

function SetNotification() {
     var username = Ext.get('twitterusername').getValue();
     if(username=='') {
          Ext.Msg.alert('Attention!','Please enter a Twitter username');
          return false;
     }
     if(notification.checkPermission()==0) {
          GetTwitterData();
     }
     else {
          notification.requestPermission(PermissionDelegate);
     }
}

A few things to point out here.  First, as part of the spec, the user has to grant permissions to the service to create Notifications.  Before we actually handle the requesting of permissions, we can check if permissions already exist by invoking the checkPermission() method.  This will return three possible values:

1. PERMISSION_ALLOWED = 0;
2. PERMISSION_NOT_ALLOWED = 1;
3. PERMISSION_DENIED = 2;

To me, the numbering is a bit counter-intuitive (0 == allowed?), but it’s easy enough to work with.

So if we’ve already obtained permissions, we simply call our main function for retrieving Twitter data.  If permissions do not exist, however, we invoke the requestPermission() method.  This will create a browser prompt, and the user can either Allow or Deny permissions for Notifications.  requestPermission() takes one argument: a callback function.  This can be invoked to handle post-permission granting/denying.  In this example, the callback is PermissionDelegate():

function PermissionDelegate() {    �
     // if permissions have been granted (checkpermission()==0), proceed; otherwise, show error message and cancel operation�
     if(notification.checkPermission()==0) {
          GetTwitterData();
     }
     else {
          Ext.Msg.alert('Notice','To receive notifications from this application, please grant permissions when prompted.<br /><br />Please try again.');
     }
}

Simple enough.  If the user grants permissions (checkPermission()==0), we continue with the processing.  If not, we display an error message and suggest that the users tries the operation again.

So on with the example.  I won’t bore you with the process of getting the Twitter post.  If you want, you can check the source code, but it boils down to the nifty JSONP hack…

Now that we’ve been granted permission to create Notifications, and finally have the Twitter data, let’s create a notification!

function TweetSuccess(req) {
     if(req.length) {
          var type = Ext.getCmp('radiogroup').getValue().value;
          var img     = req[0].user.profile_image_url;
          var name    = req[0].user.screen_name;
          var tweet    = req[0].text;
          if(type==1) {
               var tweet    = tweet.parseURL().parseUsername().parseHashtag();
               notification.createHTMLNotification("notification_helper.cfm?title="+name+"&img="+img+"&content="+tweet).show();
          }
          else {
               notification.createNotification(img,name,tweet).show();
          }
      }
      else {
           Ext.Msg.alert('Uh-oh','Sorry, that\'s not a valid Twitter username. Please try again!');
           return false;
      }
}

Most of this function is just getting the values from the returned data, so we’ll skip to the important stuff: createNotification() and createHTMLNotification().

Why two methods?  Well, each provides a little bit different way of displaying notifications, of course!

createNotification() creates a standard, vanilla notification that inherits whatever styles the browser has defined for its notifications.  This method takes three arguments:

1. iconUrl – This is the path (absolute) of the icon that you would like displayed in the notification
2. title – Um, the title of the notification
3. body -  The main content to be displayed in the notification.

While this works pretty nicely, I wasn’t thrilled with the look of the notification.  And although I didn’t pursue it very far, I couldn’t get links or any other styling to show up in the notification.

createHTMLNotifications() picks up where createNotification() falls short in the customization department.  Whereas you pass icons, titles, and body content to createNotification(), you simply pass a url to a page that defines your notification content for createHTMLNotifications().  While this creates a bit more work for arranging icons, titles, and body content, it does allow you to be a bit more creative in how the notifications look.  Plus, since it’s an HTML notification, you can use some nifty CSS3, and who doesn’t love that!

Wrapping Up

There’s a bunch more to Notifications that I didn’t cover (like closing them programmatically, etc.), but hopefully this is a nice introduction to the concepts behind what will hopefully be embraced by all browsers in the very near future.  I see a lot of promise to these, and can’t wait until all the environments are more unified to start utilizing them to their full potential.

As always, be sure to check out the demo (remember, Chrome only ) and let me know what you think.