HTML5

In my last article, I showed how to get setup and started with creating custom stylesheets. After a significant release (1.1.0) and several reader requests, I’m updating the walkthrough with screenshots and instructions for v1.1.0. This version will be strictly business: for discussion about the more interesting points of what’s going on, refer back to the original post

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.

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 More >

Just a quick note–if you didn’t see, Google Chrome has revamped the display for your personal app dashboard. You can now re-order apps by drag-n-drop, rather than installing and uninstalling in the right order.

As mentioned in my last post about Web SQL databases, each Web SQL database consists of a unique name and version. Each database, however, can only have a single version at any given time, so there’s no possibility of older and newer versions running concurrently. To quote the spec, this is provided to “…allow authors to manage schema changes incrementally and non-destructively, and without running the risk of old code (e.g. in another browser window) trying to write to a database with incorrect assumptions.” In other words, instead of trying to manage the hassle of temporarily offloading data, rebuilding the data structure from scratch, and then reloading data when code changes, versioning allows for the detection of the client’s current db version, with the option of programmatically upgrading them to a different (read “new’) version of the database schema. Of course, you could conceivably also use this to detect old versions and point to different code entirely, but that would be a lot of code to manage…

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 More >

A while back, I wrote up a quick post about some of the new client storage options that will be available in HTML5, particularly localStorage and sessionStorage. While they are both pretty nice alternatives to the clunkiness of managing client cookies, they are definitely limited. The biggest limitation is the data structure that each supports (they’re exactly the same, after all, except for lifetime of the data). As I pointed out, while their storage capacity is much greater than that of the old cookie, all data is still managed as key/value pairs. Of course, you can always use JSON encoding to store complex data structures as strings in these options…however, if you need to get at deeper levels of data relationships, these will quickly get VERY clunky and unusable.

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 More >

A common requirement in the era of Web 2.0 (and beyond) technologies is the ability to have “smart” client interfaces that are aware of changes that occur on the server (data, sessions, etc.). Most approaches include some manner of AJAX that regularly polls the server for changes. While this is easy enough to accomplish, it can be a taxing and somewhat annoying process. After all, wouldn’t it be much better if the server could communicate to the client when it has something share, rather than the client mindlessly asking over-and-over-again for the same thing?

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.

Something that’s coming down the pike pretty soon in tandem with HTML5 is the related, but independent W3C draft of a “Notifications” interface. Basically, this new interface provides a way for the browser to send notification messages on your desktop or device. So as example, while Facebook Chat will currently use AJAX to update the content on the browser page (causing the annoying tab “flicker” when a new message arrives), using the Notifications interface will allow a browser-independent message to be displayed directly on your desktop.

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 unless you haven’t visited the web in the last 3 years, you know that location-based services are super-hot right now. If social networking was the final result of Web 2.0, wiring-in people’s browsers (both position-locked and mobile) to geolocation is easily Web 3.0 and beyond. For example, with few exceptions, the vast majority of my iPhone apps have some geo-location component. Whether it’s my RedBox app finding me the closest kiosk, or FourSquare letting me “check in” to new (and not so new) locations, nearly everything I do on the web is able to be tagged with a location. Every tweet, every Facebook wall post, heck, even this blog post have geolocation data attached to them. In every possible way, the web is no longer just about “what” you are doing–it’s where you’re doing it as well.

To help make this more of an integrated reality, HTML5 will come fully-loaded with baked-in geolocation support. As with client-side storage, dealing with the geolocation options is quite easy.

Let’s take a look at a simple example. In what follows, I simply want to More >

In all fairness, cookies are nice for what they are. You can store basic information about users and their behaviors on the user’s machine for use on your site, and they are fairly reliable. The problem with them, though, is that they are clunky. Clunky to set, clunky to expire, and quite limited in terms of storage capability–4000-some characters…lame.

Fortunately, in HTML5, we have a much better option for light-weight client-side storage (like cookies) without the clunky-ness, retarded size limits, and potential “leak” issues. Actually, we have two

First, let’s talk about the Storage object to which the two options belong. According to the proposed spec, the Storage object provides access to set, read, and remove “items” which are basically the key/value pairs that everyone is familiar with. Unlike cookies, however, the key/value pairs do not have an expiration date associated with them, and are removed either by user action or by the cessation of a session.

Enough talk. Let’s look at the options.

sessionStorage

sessionStorage is an attribute of the Storage object which represents a storage area for each “origin” [read domain]. In other words, sessionStorage is a place you More >