Navigation timing API

Introduction

This specification defines an interface for web applications to access timing information related to navigation and elements.

The API will allow web application to gather performance metrics about various factors such as page redirect, DNS lookup, connection & secure connection statistics, request/response time, various events, etc. that were not possible with API script before.

Following is the graphical representations of a typical HTTP request response cycle for a web page.

Use case

Performance measurement has always been a bottleneck for web applications. The traditional way to calculate page load time is to write JavaScript to measure page load time. But in majority of cases they are unable to provide exact figures for user latency as in case of below script. It calculates the time it takes to load the page after the first bit of JavaScript in the head is executed, but it does not give any information about the time it takes to get the page from the server.

var start = new Date().getTime();

function onLoad() {

  var now = new Date().getTime();

  var latency = now - start;

  alert("page loading time: " + latency);

}

Examples

The previous example can be modified to measure a user's perceived page load time.

function onLoad() {

  var now = new Date().getTime();

  var page_load_time = now - performance.timing.navigationStart;

  alert("User-perceived page loading time: " + page_load_time);

}

Good question to ask is that the ‘Date’ object will rely on system date time set on user machine which can be easily tampered between the performance measurements. To resolve this, browsers will record monotonic time by recording system date time while starting performance calculation.

The Messaging API

Introduction

This specification defines an API that provides access to messaging functionality in the device, including SMS, MMS and email. It includes APIs to create and send messages. These APIs complement what sms:, mms:, and mailto: URI schemes provide with:

• the possibility to attach files to messages,
• A callback on success / error when a message is sent.

Use case

To describe use case, first I would say many browser today already support messaging by supporting frequently used ‘mailto’, and not so frequently used ‘sms’ URIs. While the API certainly addresses a different use case (access from scripting code), it would be very useful to describe how the URI-initiated messaging is different or equivalent to the API-initiated messaging. For example, should browsers make sure that the user experience is always consistent across these two methods of messaging? Or is it acceptable if URI-based messaging uses an external user agent whereas API-based messaging uses a browser's internal capabilities?

At the very least, it would be useful to point out that URI-based messaging exists, and that page authors have the option of using URIs instead of having to write scripting code. in terms of accessibility and platform robustness, it will be quite a while until page authors could rely on the API alone; at least as a fallback solution, messaging URIs probably always are a good idea.

Since not all devices will have all messaging functionality (e.g. a phone may have only SMS and MMS while a PC may have only e-mail) there is a need to indicate that implementations need only expose available functionality.

Examples

The following code extracts illustrate how to create and send messages. Sending an MMS with an attached picture, if device supports it.

function successCB() {

   alert("The Message has been sent successfully");

}

function errorCB(error) {

   alert("The Message could not be sent " + error.code);

}

if (navigator.device.sendMessage) {

   picture = document.getElementById('attachment').files[0];

   navigator.device.sendMessage("mms:+460000000001?body=Welcome%20%to%Atlantis", [picture], successCB, errorCB);

HTML5 Web Storage API

Introduction

This specification allows web application to store the data in structured and persistence manner. This storage mechanism is similar to HTTP session cookies. But the web storage resolves the problems that are with cookies implementation like

• Storage limit: Cookies can store 4KB data only
• Performance issues: With every request cookies are transmitted to server
• Accessibility issues: Per domain there are numbers of cookies created by different browsers

The web storage can be categorized into session storage (per browser session) and local storage (persistent across multiple sessions).

Session storage: Web application can store data into session store which can be accessible by same application within any window opened in same/another browser session/instance. The data stored into this storage is cleared off when a browser window is closed.

Local storage: This storage type allows application to store data that can be persisted across multiple browser session or reboots. It can act as a permanent repository to store data that is required to be remembered by your computer unless user tries to clear the data using browser’s data clean up wizard.

While we think of power to store in better way the good questions to ask are what about security of data and what about storage limit/constraint. Though the data is stored per domain and will be restricted by browser to have access to that domain only there are going to be potential risks from cross-directory and DNS spoofing attacks. On the space limit, W3C specifies the ideal space limit to be 5MB but it can be up to the browser vendor to decide. In order to not navigate away from the theme to describe the API let’s move on to the user cases.

Use case

There could be many scenarios where one can think of using web storage to achieve some purpose, like storing data for sticky notes, remembering how many times user visited a page, bookmarking page number in a flip book application where user has left last time, language preference user selected during signing into an application and many more.

If we use cookies to remember how many items user has added it to a shopping cart for an eCommerce transaction then we might have cross-window transaction issues. If a user is buying movie ticket in two different windows, using the same site then as the user clicked from page to page in both windows, the ticket currently being purchased would "leak" from one window to the other, potentially causing the user to buy two tickets for the same movie without really handling the scenario. Session storage for this situation would solve this problem.

Another good example to use local storage is to cache the metadata information for a diagram creation tool. The tool can allow user to draw a diagram and add multiple components which user might just leave in the middle without actually pushing draft to server. When this happens tool might store information about components, their position, colors, settings, etc into a local storage so when user resumes the tool can re-apply design panel with same state of diagram that user had created earlier.

Example

http://html5demos.com/storage

HTML5 Webworker API

Introduction

This specification defines an API for running scripts in the background independently of any user interface scripts. This allows for long-running scripts that are not interrupted by scripts that respond to clicks or other user interactions, and allows long tasks to be executed without yielding to keep the page responsive.

Workers (as these background scripts are called herein) are relatively heavy-weight, and are not intended to be used in large numbers. For example, it would be inappropriate to launch one worker for each pixel of a four megapixel image.

Generally, workers are expected to be long-lived, have a high start-up performance cost, and a high per-instance memory cost.

User case

As the web worker API allows us to implement multi threading behavior to a web application imagine a Stock application requires doing multiple things at the same time, getting stock updates on timed interval and finding quotes for specific stock option based on user search criteria. This can be a very good example to think about web workers to be used.

Another use case could be where the application is required to display different views for the map say regular map view, satellite view, hybrid view and 3D map view displaying same region at the same time. User can switch between maps to move map directions in any of the views where all the maps should get updated to show the respective region in their view.

Examples

http://www.whatwg.org/demos/workers/stocks/page.html

http://robertnyman.com/html5/webworkers/webWorkers.html

HTML5 JS API specification and use cases

We all know that the HTML5 is new hot thing in the industry which everyone is trying to write about it, know more concepts, downside and curious about future of the web going ahead with this innovative standard – technology.Some might embrace it or some might criticize it whichever side of the debate you are on it will surely change the web development platform giving the power to do more – which we as geeks weren’t suppose to even think about it. Being W3C standards the browser vendors are now getting leaned towards supporting different features of it that included Microsoft Internet Explorer 9 too.

Things like jQuery, YAML, formatting techniques, and design trends change very quickly throughout the web community. And for the most part we’ve all accepted that some of the things we learn today can be obsolete tomorrow, but that’s the nature of our industry. But keeping aside that fear of not learning new thing we are going to know more about HTML5. If you Google it you will find tons of articles and blogs about HTML5 features and demos, mainly tags and new additions to HTML5 than older versions.

This blog is an attempt to gather HTML5 JS API information in one place instead of going through the traditional concepts only. As the HTML5 is in draft mode and it will change quickly, it is likely that some information outline below might get outdated. If that is the case, please get in touch so that I can update accordingly.

Below is the list of APIs in draft version by the time I wrote this blog. I am going to link them to specific posts in the blog that I will be writing the introduction and explaining the use case of each.

Web Workers

This specification defines an API for web developers to implement multi-threading running scripts in the background independently of any user interface scripts.

For more information http://geeksinaction.blogspot.com/2011/03/html5-webworker-api.html

Server-Sent Events

This specification defines an API for opening an HTTP connection for receiving push notifications from a server in the form of DOM events. The API is designed such that it can be extended to work with other push notification schemes such as Push SMS.

For more information http://geeksinaction.blogspot.com/2011/03/html5-server-sent-api.html

Web Notifications

Web notifications are the ability for an application to notify user even if they are not at the web page in the form of small notification popup box. This creates a great deal for the web applications where even if the interaction between the web application and user is not in synch they can have notifications reached to the end user.

For more information http://geeksinaction.blogspot.com/2011/03/html5-web-notification-api.html

Web Storage

This specification allows web application to store the data in structured and persistence manner using key-value format. The web storage can be categorized into session storage (per browser session) and local storage (persistent across multiple sessions).

For more information http://geeksinaction.blogspot.com/2011/03/introduction-this-specification-allows.html

The Messaging API

 This specification defines an API that provides access to messaging functionality in the device, including SMS, MMS and email. It includes APIs to create and send messages. These APIs complement what sms:, mms:, and mailto: URI schemes provide with:

• the possibility to attach files to messages,
• A callback on success / error when a message is sent

For more information http://geeksinaction.blogspot.com/2011/06/messaging-api.html

Navigation Timing

This specification defines an interface for web applications to access timing information related to navigation and elements.

For more information http://geeksinaction.blogspot.com/2011/06/navigation-timing-api.html

Contacts API

HTML5 Web Messaging

File API: Writer

File API: Directories and System

File API

Web IDL

Permissions for Device API Access

The Media Capture API

HTML Media Capture

RDFa API

The Widget Interface

Geolocation API Specification

XMLHttpRequest Level 2

Indexed Database API

XMLHttpRequest

Cross-Origin Resource Sharing

API for Media Resource 1.0

The System Information API

Uniform Messaging Policy, Level One

Selectors API Level 2

Programmable HTTP Caching and Serving

The Web Sockets API

Selectors API Level 1

Web Forms 2.0