the singularity of being and nothingness
Posts tagged HTML5
New HTML5 Logo
Jan 19th
If you didn’t see, W3C unveiled a shiny (new) logo to represent the far off dream of HTML5. Check it out – http://www.w3.org/html/logo/
Share this:
HTML5 Web SQL
Jul 18th
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 >
HTML5 Server-Sent Events
Jul 12th
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 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, More >
HTML5(ish) Notifications
Jul 11th
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 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” More >
HTML5 Geolocation
Jul 9th
Continuing on from my last post regarding new client-side storage options, I decided to keep the trend of HTML5-related posts coming 🙂
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 >
HTML5 Storage: Goodbye, Cookies
Jul 8th
If you’ve done any web development, at all, ever, you’ve undoubtedly used–and cursed–the clunky cookie.
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.
sessionStoragesessionStorage 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 >
