|
|
|
|
The Web Animations API allows for synchronizing and timing changes to the presentation of a Web page, i.e. animation of DOM elements. It does so by combining two models: the Timing Model and the Animation Model. The Web Animations API provides a common language for browsers and developers to describe animations on DOM elements. To get more information on the concepts behind the API and how to use it, read Using the Web Animations API. Provides playback controls and a timeline for an animation node or source. Can take an object created with the KeyframeEffect() constructor. Describes sets of animatable properties and values, called keyframes and their timing options. These can then be played using the Animation() constructor. Represents the timeline of animation. This interface exists to define timeline features (inherited by DocumentTimeline and future timeline objects) and is not itself accessed by developers. Part of the CSS Animations module, capturing the animation name and elapsed time. Represents animation timelines, including the default document timeline (accessed using the Document.timeline property). The Web Animations API adds features to document and element. The DocumentTimeline object representing the default document timeline. Returns an Array of Animation objects currently in effect on elements in the document. A shortcut method for creating and playing an animation on an element. It returns the created Animation object instance.
Please beware that as of 18th November the W3C is no longer actively working on the Web SQL Database specification. The Web SQL database API isn’t actually part of the HTML5 specification, but it is part of the suite of specifications that allows us developers to build fully fledged web applications, so it’s about time we dig in and check it out. What’s in the box? If you haven’t guessed from the overly verbose specification title, Web SQL Databases is a spec that brings SQL to the client side. If you have a back-end developer’s background, then you’ll probably be familiar with SQL and happy as a pig in muck. If not, you might want to learn some SQL before you start hacking around, Google’s your friend here. The specification is based around SQLite (3.1.19), but having come from MySQL myself, it’s all pretty much the same (sorry for the sweeping statement!). For an example of Web SQL Databases working, have a look at the Twitter HTML5 chatter demo I put together.
Support is a little patchy at the moment. Only Webkit (Safari, SafariMobile and Chrome) and Opera 10.50 (ATOW alpha on Mac) support web databases. Fellow Doctor Bruce Lawson has told me that Firefox are holding off as they feel there’s a better implementation than SQLite (though I hope it’s similar, whatever they pick). Either way, I’d definitely recommend checking out the SQLite documentation for the functions that are available. Because of this patchy support and the simple fact that Webkit had implemented the database spec some time ago, the spec on the W3C is now slightly ahead of the implementations in Safari, while Webkit is still catching up. On the other hand, since Opera has only just added support, it’s closer to the spec (I’ll mention the differences as we go along). Nonetheless, it’s fun to play with, so let’s get playing! If you try to open a database that doesn’t exist, the API will create it on the fly for you.
You also don’t have to worry about closing databases. I’ve passed four arguments to the openDatabase method. The creation callback will be called if the database is being created. Without this feature, however, the databases are still being created on the fly and correctly versioned. The return value from openDatabase contains the transaction methods, so we’ll need to capture this to be able to perform SQL queries. From the tests I’ve run, only Safari prompts the user if you try to create a database over the size of the default database size, 5MB. The prompt is shown the image below, asking whether you want to grant the database permission to scale up to the next size of database - 5, 10, 50, 100 and 500MB. Opera, on the other hand, builds the database without complaining, which I expect might change later as it’s still in alpha. I could be wrong, but everything I’ve tested so far says that versioning in SQL databases is borked.
The version number is a required argument to openDatabase, so you must know the version number before you try to open it. Otherwise, an exception is thrown. Also, changeVersion, the method to change the database version, is not fully supported in Webkit. It works in Chrome and Opera, but not in Safari or Webkit. Regardless, if I can’t determine which version of database the user is on, then I can’t upgrade the user. A possible workaround is to maintain a state database, something like the ‘mysql’ database in MySQL. This way, you would only have one version of this state database, and within this you would record the current version of any databases that control your application. It’s a hack, but it works. Now that we’ve opened our database, we can create transactions. Why bother with transactions instead of just running our SQL? Transactions give us the ability to rollback. This means that if a transaction - which could contain one or more SQL statements - fails (either the SQL or the code in the transaction), the updates to the database are never committed - i.e. it’s as if the transaction never happened.
|
|
