HTML (“hypertext markup language”) is the core language that powers the World Wide Web. Any server side technology must in the end, display HTML in order for web browsers to be able to render web pages. HTML 5 is the latest revision of the HTML spec that is slowly being adopted by the different major browsers. There are some pretty exciting additions to the HTML spec and I wanted to go over a few and what they potentially mean for the future of the web.

New Tags
Structure Tags
New additions to the HTML markup family include tags like header, nav, article, section, and footer. From the visual perspective these probably won’t have a huge impact as users are unlikely to see the difference between pages built on the old DIV based layout and the new structure tags. However from the search engine perspective, these tags will make it easier for crawlers to distinguish between what’s the meat of the content and what is just fluff. Current DIV based layouts structure the content semantically through unique IDs and classes. We give these DIVs IDs and classnames like header, footer, post, etc in an attempt to classify and organize the markup. However these are abstract concepts from the browser’s perspective. If they wanted, there’s nothing stopping the web developer from naming the header something arcane like foobar or even call the footer something like nav_sub2. As you can imagine then, search engines and web crawlers must develop sophisticated algorithms to detect patterns in order to infer what’s a header or footer. However with these additions, the developer must clearly demarcate what section each HTML piece is, thus taking the guesswork out of the search engine. This has the benefit of potentially improving search engine results.

Canvas Tag
The new Canvas tag is exactly what is says it is – a blank canvas with infinite possibilities. Flash developers used to drawing pixels on the MovieClip object will immediately be able to relate. Essentially one would use the canvas tag to render any number of things from manipulated images, animation, or even 3D imagery. With the canvas tag, you could build applications such as a paint program, or a 3D slideshow without having to rely on Flash. As usage of the Canvas tag increases, you’ll see more animation and renderings that were typically done in Flash re-envisioned completely in HTML5 and Javascript. The drawback however is that whereas Flash is build once run everywhere that supports Flash, an HTML 5 solution would leave you vulnerable to browser compatibility issues.

Here’s a video of a Coverflow implementaion done purely in JS + the new Canvas tag

AV Tags
The Audio and Video tags promise to simplify the mess that is currently the state of the art when embedding video. Whereas before you had either the <embed> or the <object> tag depending on what browser you are using or maybe you just turned to a javascript based wrapper to handle your media needs, you can have a very simple video or audio tag. With the ubiquity of the Flash platform as a video player, I’m not sure this is going to make much difference. Sure this is a lot easier, but we really could have used this 10 years ago.

<video width="640" height="360" src="/demo/google_main.mp4?2"
autobuffer></video>

Web Worker
Think of Web Workers as threads – any jobs that can be computationally expensive and intensive. In the current model, a complex task on a webpage might bring the interactivity of the page to a crawl while it’s busy number crunching. A worker thread could be spawned off to do some intense client side crunching without bogging down the page. This is even more relevant in today’s time when so much is being offloaded to the front end UI with javascript libraries. A good candidate for web workers would be a browser based excel spreadsheet like Google Docs where number crunching on the client site is potentially very slow.

<script>
   var worker = new Worker('worker.js');
   worker.onmessage = function (event) {
     document.getElementById('result').textContent = event.data;
   };
</script>

Application cache
The Application cache allows web applications to function offline when it’s not connected to the Internet. Google Gears is an implementation of this. All the developer has to do is provide a manifest of files that the web application needs in order to function offline. I see this as a really great feature to make web apps more robust. With most webapps, if you lose connection, you most certainly lose whatever you were working on. I can see more and more applications handling loss of network connectivity more gracefully by taking advantage of the application cache.

All you need is this code snippet and a manifest file which lists all the files the application needs.

<html manifest="foobar.manifest">

Geolocation
The Geolocation API provides a scripting interface that lets the developer determine the user’s location (based on GPS or inferred from IP, Wifi, etc). The user must however allow the application to access that information. Although geolocation has been inferred by IP for a while now on the backend, we’re seeing an increase of functionality performed on the front end with AJAX and this is no different.

navigator.geolocation.getCurrentPosition(function(position));

Should I be using HTML5 tags?
Here’s a table outlining features I played around with in the latest browsers from Google, Apple and Mozilla.

* only certain formats
** sort of worked

As you can see, coverage on some of the new HTML 5 features is pretty good on Firefox and Safari. However with the audio and video tags, I did find that Firefox supports the open source codex Ogg Vorbis while Safari’s supports all the formats that Quicktime supports, naturally. So if you are looking to use some of the new HTML 5 features now, coverage on all the browsers is sketchy at best except for the Canvas tag. If you are trying to do video or audio, you’d best stick to Flash. I think where HTML5 is useful for the here and now is in the mobile sector. Many new mobile OSes including iPhone OS 3.0 and webOS have started supporting some of the HTML 5 features and since you would be developing platform specific apps, compatiblity issues are non issues.

Safari launched Safari version 4 Beta on Tuesday. There’s some good things and bad things about it.

I won’t go through every facet of the update (you can find a list on Apple’s site). I’ll be focusing on the features that stand out to me the most.

Tabs

Tabs are the most obvious UI change in Safari. In version 3 and earlier, Safari had inverted tabs placed below the address (and bookmarks) bar.

before:

Now, tabs are integrated into the top window bar and serve 2 functions:

- a draggable bar to move your application window around
- a group of individual tabs you can cycle through

after:

the bad: Because the top bar is now serving a dual function, it’s harder to focus/select an individual tab. This is because Safari’s first response to an interaction (click/press) with the top bar is to treat it as an application window you can drag. If the interaction hierarchy were flipped, and tab selection was first priority, window dragging would prove to be nearly impossible.

While you can focus a tab by carefully clicking anywhere on the bar, it takes a few tries, unless you start to train yourself to move straight to the right corner of a tab, where you’ll see the ‘grip’ lines.

Bottom line, Fitt’s Law is being comprimised.

the good: On a positive note, about 20 pixels of vertical screen real estate is gained with the combined browser/tab bar. Economy of space is a great thing and it’s especially relevant on laptops.

Web Inspector – Design Consistency & Data Visualizing

A great feature that I probably won’t be using very much is the Web Inspector. For developers out there that use programs like Firebug within Firefox, the Web Inspector will look very familiar. It allows you do to look behind the scenes of a given page and view the HTML and style sheets as well as see how quickly all the elements within a page load. Coupled with the Activity window, it’s a great way to debug websites.

Like all things Apple, its not only how well the Web Inspector works that makes it great, but how well it’s visually designed. When I toggled from Elements view to Resources view, I was again pleasantly surprised to see that they had appropriated repurposed the iTunes Resource visualizations for the iPod and iPhone:

Web Inspector – Resources:

iTunes – iPhone capacity:

RSS Feeds

I don’t get the option to choose what application/service I want to use to read feeds when I click on the RSS icon in the address bar. Firefox gives me the option to choose Google Reader.

What happened, Apple?!

Address Bar & AutoComplete

This is the clincher for me. Safari 4 Beta does not let you type in any part of the address, or title, of the site you want to go to. This has become an integral part of navigating the web for me and the best improvement from Firefox 2.

It’s a feature that’s easy to overlook until you don’t have it anymore, then you realize you can’t live without it.

Summary

Safari 4 is in many way’s a solid step up from from Safari 3. Nothing feels broken or incomplete, and it is dramatically faster (as reports have claimed). Along with the autocomplete issues, the lack of add-ons is the only other major drawback that’s keeping me from switching from Firefox 3. Adblocker, Delicious, Tabs Open Relative – sure I only have 3 add-ons, but they make a world of difference when browsing.

For the non-techie user, Safari is an excellent choice.

It’s like a Porsche without power windows and door locks – sure they’re drawbacks, but the car still drives like a dream.