Google Goes HTML5

I just noticed that Google is now serving it’s homepage with an HTML5 doctype:

< !doctype html>

I suspect this might have changed when they launched that new fade effect. I also noticed they are doing so when using the new YouTube “Feather” beta. This shouldn’t be too surprising considering their involvement in the HTML5 specs and developing a web browser and announcing it’s moving away from Google Gears.

Of course the pages don’t validate, and don’t really take advantage of much HTML5 features (that I’ve seen at least). But it’s a step in the right direction. With modern browsers like Firefox, Chrome, Safari becoming more popular it’s slowly becoming a reality.

Google Is Moving Away From Google Gears

LA Times is reporting:

“We are excited that much of the technology in Gears, including offline support and geolocation APIs, are being incorporated into the HTML5 spec as an open standard supported across browsers, and see that as the logical next step for developers looking to include these features in their websites,” wrote a Google spokesman in an e-mail.

I complained a while back that things seemed too fragmented. To date I’ve been pretty leery of things because I wouldn’t want to support two competing methods or require users to either download Google Gears or use a browser that supports cutting edge technologies. It’s either too much effort and code footprint, or too much effort from the user perspective to download another binary.

A few Google folks replied to my earlier blog post and noted that they fully intended to work towards convergence. I’m glad it’s finally becoming a reality. I hope Google Gears will continue to be developed for the purpose of filling in missing functionality for certain browsers that tend to fall behind and simply let the browser take over if and when it eventually supports that functionality. That would create a consistent environment across platforms and browsers.

Google Gears For Safari And Other Browser Addons

Google today released a beta of Google Gears for Safari. Still no iPhone support, but that’s not likely due to Apple’s rather restrictive licensing rather than technical reasons. It’s good to see them keeping true to their original efforts to support all platforms equally. That’s been a gripe of mine recently.

With Google creating Gears for all browsers, Apple creating QuickTime on all browsers, Mozilla creating <canvas /> support for IE, Microsoft creating Silverlight and Windows Media Player for all browsers (though Mac users are through Flip4Mac) it creates an interesting web of technologies. Everyone is starting to fill holes on other platforms. The downside to this is that users need to download multiple components for a good web experience. That is still a major concern for the future of the web. It’s not all about licensing.

Rebreaking The Web

It’s happening again. Once upon a time, browser vendors started adding their own features without consulting with each other and agreeing upon standards. What they created was a giant mess of inconsistencies across browsers and platforms that is still in effect today. Ask any web developer and they can tell you of the pains that they have suffered trying to make seemingly trivial things work everywhere consistently. It’s no easy task. Before IE 7, even an ajax required something along the lines of:

var httpRequest;
if (window.XMLHttpRequest) { // Mozilla, Safari, …
    httpRequest = new XMLHttpRequest();
} else if (window.ActiveXObject) { // IE
    httpRequest = new ActiveXObject("Microsoft.XMLHTTP");
}

That’s right, IE 6 didn’t support the native xmlHttpRequest object (more here). This is just one of many examples in JavaScript and CSS. document.all anyone?

The end result of this problem became to be known as the “Web Standards” movement. Simply put it’s an idea that code should follow a standard that results in consistent output across all browsers on various platforms. Write once, run anywhere. While it’s taken years for this to manifest, it’s slowly become a reality. Firefox, Safari, Opera have fairly consistent rendering (at least in comparison to the mess of just a few years ago on the browser scene. IE 6 was fairly poor in terms of modern web development, but IE 7 made progress, and IE 8 is Microsoft’s greatest effort to date to bring their browser up to speed.

Continue reading

The Winner For Most Embedded Is: SQLite

So the format war of Blue-ray vs. HD-DVD is over. There are still several other rather significant battles going on in the tech world right now that aren’t Microsoft vs. Apple or Yahoo vs. Google. For example:

Adobe Air vs. Mozilla Prism vs. Microsoft Silverlight

Google Gears vs. HTML5 Offline support

Android vs. iPhone SDK vs. Symbian

Ruby On Rails vs. PHP

Not every case will have a true “winner”. That’s not really a bad thing. Choice is good. In some cases they will merge to form one standard, such as what’s likely for offline web applications.

What is interesting is that SQLite really dominates right now. Adobe Air, Mozilla Prism, Google Gears, Android, iPhone SDK (likely through Core Data API), Symbian, Ruby On Rails (default DB in 2.0), PHP 5 (bundled but disabled in php.ini by default). It’s becoming harder and harder to ignore that SQL survived the transition from mainframe to server, and now is going from server to client.

No longer is the term “database” purely referring to an expensive RAID5 machine in a datacenter running Oracle, MySQL, DB2 or Microsoft SQL Server. It can now refer to someone’s web browser, or mobile phone.

This has really just begun to have an impact on things. The availability of good information storage, retrieval, and sorting means much less of these poorly concocted solutions and much better applications. Client side databases are the next AJAX.

Edit [2/27/2008 9:14 AM EST]: Added Symbian, since they also use SQLite. Thanks Chris.

Mozilla Prism

Mozilla Prism is an interesting product. What I really like is that it requires no real extra work for your app to run in it. With some additional effort you can potentially add some great stuff (offline support for example). It’s too early to develop applications for it just yet, but it does show off some serious potential. I did two tests as an example:

Google Calendar

Url: http://calendar.google.com (SSL doesn't seem to work at this time)
Name: Calendar
[ ] Show location bar
[ ] Show status messages and progress
[x] Enable navigation keys

Create Shortcuts
[x] Desktop
[ ] Start Menu
[ ] Quick Launch Menu

CBSNews.com Video Player

Disclosure: My employer.

Url: http://www.cbsnews.com/sections/i_video/main500251.shtml
Name: CBSNews.com Video
[ ] Show location bar
[ ] Show status messages and progress
[x] Enable navigation keys

Create Shortcuts
[x] Desktop
[ ] Start Menu
[ ] Quick Launch Menu

Both worked nicely. It gave me a way to keep the app open independently of my browser. The second test proves the next thing I wanted to mention. Plugins are supported. No reason why you can’t use a Flash player for example. Of course you could also use <video/>. I wonder if Google Gears could be installed on it? You can use about:plugins as an application url to see what plugins are installed (I believe it should be the same as Firefox). There doesn’t seem to be an about:prism just yet.

There are however some security aspects that an application like this must take into account.

Improvements

There are a bunch of things I’d love to see. For example:

  • API for Interactions – For certain events such as minimized/maximized (or user-visible/user-hidden to make it more neutral in terms of meaning). Also one for for opening a file so that the OS could map a file to be handled by an Mozilla Prism Application. The event could be handled similar to that of an upload. Haven’t looked to see what WHATWG offers in regards to these two things.
  • Extensions Support – Think of this as an interface/vehicle for XULRunner. Full window apps like Calendar could be run in Prism. This provides a common runtime shared across multiple applications.
  • Install Mechanism – To share the two things I did I had to document my settings up above. The ability to pass those perhaps using a protocol would be really nice. For example:
    prism://url=calendar.google.com/&name=calendar&enableNavigationKeys=true&createShortcuts=prompt

    would then open prism who would then ask you if you want to “install” this application. Bonus points if it accepted a base64 encoded icon similar to a data:url and used it. Using an technique similar to what Apple does for iTunes and having a landing page would give the user the option to install Prism if they didn’t have it already.

Great stuff. I can’t wait to see where it goes from here.

Edit [10/29/07 @ 11:45 PM EST]: Fixed bad url in example.

Google Gears

In case you were wondering what Google Gears meant to the planned support for Offline Web Applications in Firefox 3.0, here’s an article you may be interested in. No definitive answers, but does mention the possibility of combining ideas.

Google Gears is pretty cool, but I’d be much more comfortable if Google submitted the API as part of WHATWG and it were standardized. Google Gears would then be the way to use it without a browser having native support. I personally don’t like the idea of competing implementations.