1.) HTML is EVOLUTION not REVOLUTION.

HTML is already well defined and ubiquitously used. HTML 5 offers n interesting collection of INCREMENTAL enhancements to existing HTML syntax.

HTML5 offers “native” ways to do do things that we already do with JavaScript / Silverlight / Flash or Server Side Code.

There will be advantages but, as is often the case, the “big wins” will be the new scenarios that developer invasion.

HTML is a collection of new tags, elements, attributes, features, etc. NOT an full replacement for existing HTML.

2.) HTML5 is not really”A” standard. (It’s several.)

One of the must frustrating things about being a Web Developer has always been the incompatibilities between browsers. In recent years the compatibility between current browser versions has improved (though we’ve still been stuck with the lingering use of Internet Explorer 6).

HTML5 will probably bring back the browser wars. Though nothing is set in stone yet, it seems certain that different t browsers will provide support for different collections of HTML5 “features”. [ See more HERE. ]

Given this inevitability, building a public facing site will always mean supporting users who make different browser choices, and that means using HTML5 features will REQUIRE our code to proactively do feature detection.

Historically speaking, server side detection of browser features is a less than perfect mechanism. Our HTML 5 pages will need JavaScript code will need to confirm support for a given feature at runtime before we use it and provide some strategy for when that feature is not supported in the user’s browser.

This means that sometimes it will be easier to depend on3rd party technologies like jQuery or Silverlight since we can detect it’s presence ONCE and then code against all the features provided.

3.) People just don’t update their browsers.

IE6 was released in 2001 and as of this writing still hangs on to 5% market share.

Our web applications are still going to have to be coded to degrade gracefully. While this is not rocket science, it inevitably means more work for the web developer. In fact, this is true of all new browser supported features. Unless we want to simply ignore users that are not using the latest and greatest technologies that we choose to target, each features of “ne” browsers that we with to support will require incrementally additional coding to degrade gracefully. This is another example of where a 3rd party product (like jQuery or Silverlight) may be easier.

Of course, there are JavaScript libraries starting to surface to simplify this process. [ Like Modernizr. ]

4.) It’s still all “Jelloware”.

HTML has had a wacky standards process since its very beginning and HTML5’s definition seems to be no different.

The HTML standards definition process has been a strange combination of speculative discussion and post implementation forensic. In many cases browser manufacturers implement features that they desire or think is important and the ones that are most successful are the ones that make it in to the specification.

Which HTML things make it into the specification and then with of those things are actually implemented by any specific browser maker (let alone all of theme) is still up in the air.

It seems that some very interesting functionality (like WebSockets) may be included in the spec but not implemented by all browsers – or just the opposite. It may be implemented by some “HTML5” browsers but not even make the specification.

5.) Everybody wants a piece.

Google is all over the HTM5 process, Microsoft , Adobe and Yahoo have significant interest. As is always the case, these corporate influences can change or delay the finalization of what is already a tediously slow standardization process.

6.) The “OffLine” APIs

Even giving the challenges outlined above there are very interesting opportunities presented by HTML 5. One of the ones that I find especially exciting is the set of Off-Line APIs.

As an industry we’ve been looking for elegant ways to handle O-Line / Off-Line application building for a long time and some of the choices have met with limited success. (Silverlight OOB, Adobe AIR, etc.)

HTML5 offers an opportunity to provide a “disconnected” experience in a real browser based application. Application Cache / Manifests, Local Storage, and the “Editable Element” features of HTML5 make for some very interesting prospects for building applications that are not always connected.

Does this make Silverlight and Air fully obsolete?

I don’t think so. I think we’ll still choose based on application feature requirements and most common user scenarios. Silverlight will still be a better choice for frequently disconnected user experiences.

7.) Canvas

Image Drawing directly sported by the browser ?

Conceptually the HTML5 Canvas is very exciting but I still have questions.

HTML5 Canvas is BITMAP based (not Vector), how frequently will I need the more advanced  drawing capabilities of SVG or XAML? If the answer is statistically significant, does it make sense to invest in developing for HTML5 Canvas or should I just standardize on a richer solution for my drawing needs.

Canvas performance is also an open question for me. Even simple Canvas demo applications tested in Firefox do not yet seem to perform very well. WhenHTML5 fully arrives, will performance across all HTML5 browsers be good enough for my needs. Only time will tell.

8.) Built in Video and Audio Support

The Video and Audio support in HTML5 won’t replace the use of Silverlight or Flash players for non-trivial media uses but it will be VERY convenient for embedding. As multi-media becomes more and more prevalent and broad band internet access continued to near ubiquity, web application uses have come to EXPECT audio and video in the web sites they visit.

With HTML5 it gets very simple.

<video src=”movie.ogg” controls=”controls”></video>

9.) HTML 5 Web Workers

Though the browser specific implementation details may differ, the general idea behind HTML5 Web Workers is to allow the web developer using JavaScript to create background process (typically running on separate threads) and thereby taking advantage of multi-core processors.

This feature will allow us to creatively improve the performance of browser based applications especially when they require (relatively) long running processes like AJAX calls).

Note that HTML 5 Web Workers will not replace all the multi-threading scenarios that Silverlight threading can solve. For example, HTML5Web Workers can not access the web page’s “window” object which means they lack direct access to the web page and the DOM API.

If you’re use of threading is to add update dynamics to you UI then upi will probably want to stay with Silverlight bu if yo’re working with HTML 5 Web Sockets or AJAX or a variety of other scenarios than HTML5 Web Workers may be very useful to you.

10.) There is MUCH More !
  • Web Sockets
  • Semantic Markup
  • Selectors API
  • window.JSON
  • JavaScript Logging & Debugging
  • Geolocation
  • Communications API
  • Forms API
  • Web Storage
  • Futures (WebGL, Touchscreen, etc.)

There is A LOT in the works. It’s easy to limit our view of something as broad as HTML 5.

The good news is that most of HTML 5 is incremental so we can evaluate and adopt incrementally as well.

Moving forward…….

I’ll be doing a lot with HTML5 in ASP.NET and posting it all here at MSJoe.com

Stay Tuned and feel free to use the Contact form here to send me requests and suggestions.

Technorati Tags: ,