For a while now I have been reading through the new HTML5, CSS3 and JavaScript specs and posting my results with regards to browser support etc. on thebrowsereview.com. Recently I started looking at Offline Web Applications. One of the many interesting things I found is the navigator.onLine property. The W3C spec states the following:

In addition to those APIs HTML 5 also defines an onLine attribute on the Navigator object so you can determine whether you are currently online

This can be very useful. Another part of this is the ‘online’ and ‘offline’ window events that are fired whenever this property changes. I went ahead an created a simple test page, you can see it here, that tests the implementation of it, the code is as follows:

window.onload = function() {

	var showOnline = function() {
		document.getElementById("offline").style.display = "none";
		document.getElementById("online").style.display = "block";
	},
	showOffline = function() {
		document.getElementById("online").style.display = "none";
		document.getElementById("offline").style.display = "block";
	}

	window.addEventListener("online", function() {
		showOnline();
	}, false);

	window.addEventListener("offline", function() {
		showOffline();
	}, false);

	if(navigator.onLine) {
		showOnline();
	} else {
		showOffline();
	}
}

With the above, on initial load of the page it will show the indicator that reflects your current online status. If you then loose connectivity or reconnects, the script will change the indicator accordingly.

First off, there are only two browsers that currently implements this, the one is Chrome and the other Firefox but, here is where I ran into a problem. In Chrome, when I load the page and are online, using a local copy that needs no connectivity, Chrome reports that I am online, if I then disconnect and reload the page, it reports me to be offline, perfect.

Next test was to leave the page loaded and disconnect and see what happens. As soon as my connectivity is lost, Chrome fires the offline event and the indicator changes to offline and vice versa. Next I tested this in Firefox 4.

Interesting thing here is that Firefox always returned true, whether I am connected or not. This is the case for both page load as well as changing the status while the page is loaded. With this, I decided to log a bug as I believe this not to be the ‘correct’ implementation of the standard.

I had a very quick response from Boris Zbarsky explaining what Firefox 4 is doing:

We return false when we’re in offline mode.  Firefox 4 only enters offline modeif the user explicitly requests so (it’s an option in the file menu).  If we’renot in offline mode, we will try to access the network if you try to “follow alink” or “request a remote page”.  So per spec, we’re returning true unlesswe’re in offline mode.

And citing the WHAT-WG spec that states:

The navigator.onLine attribute must return false if the user agent will not contact the network when the user follows links or when a script requests a remote page (or knows that such an attempt would fail), and must return true otherwise.

I believe the bit in parenthesis are key in this case. To my mind this makes the spec ambiguous and results in the differing implementations of the same standard.

With Firefox switched to offline mode, it will not follow any links that needs a network connection to resolve and then in this case returns false when calling navigator.onLine. While in offline mode, Firefox will also fire the online and offline events on an already loaded page. This implementation of the standard can then be strongly linked to this part of the spec:

The navigator.onLine attribute must return false if the user agent will not contact the network when the user follows links or when a script requests a remote page and must return true otherwise.

The, or knows that such an attempt would fail I would link more to the implementation by Chrome. So who is correct here? I would venture to say both. So what is the point I am trying to make here?

Well, it is four fold. First off, these are only two of the ‘big’ five with such non interoperable implementations of the same standard, what if Opera decides to implement this yet another way and Internet Explorer another? What is left of what we call a standard?

Secondly, the people behind the specifications are extremely knowledgeable people and work very hard but they need to avoid creating ambiguity. Thirdly, I sincerely hope and, at the same to ask, the browser vendors out there to communicate their intention to each other when it comes to the implementation of these standards so that we can have unity and move away from the fragmentation that still exists in the web world.

And lastly, we as web developers must never forget that we have the responsibility to communicate, and there are multiple ways to do this, and provide feedback to the specification writers as well as the implementers. This should also not be a once off but, be a continuous process that should not be dominated by the demands of one single tier.

In closing, what we are all working towards is a unified, interoperable browser landscape based on standards, that removes the need to code to browsers and versions. The standards should therefore be clear and concise and so should the implementation thereof so that one can be assured that if your code follows the standard, the results will be the same no matter what user agent the user chooses.

All of this will give users a true freedom of choice and allow developers to focus on creativity and innovation as apposed to coding to the lowest common denominator and spending hour upon hour on browser compatibility. What are your thoughts? What do you expect from the W3C, WHAT-WG and browser vendors in terms of the standards that are currently being defined and implemented? I look forward to reading your comments.

Image courtesy: Fitgerald