Category Archives: Non classé

Appcache & Beyond

Here’s the presentation I gave for the first edition of LyonJS. Firefox or Chrome are required to view those slides, sorry to the others, I’ll try to fix that next time.

Appcache use-cases

I’d like to reorient my conclusion slightly, after the discussion we had at the end of my talk.
As it has been pointed out, offline webapps are not the only use-case for appcache. It can also be used for all webpages that get their content from third party webservices, through ajax APIs. This is the case for, and a growing number of websites that are pure mashups of other webservices.

You forgot to say please

In this case, the benefits are better performances. But my point is that, if appcache needs some improvements (and I think it does!), the goal shouldn’t be to make it the webperf hammer of every website. There is one unique reason for that: the browser should be the one in charge of deciding what deserves to be cached, and what should be evicted from it. We can’t let every website store 200K-1M of resources on a device without asking for permission and providing a simple UI to free memory.

“Evictable” appcache

I actually believe that “asking for permission” is not the best option we can come up with, as users shouldn’t have to manage websites like installed app (if they’re not meant to work offline), this would feel backward. I’d like to see an “evictable” flag being added to the spec (just like the one proposed for indexedDB) that would let the browser know that it’s safe to remove a cache group when needed. With such a flag, user’s consent wouldn’t be required to let websites use appcache. For offline webapp, users would have to grant permissions and they would be the one in charge of “uninstalling” the webapp.

Would that be an acceptable behavior for you?

defaut display value of any DOM element

library authors have long been struggling to find a bullet proof function that will give the default display value of any DOM element. Average Web developer shouldn’t worry about it, but the solution had to be logged somewhere on the internet.

Consider the following kind of code:

The library used for animation will have to set the display value of the address to something else than none before animating it’s opacity from 0 to 1.

What should this display value be?

One way would be to use a hash object to store the default display value of elements:

var defaultDisplay = {
  div: "block",
  span: "inline",
  p: "block",
  b: "inline",
  td: "table-cell",

But this object would be rather large, considering the list of HTML5 elements. It can also be guaranteed that some day, other elements will be added to this list, and the library would be incompatible with it. The solution found in most libraries is similar to this one:

However, this function fails with the code found in the first snippet, as it will return “none” for any address, figcaption, mark or ruby inserted in this document, because that’s what the CSS says!

iframe to the rescue

In jQuery, we resorted to use an iframe to sandbox the dummy elements we create: the iframe hosts a completely different document, and the elements you append to it are not affected by the original CSS.

It should be noted that creating an iframe is a very expensive operation: on my 3 years old laptop running Firefox4 for Ubuntu, it takes up to 17ms to check the default display value of an element. This is mitigated by trying to use the classical code first (which executes in a fraction of that) and caching the output of the function.

navigator.onLine alternative: serverReachable()

Remy Sharp blogged recently about the issues of the navigator.onLine property and online/offline events. Let see how they can be worked around.

Getting the browser to handle it is hard

As it turns out, this property and those events can currently only be relied on to tell whether and when the user decides to turn on/off the “Work offline” feature of the browser. Indeed, some platforms have specific behaviors that make it hard for the browser to be constantly aware of the computer connectivity: Windows sometime incorrectly report its connectivity after waking up from hibernation, NetworkManager on Linux can’t be trusted because some users bypass it, etc.
This is why, as of Firefox4 and until we can find a reliable alternative, only the user can switch to offline mode.

What onLine doesn’t tell

If you are building a website with offline features, using this property to switch between online and offline mode might not be the best option. Not only can it incorrectly report the connectivity of the computer, but it also doesn’t tell anything about the actual reachability of the server: you might be connected to a network blacklisting the service; you might have no connection but be developing a website locally; or the server could be down…

In any case, it is probably more reliable to simply send a request to the server and fallback to local storage/resources/database when the request fails.


Following is an example of code you can use to verify that the server is reachable

Improving the AppCache

Last week, Mark Christian & Dustin Diaz published AppCache Facts, a concise and pragmatic documentation about how to write a cache manifest to take your Web applications offline.

AppCache has the potential to benefit many websites, not only in offline scenarios but also on the performance ground. And yet, developers have struggled to use it in their projects because of the initial implementation quirks, the lack of documentation and tooling.

Now that the implementation and documentation parts are good enough, it’s time to get rid of the next papercuts. I gathered an initial list of those little things that could be fixed or improved to make the AppCache useful and convenient:

  • it should be possible to exclude the html file associated with the manifest from the cache,
  • it should be possible to cache resources from other origins on https too,
  • Firefox should stop asking for user permission and let developers see what’s in the AppCache.

What would you add to this list?
Leave a comment, and I’ll make sure the feedback is heard by Mozilla and Google engineers.