Adam Dempsey voted up an answer.

I think it is because it is a difficult problem to solve well.

HTML5 has many of the necessary capabilities to build and distribute full fledge offline applications such as Outlook and Powerpoint. However, there are still lot of work on the infrastructure side to make that a reality, especially if you are trying to repackage an online application to be offline capable.

Here are some of the "big bones" I see from my experience: 

1) Application states: One of the big challenge to make an online Web application offline capable is to make sure that all the state management and user interface artifacts (e.g., screens, behavior, and model) can be partitioned to the client without the need of a server. While of google applications are using Javascript-MVC driven frameworks (e.g, Closure/GWT like frameworks) it is still not trivial to partition all the components to be dual mode.

In an online mode, you usually architect your application to load components on demand, however, for offline, you need to be able to package all the components at once. Consequently, it can be pretty challenging to retrofit an online application into an offline one, even for the ones that already have a Javascript MVC architecture.

2) Indexed storage: One of the big thing currently missing in the HTML5 specification for offline applications is an indexed local storage API. Google Gears embedded SQLite which solved the problem across browsers, however, without Gears, only WebKit based browsers (and Opera) supports SQLite out of the box. There is a new initiative called indexDB which sounds promising, but it is still too early to tell if it will be widely supported. So, I guess Google did not feel it was worth implementing an "indexing engine" on top of today's name/value pair local storage HTML API, and might have decided to first work with the standard bodies to solve this problem at the HTML specification level (I am just guessing obviously).


3) Docs file format: Another issue is on the Docs side is that offline Docs require a portable and "upgradable" file format. My guess is that, as of today, Google Docs "content format" is very custom and would need significant rework to be portable. Creating a portable file format is not trivial task (from a social engineering and technical point of views).

4) Mail protocol: This is not really an issue for Google since it already uses its own proprietary HTTP protocol for accessing its GMAIL backend. But if someone else wanted to build a offline HTML5 app for Gmail, it will be stuck since there is no public HTTP api to access GMail backend services. Using HTML5 WebSocket to access the iMap/SMTP Gmail api could be a possibility, but might be quite a bit of work.

So, again, I think Google will eventually get there, since bringing offline to the Web is core to their vision, however, it will take time. At the end of the day, much of the work required for traditional desktop applications will be needed to make Web applications offline.

See question on Quora

Adam Dempsey voted up an answer.

I think it is because it is a difficult problem to solve well. 

HTML5 has many of the necessary capabilities to build and distribute full fledge offline applications such as Outlook and Powerpoint. However, there are still lot of work on the infrastructure side to make that a reality, especially if you are trying to repackage an online application to be offline capable.

Here are some of the "big bones" I see from my experience:

1) Application states: One of the big challenge to make an online Web application offline capable is to make sure that all the state management and user interface artifacts (e.g., screens, behavior, and model) can be partitioned to the client without the need of a server. While of google applications are using Javascript-MVC driven frameworks (e.g, Closure/GWT like frameworks) it is still not trivial to partition all the components to be dual mode. 

In an online mode, you usually architect your application to load components on demand, however, for offline, you need to be able to package all the components at once. Consequently, it can be pretty challenging to retrofit an online application into an offline one, even for the ones that already have a Javascript MVC architecture.

2) Indexed storage: One of the big thing currently missing in the HTML5 specification for offline applications is an indexed local storage API. Google Gears embedded SQLite which solved the problem across browsers, however, without Gears, only WebKit based browsers (and Opera) supports SQLite out of the box. There is a new initiative called indexDB which sounds promising, but it is still too early to tell if it will be widely supported. So, I guess Google did not feel it was worth implementing an "indexing engine" on top of today's name/value pair local storage HTML API, and might have decided to first work with the standard bodies to solve this problem at the HTML specification level (I am just guessing obviously).


3) Docs file format: Another issue is on the Docs side is that offline Docs require a portable and "upgradable" file format. My guess is that, as of today, Google Docs "content format" is very custom and would need significant rework to be portable. Creating a portable file format is not trivial task (from a social engineering and technical point of views).

4) Mail protocol: This is not really an issue for Google since it already uses its own proprietary HTTP protocol for accessing its GMAIL backend. But if someone else wanted to build a offline HTML5 app for Gmail, it will be stuck since there is no public HTTP api to access GMail backend services. Using HTML5 WebSocket to access the iMap/SMTP Gmail api could be a possibility, but might be quite a bit of work.

So, again, I think Google will eventually get there, since bringing offline to the Web is core to their vision, however, it will take time. At the end of the day, much of the work required for traditional desktop applications will be needed to make Web applications offline.

See question on Quora

Adam Dempsey followed a question.

Adam Dempsey followed a question.

In Orange (company): Adam Dempsey added a question.

In Orange (company): Adam Dempsey added a question.

In iTunes: Adam Dempsey followed a question.