Showing posts with label HTML5. Show all posts
Showing posts with label HTML5. Show all posts

Monday, November 13, 2017

The Future of HTML5 Offline Functionality

The Future of HTML5 Offline Functionality


One of the great promises of HTML5 is to allow rich web applications to continue to operate (inasmuch as it’s possible) when a connection is not available to the Internet.  There are two major components of providing such a service, and both are addressed in some way by the HTML5 standard.  However, these are two of the most-disputed areas of the spec when it comes to actual implementation.

The Application Cache 

The HTML5 spec has a lengthy description of the Application Cache mechanism.  Basically, this allows web developers to specify what content should be displayed for a URL when a connection can’t be made to the server that normally handles the URL.

For example, a particular LucidChart document might be edited by visiting a specific URL. The App Cache allows us to specify that we’d like certain content to be cached and displayed instead if can’t be reached.  That content would include the current version of the document and all its related metadata, along with the HTML, Javascript, CSS, and images needed to display it to the user.

While this concept is well-accepted in the standard, one critical issue hasn’t been addressed: How much space do you allow applications to use in this cache, and how do you gracefully allow the user to adjust those allocations?

Consider that in order to have true offline functionality for LucidChart, we need to have a copy of at least the current version of all of a user’s documents in the app cache.  For many users, especially those who are using custom uploaded images, this size stretches into tens or hundreds of megabytes.

The HTML5 spec does not specify the amount of space available to applications, but currently developers can’t count on getting more than 5MB per domain.

Local Storage 

While the application cache would allow users to view their past work, there needs to be a mechanism for saving new work that they accomplish until a connection is restored to the server.  There are actually three competing standards in play for this area.

First, and the only one universally available (even in Internet Explorer) is Web Storage, AKA “DOM Storage.”  This is simply a key-value map that allows developers to store arbitrary data for later use anywhere on the domain.  This is very unstructured data, so there is no meaningful way to query the data in a way that parallels a normal modern database system.  However, it is universally implemented today, so it is the most promising of the prospects.

However, Web Storage falls down in the same way that the App Cache does–there’s no specification of how much space should be available to sites.  Chrome currently has a 5MB limit per domain, IE has a 10MB limit per domain, and Firefox appears to have no limit (though they notify users when a site is using a lot of storage).  Depending on the kind of data a user is generating, this storage can run out alarmingly fast.

To help address the problem of unstructured data, another standard called Web SQL is competing for inclusion in HTML5.  It’s a simple Javascript interface to a simple SQL database.  In every current implementation, this database is implemented with the public domain SQlite library.

Mozilla, however, thinks that a “standard” that’s actually based on a particular implementation (in this case, SQlite) is not a standard at all.  So they built a simple data store (incidentally, also built on top of SQlite) that exposes a simple key/value document hierarchy.  Since the interface is well-defined, they claim this this is a better standard to build against that Web SQL.  The problem, of course, is that only they support it (and only in Firefox 4+).

What Developers Need 

We at LucidChart need the following in order to develop a first-rate offline tool:

· Higher storage limits for the App Cache and Web Storage.  Preferably, a way to prompt the user to allow us to use unlimited storage–as any native app would have access to.

· Universal, reliable implementation of the App Cache standard in all major browsers.

· (Optional) Universal, reliable implementation of Web SQL.  Unfortunately, Mozilla has sworn never to implement this standard.

And we are not alone in this.  I struggle to think of a meaningful web application that does not have these needs in order to build offline functionality.  Whether it’s email, word processing, drawing, diagramming, analytics, or CRM, we need a reliable way to store large amounts of structured data in the browser if we’re going to be able to cut the cord to the Internet and continue working.


Dav Gra is interested in the latest trends of online collaborative solutions for distributed teams, including this free Visio alternative which can be used as organizational chart software.

Saturday, July 29, 2017

HTML5 : The Revised Version Of HTML

HTML5 : The Revised Version Of HTML

HTML5 is a revised version of HTML standard. Its development is still under process. The difference between HTML5 and its immediate predecessors HTML4.01 and XHTML1.1 is that HTML5 has features like video playback and drag-and-drop which were missing in the earlier versions.
The origin of the specification dates back to June 2004 by the Web Hypertext Application Technology Working Group (WHATWG) under the name Web Applications1.0.In March 2010 WHATWG was ready with the draft standard state of the specification. The editor of HTML5 is Ian Hickson of Google,Inc.Also at this point of time the specification was ready in working draft state at W3C(World Wide Web Consortium).
HTML5 was the starting point of the group working upon the new HTML at W3C in 2007.On 22nd January 2008 this working group published the First Public Working Draft of HTML5. The specification is still under development and will remain to be so for years to come although some parts of it will be ready to be implemented in the browsers soon. It is being estimated that HTML5 will reach the final recommendation stage in late 2010.It will be recommended by W3C.  Ian Hickson is expecting HTML5 to reach the Candidate Recommendation stage in 2012.The specification will be recommended by W3C only if it has "100% complete and fully interoperable implementations".

Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. ).

– WHAT Working Group, When will HTML5 be finished?

HTML5 employs inputs which ensure full exhaustion on the modern websites. Some of the inputs are semantic replacements of general functions of generic block (

) and the inline () elements. Some of elements from HTML4.01 have been deleted and some new ones have been added to HTML5 to make it more efficient. The syntax of HTML5 is not based on SGML although their markup is same. Along with markup specification. Scripting application programming interfaces (APIs) is also specified by HTML5.
The new APIs specified are:

•The canvas element for immediate mode 2Ddrawing.
•Offline web applications.
•Timed media playback
•Document editing.
•Drag and drop.
•Cross document messaging.
•Browser history management.

HTML5 will be efficient and flexible enough to handle incorrect syntax. It has been structured in such a way that the old browsers can safely ignore the constructs of HTML5.

Antonio Bristow has penned down many articles on HTML and other mark up languages for webpages. In this article he tells the readers about HTML5, a revised version of HTML.