This review is doing double duty. It evaluates the book HTML5: Up and Running by Mark Pilgrim from the O’Reilly Press while also doing review of the status of the HTML5 standard itself. Keep an Open Eye acknowledges that Mark’s HTML5 : Up and Running and also Diving into HTML5 have been invaluable resources for getting quickly up to speed into what has been a 12 year wait [and counting] for a major update to the Web’s key client side standard, HTML.
Another motivator is indicated by the “!?”exclamation/question mark in the title for this blog posting. Right now HTML5 is a mixed blessing. HTML5 has some very attractive features such as bitmap Canvas operations [strong support], SVG-Scalable Vector Graphics support [mixed support] and multi-touch screen operations[support in its infancy]which are vital to the new mobile era of computing. HTML5 is viewed by many as one of the few common development languages usable by all the rapidly expanding UI-User Interfaces being made popular by Apple’s iDevices, Google’s Android, Microsoft’s Kinect, and other new mobile client UIs on smartphones, tablets and other electronic gadgets. The downside is the mixed support for some of the critical sub-standards that make up HTML5. This status report reveals where the logjams are in getting a robust, cross platform development environ using HTML5.
The final motivator is the fact that Microsoft, after 12 years of being remiss on delivering promised HTML, CSS, and DOM standards, released the beta of IE9 in September which not only patched many of those 12 year old missing standards but also will show substantial improvements in its HTML5 implementation and performance . But as always with Redmond and the Web, there are some distinct downsides. Windows XP, despite having 50% plus of total Windows market share has been ruled out for IE9 [Redmond is forcing the customers choice- switch to one of four other great browsers or do the time and costly upgrade to Windows 7]. In addition, Microsoft is selectively implementing HTML5 [see chart below], has yet to commit to all of HTML5 and its associated features, and may have some direct hardware dependencies buried into its IE9 Web code. Much will be revealed with final IE9 browser release in 2011.
Mark Pilgrim has written another version of this book entitled Diving into HTML5 which is publicly available here. There are differences [particularly in styling and illustration]but the O’Reilly version is more complete. However Diving into HTML5 has a 5 point preface that is well worth repeating here because it forms the heart of our review of HTML5: Up and Running. Mark makes the following points-
1)HTML5 is not one big thing; but rather is broken down into 10-15 big feature sets which you can individually check for then augment and make extensions or substitutions based on tested availability of HTML5 features in the browser your web page is being displayed with. This is also indicative of the incremental approach taken with HTML5 which help win it acceptance after a shaky start.
2)You don’t need to throw anything away as HTML5 supports almost all of HTML4 with very few exceptions – largely deprecations of redundant or obsolete tags,events, and/or properties. See here.
3)HTML5 is easy to get started in. Given HTML5’s very high backward compatibility with HTML4, support of long developed extensions like SVG, MathML, XForms [and others], plus the work on many HTML5 feature sets by 4 of the 5 major browser vendors, some major features are nearly complete. But before diving into HTML5 as recommended by Steve Jobs, be aware that a)all browser vendors are barely 2/3 rds of the way complete towards implementing HTML5 [see the table immediately below]; b)there is not a great deal of uniformity in how the browser vendors have delivered their versions of HTML5 to date [also illustrated below]; c)some key features of HTML5 are missing or lacking completed/consensus standards specification such as multi-touch + gestures, devices or Web Database; as the importance of HTML5 and the broader web interface increases, fractious disputes among the standard setting parties is on the increase[see history below]. So HTML5 is easy to get started in but Web and mobile developers have to be very careful in how, where and in what way they will be planning to use HTML5.
4)HTML5 already works – again see the table and charts below for an overview of how well it already works.
5)HTML5 is here to stay – and clearly there is a lot of momentum and works towards improving their HTML5 support among all five major vendors [include Microsoft now]. Again, the table shows Firefox improving by 37% in one version update while Microsoft IE, though still trailling all other vendors in HTML5,has improved by 300% in the move from IE8 to IE9. But this web developers has plenty of wounds from past browser wars, so I am from Missouri waiting to see a)how quickly key new standards like multi-touch are approved and b)how quickly and uniformly HTML5 is implemented by all vendors. Many of HTML5’s key features are in the last 1/3rd unfinished state or the unspecified part of the standard.
Finally, Mark could have added explicitly [it is certainly implied in many of his topics] 3 more points regarding HTML5:
7)What is in and what is out of HTML5 is currently subject to a great deal of confusion, omission+overlap with other W3C Working Groups, plus politcal jockeying as the impact of W3C standards are critical for rapidly evolving PCs, mobile devices and smartphones with their market dominating innovations and product introductions.
8 ) HTML5 has a history that is tied into past Web development and W3C standards making. As seen below this history has not only shaped HTML5 in the recent past; but continues to drive HTML5 standardisation and development today.
Mark points out that HTML5 is a reaction to Web Development and W3C Standards directions from roughly 1998 to present [see here for a pithy yet valuable summary] and he is right on. In December 1997 the HTML 4.0 standard reached final recommendation and by May 1998 the W3C was considering an effort to use XML to rationalize and improve HTML :”it was agreed that further extending HTML 4.0 would be difficult, as would converting 4.0 to be an XML application. The proposed way to break free of these restrictions is to make a fresh start with the next generation of HTML based upon a suite of XML tag-sets“. Two months later, in July 1998 the 2nd HTML working group [aka XHTML1 working group]was constituted with the goal of “redefining HTML as a modular application of XML” . This was followed with the statement that “maintenance of HTML 4.0 [will now be] limited to tracking messages and keeping errata“.
HTML was dead and to be replaced by XHTML. In Aug 1999 the XForms requirements [extensions to HTML’s <form> tag] are published by XHTML working group with the proviso that backward compatibility with existing HTML4 forms controls could not be provided. Then in Jan 2000 when the final bug fix of HTML 4.01 is announced XHTML1 is also announced including its controversial Draconian Error Handling. This rule required that all XHTML tag or markup errors be treated as fatal errors. This was in contradiction to previous Web experience and browser development direction to date that used validators to point out syntax errors but at delivery time tried their utmost to deliver a page with no/minmal error messages while interpolating what were the page designers+developers intentions. As we shall see this has been a simmering issue at W3C.
In June and July 2000, the XHTML 2 receives its charter “to see through to completion the transition to XML” and the working group produces XHML1.1 . But 2 months later, the XHTML working group provides a work around for XHTML’s Draconian Error Handling. XHTML can have two Mime types – text/html and xml/xhtml. The first does not have to enforce XHTML’s any and all markup errors be treated as fatal. But between 2000 and 2004 XHTML continues to insist on no backward compatibility to HTML4 and draconian error handling be the standard. Finally in June 2004 a W3C Committee considered and rejected by an 11-8 vote an incremental approach to HTML standards development in favor of the XHTML group’s sweeping upgrade.
So then in August 2004, a consortium of browser developers and vendors including Apple, Mozilla, and Opera formed the WHATWG.org group. They started work on their version of XForms that would maintain backward compatibility to HTML4 plus a small set of Web Application features. By 2007, when the W3C wanted to get back into HTML development based on the fast evolving AJAX and Web 2.0 developments, the WHATWG.org -Web Hypertext Application Technology Working Group had made substantial progress on usable Web features that were backward compatible with HTML4. These improvement like like bitmap drawing, offline operations, and new layout element tags met rapidly evolvng Web 2.0 inspired development needs. So WHATWG and many members were invited back into the W3C as a second parallel and incremental effort to improve HTML under the HTML5 Working Group.
Then in 2009 the XHTML2 group was discontinued and the HTML5 working group became the principal developers of the HTML standards. This change-over has caused some tension among the W3C standards players and discrepancies as to what is in or out of the HTML5 standard. In effect, HTML5 became a replacement for XHTML 2.0 which the W3C discontinued work on in 2009. Mark argues that XHTML2 ran aground first on its Draconian Error Exception rules. Secondly, the XHTML working group failed to deliver even incremental updates to HTML itself as backward compatibility with HTML4 was unacceptable. Finally, some key XHTML utilities just were not delivered in a timely or complete manner. So in effect, WHATWG which included the 4 the major browser vendors [Apple, Google, Mozilla and Opera. Microsoft was invited but declined to join the group]became the drivers of a substantial portions of the HTML5 standard.
During this same period, Microsoft had become almost antagonistic towards Web development. Microsoft had stopped all development on IE except for bug fixes an security updates on August 2001 and had absented itself from active web standards participation. As noted here, IE did not get an update for 5 years until October 2006. And the IE7 and IE8 releases still performed worst among browsers for both speed and standards compliance. Only with IE9 announced in March of this year, has Microsoft re-entered the web development scene with vigor. But like in smartphones and portable devices, Redmond is coming from well behind. As Mark summarizes, the HTML5 ascendancy as a W3C standard in a simple phrase – “the ones that win are the ones that ship”. As we shall see this is a dual edged sword as vendors race to provide de facto standards for new features ahead of everybody else. But for now, WHATWG.org and therefore Apple/Google/Mozilla/Opera is leading the HTML5 standardization parade.
So from the history we see that Mark Pilgrim’s book, HTML5: Up and Running has a large measure of truth going for it. Substantial chunks of HTML5 are up and running. A quick survey of the popular browsers using the HTML5test.com benchmark of HTML5 compliance found the following scores for each browser:
|Browser||Test Score- 300 Maximum|
|Apple Safari 5.0.1||207+7 bonus points|
|Firefox 3.6.4||139+4 bonus points|
|Firefox 4 Beta2||190+9 bonus points|
|Google Chrome 6.0.4||212+10 bonus points|
|Opera 10.61||159+7 bonus points|
|Microsoft IE9 Test1||95+3bonus points|
Mark provides some good links to HTML resources. Here is one that provides a good overview of HTML5 current status. It is well worth visiting because it shows the fast evolution of HTML5 in the past 3 yearsThe clever graphic uses HTML5+jQuery to depict HTML5’s status:
This chart shows the rapid advance over the past 3 years of HTML5 in the major browsers. One proviso, the chart itself reflects the rapid change this past year as it is behind the latest browser releases: Opera 10.5 vs Opera 10.6 available, Chrome 4 versus Chrome 5 available, and Safari 4 versus Safari 5 available. Also the chart does not show gradations in compliance. Take the <canvas> status from the screenshot – IE9 is given no credit where the IE9 test version 3 certainly matches the 70% or better compliance of most browsers:
This is the other problem with HTML5 – not only are the features not uniformly implemented by the various browsers; but also within features there is substantial variability. Click on the above chart to see how much there is in the tag implementation.
Finally, Mark has a small parable on HTML. He seeks to discover the origin of the <img> tag in HTML as proposed by Marc Andreessen of Mosaic soon to become Netscape back in 1993. Though <img> had little compliance with the SGML template being used for creating HTML tags at the time [1993-94] and others had working code and solid proposals, Andreessen’s <img> tag won out because it shipped with the wildly popular Mosaic browser, worked and did not break existing programs. The meaning of Mark’s parable: in creation of standards do not look for design principles or even agreed upon templates to carry the day; but allow for popular working code [“the ones that ship”] to carry the day as well.
<new tag elements> – <aside>, <nav>, <header>, and other new sectional tags and their associated events.
CH-20/30, FF-22/30, IE-, OP-11/30, SA-18/30
<canvas> – allows 2D drawing of using lines, shapes, gradients, text etc into a user defined area on a web page.
CH-20/20, FF-20/20, IE-, OP-20/20, SA-20/20
<video> – allows embedding 4 different type of video recordings with customized user controls, bordering and colors
CH-22/27, FF-22/27, IE-, OP-22/27, SA-22/27
<audio> – allows embedding audio players with user customized controls, duration, program control
CH-20/20, FF-20/20, IE-, OP-20/20, SA-20/20
<storage> – like cookies allows storage of data on a users computer but with unlimited size, duration, and user control of playback to server. The key to offline running of live web pages.
CH-15/20, FF10/20-, IE-, OP-15/20, SA-15/20
CH-10/10, FF-10/10, IE-, OP-10/10, SA-10/10
window.applicationCache – Offline Web operations using a special application cache which can be used to communicate back to the Web server on resuming the online connection.
CH-10/14, FF-14/14, IE-, OP-10/14, SA-14/14
navigator.geolocation – geolocation APIs enable browser to interrogate and report where they are located – this is a dual edge capability, see WSJ’s Web Tracking debate
CH-10/10, FF-10/10, IE-, OP-10/10, SA-10/10
<forms> extensions – several new <input> types and placeholder text are part of extensive Web forms additions
CH-34/38, FF-6/38, IE-, OP-30/38, SA-32/38
microdata – this API is for specialties like VCARD creation and browser/search engine data similar to <meta> tags
CH-0/10, FF-0/10, IE-, OP-0/10, SA-0/10
Now Mark stops here in terms of looking at the major HTML5 feature sets and their detection; but many readers may wonder aren’t there some big chunks of HTML5 missing? What is going on? That is why HTML5 history is important because HTML5 is certainly a chameleon. Several W3C working groups are “co-developing” HTML5 based on the the original design work done by WHATWG.org. This WHATWG work [and it is ongoing] called Web Application 1 [see the spec here] is feeding not only the core W3C HTML5 spec but also those other W3C working groups [often providing the starting template for the groups charter].
WHATWG.org is the loose alliance of all the other browser vendors but Microsoft [remember, Redmond was invited but declined to join WHATWG]. It is actively test driving not just the HTML5 core spec but the broader reach of specs not officially labelled HTML5 but intended to be integrated with that spec. Third parties have gotten at least two kicks at the HTML5 cat – during the WHATWG formulation+ testing and then during the W3C candidate process. In sum, this is the way Ian Hickson, editor of both WHATWG and the HTML5 Working Group, sees HTML5 going forward. There is a core HTML5 set of features and then a broader set of Web Applications which includes the HTML5 core. Here is Ian’s view of how “full” HTML5 breaks out – topics highlighted in pink are not covered in Mark’s books.
|WHATWG Specifications (and sections therein)||Section links for Web Applications 1.0||W3C/IETF Specifications|
|HTML5 only (excluding newer features)||Single-page, Multi-page (HTMLWG)|
|Microdata||In WHATWG HTML||Microdata||Microdata (HTMLWG)|
|2D Context||In WHATWG HTML||2D Context||2D Context (HTMLWG)|
|Communications – Cross-document messaging||In WHATWG HTML||Cross-document messaging||Communications (HTMLWG)|
|Communications – Channel messaging||In WHATWG HTML||Channel messaging||Communications (HTMLWG)|
|Device Element||In WHATWG HTML (note: not in Last Call for HTML5)||Device see also ||HTML Device (HTMLWG) see also |
|Web Workers||Web Workers specification||Web Workers||Web Workers (WebApps WG)|
|Web Storage||Web Storage||Web Storage (WebApps WG)|
|Web Sockets API||Web Sockets API||Web Sockets API (WebApps WG)|
|Web Sockets Protocol||Web Sockets Protocol||The Web Socket Protocol (IETF)|
|Server-Sent Events||Server-sent Events||Server-sent Events (WebApps WG)|
|Web SQL Database (stalled)||Web SQL Database (WebApps WG)|
Note what is missing from this full HTML5 spec – multi-touch and gestures. So now lets look at how Mark’s HTML5 Up and Running covers these features.
HTML5 adds a number of new element tags like <aside>, <nav>, <header>, <footer> etc. But unlike <h1>, <h2>, <li> or <hr> tags, these new tags do not have default styling behaviors associated with them. In effect the user is responsible for their layout positioning and final styling. If you want the header to always appear at the top of the page regardless of positioning in your web page .html file, then you are resposible for placing the <header> tag through CSS on the page as desired. Likewise if you want <aside>with a border and special script you can do so with a CSS styling which adds a border, specifies the font-size and sets the background color to have your look and styling. HTML5 truly embraces CSS and with CSS3 [not strictly part of the standard], offers Web designers and developers enhanced styling features.
Mark points out the new tags and the emphasis on CSS has three advantages – i)the user gets to customize their layout precisely and ii)the HTML becomes less encumbered and more readable both for the Web developer and iii)by SEO Web spiders. In addition, browsers [aka user agents in W3C speak] can make provision for special accessibility requirements associated with impaired users. In sum, look for Web tool vendors to take advantage of these new tags in their various templates and layout engines.
Mark does two other things in this chapter. First he spends time, as does the standard, in explaining the <link rel=?> or relation attribute in the <link> tag and how they are used and expanded in HTML5. Many of the link relations are used for specific Web development tasks and operations which have value in new display, especially mobile contexts. The second topic is about Microsoft.
In his book Mark constantly raises the issue of how Microsoft plays within the W3C and HTML5 standards. For example, in this case Mark cites the need to use shivs, hacks and comment conditionals to bring IE browsers up to speed in both HTML4 and HTML5. IE9 will hopefully change this. But “Microsoft shivs” also opens a Pandora’s box that has been “living with IE” for the past 8 years. Microsoft [and possibly Apple and Mozilla if Microsoft gets away with it]may well be content to not support portions of the new full HTML5 standard or use proprietary and hardware dependent extensions and let the Web community do what it has been for the past “n” years where “n” is certainly large – fill in the gaps with shims, hacks and other work arounds.
The <canvas> tag bring 2D bitmap drawing to a browser near you. Now this is 2D drawing not 3D although there are some demos of pseudo 3D drawing techniques using raycasting which are fairly impressive examples of delivering 3D in with a 2D-only [for now] <canvas> feature set. Also Mark does not cover SVG which HTML5 provides for as a vector graphics embedded <object>. Also the HTML5 standard does not provide for mixed bitmap and vector combinations except through CSS3 layering and transparency settings [Photoshop’s layers come to the Web to some delight and chagrin too]. Look to desktop software like Xara Pro Designer or Corel Draw or Adobe Illustrator +Photoshop plus SVG itself to provide this union of bitmap and vector graphics.
Given the richness of the <canvas> API, Keep an Open Eye was surprised that Mark did not provide at least a list of some of the other f<canvas> functions available. However, there is the requisite section on “What about IE?” which describes a workaround in case the IE9 beta goes proprietary on <canvas>. Finally there is a superb example of using <canvas> to create the Halma game which include code for doing HTML5 local storage. It is a simple but engrossing Norse/Anglo Saxon game of checker like moves in which a cluster of nine pieces in the lower left corner must be transferred to the top right in the minimum possible moves. Mark explains the code and provides a link to the game [click on the screenshot below] which the user can then save the page and inspect and change the code as desired:
Mark has only <video> in the chapter heading; but audio is so interwoven with video that he discusses HTML5’s <audio> tag in detail as well. Oh and what a tangled history these tags have in recent months courtesy of the Apple vs Adobe Flash battle. But as Mark deftly points out – that is not the half of it. All the browser vendors appear to have vested interests in various media containers. Think of media containers as pseudo zip files that bring aboard encoded video and audio objects created by different video codecs and audio codecs.
The media containers have a manifest of whats on board so that then your browser can decide if it has the supporting decoder codecs so that the video or audio or both can be played back to you. Now add to this that most media containers support streaming – so in the manifest is an address where to go, get and download the rest of the “show” in sizable chunks that don’t overwhelm the browser and your Web connection. Simple. But the permutations and combinations of competing media containers, audio codecs and video codecs available to the various browser vendors are what makes this pudding “whipped”.
<aside> Adobe and before it Macromedia which Adobe bought in 2006, have a free Flash Player that is just a media container. The Flash container has not just video and audio on board, but also fonts, bitmap images, vector images, CSS stylings, and script storage as well. For the past ten years Flash has not only been the pioneer in packing ever more media including animations on board its media container; but also has delivered by far the most storage efficient and speediest player on the market. So after profiting on this capability for the past ten years with Flash being an integral part of Apple’s Graphics Leadership Mystique, Apple’s CEO Steve Jobs goes and literally pukes all over the Flash Player. Like many people, Keep an Open Eye has a problem with that. But what is even more disappointing is that many of Apple’s difficulties with the Flash Player are self inflicted wounds and deficiencies. Read the sad story here. </aside>
As you might expect a couple of tables drawn from the book are going to be needed to to show the container + codec players and then their support in the tables below. Mark warns us there are tons of video and audio codecs available so the situations could change. To clarify, a profile for a media container+codec combo means various setting that improve quality of the recording at the cost of either slower encoding and/or decoding or larger filesize. First is the table of media containers and some of the codecs they support in the HTML5 spaces:
|Container + Codecs||Attributes and Properties|
|Video MPEG4 + H.264 AVC + AAC||.mp4, .mv4; patent encumbered will charge in 2014; 3 major profiles|
|Video MPEG4 + Theora + Vorbis||.mp4, .mv4; Theora codec has no patents, codec runs on all major OS|
|Video Ogg + Theora codec + Vorbis||.ogv; Open Source and patent royalty free; runs on all OS; one profile|
|Video Webm + VP8 codec + Vorbis||.webm; Open Source and patent royalty free; two profiles|
|Video AVI + VFW + AFM audio||.avi; no compression, Windows primarily, limited codecs; one profile|
|Flash + VP8 video + Vorbis audio||.flv; free player, closed source, runs many codecs on most OS|
Now experts on audio/video scene will argue that this table is a subset of all the possible combinations which is true enough; but as regards HTML5, Mark condenses the list of contenders down to 3 based on their support in popular browsers and devices as follows:
These results leads Mark to the following “knockout punch conclusion”
There is no single combination of of containers and codecs that work in all HTML5 browsers. This is not likely to change in the near future. To make your video watchable across all of these devices and platforms, you’re going to need to encode your video more than once.
After landing this blow, Mark softens it a little by going through creation of Ogg and in 22 pages of detailed screenshots and step by step processes of creating first an Ogg Theora video+ Vorbis audio movie and then a MP4 H.264 video+AAC audio. And suddenly using an Adobe Flash .FLV with its automated movie creation and cross platform support for both containers and all the OS except iDevices [yes, Steve has not dared to ban Flash FLV from MacOS/X yet] is looking mighty attractive. So that is why Flash FLV is added as option line in the Media/Container Codecs table above.
Mark describe the geolocation API with a fair degree of caution – and well he does so. The venerable Wall Street Journal has been doing a series of probing stories on the dwindling level of privacy aviable to Web users. Eevn the journal was astonished by the amount a site could gather from individual just by soliciting the users name. The Geolocation API could further dimisish that privacy an d all in the name of fun and meeting friends and having a good time or finding that “right” gift quickly.
So Mark points out what users should expect from browsers or smartphones/devices that provide geo-services. As the end user you should be in control with the browser/user agent supplying the following controls on geolocation:
1)by being told whenever a website wants to know your location;
2)by being told which website wants to know your location;
3)can get help which explains exactly what is going on;
4)can choose to NOT share your location as easily as deciding to share it;
5)can choose to allow/forbid this website from requesting geolocation info from you in the future;
6)can be assured that this request is non-modal so you can switch to another window to check on whats up and return once you have an answer;
7)this check is unconditional so no website will be able to bypass this geolocation check;
8 )this check is blocking, so there is no chance that the website can determine your location while waiting for the answer.
Now a bit disconcerting is these guarantees are for the Mozilla browser – Mark does not clarify whether the same restrictions apply in all browser.
With this as starting proviso, Mark then describes the power of the geolocation API. There is not a lot seemingly that geolocation gives away. Your latitude, longitude and accuracy. Then depending on the device you are using the geolocation API sends back your altitude, its accuracy, your heading as a direction departing from true north, speed, and timestamp[bad news if the police could intercept and read this].
Once again, Mark has to show how Google Gears can be used to rescue developers with a work around if Microsoft fails to support the W3c Geolocation API in IE9. Is this starting to sound like a broken record? How does Redmond get away with this nonsense?
<rant>This reviewer is dreading this topic because Ian Hickson as WHATWG and HTML5 editor appears to be making a big mistake on the Web SQL Database standard. What should not be, is a mess. Ian should allow the existing Web SQL Database standard which uses SQLite to proceed. Not just because Apple, Google, and Opera have already implemented it. Not just because Mozilla, Microsoft, Adobe, and dozens of major and minor software vendors use SQLite in lots of their software. Rather because SQLite is Open Source and brings a largely declarative and very popular database which tens of millions of developers know to the Web. Then a second standard for Web Database using key value pairs with IndexedDB [or whatever] could progress on a separate track.
The objections that a)SQLite does not have standards documentation [false , see the SQL railroad diagrams and other resources here]; b) SQLite is not an ANSI standard database [who is, given the abuses of ANSI SQL; but SQLite is a true subset of SQL92]; c) transferring data to SQLite will sometimes require an extra data-columns mapping step [and you name one database including the still “evolving” IndexedDB that won’t need to do the same ]; d)SQLite may change versions leaving users with incompatibility problems [also true of SVG, Web Sockets, and any software; but as a HTML5 standard SQLite developers would have every motivation to ensure means for backward compatibility be provided]; and e)SQLite being used by so many software vendors has garnered a solid profile for security, performance, and reliability that other databases will be hard pressed to match in the local client space. In sum, these objections are straw dogs to allow other Web Database proposals to go ahead. So let them, as a separate Web Database track and let developers and the markets choose the best Web database. </rant>
In the book, Mark points out that the data explosion that is occurring in the IT world is also alive and well in the Web world too. Cookies are currently the modus operandi for Web data storage but they have KB size limits and the pesky attribute that they are transmitted back to the server on every page refresh or change. Mark mentions several candidate storage systems including Microsoft’s userData, the AMASS system which became dojox.storage, and the Google Gears which uses SQLite as its database engine. So there are a lot of alternatives for Web storage.
Mark again uses the Halma game example to show the use of HTML5 storage in a real world Offline context – a nifty example. His end of chapter reference list keeps up the high quality, as Mark provides links to HTML5 storage but also to the Web SQL Database controversy.
One of the key advantages of Adobe Flash+Air and Google Gears is that they allow developers to create Web apps that work offline as well as online. For many read-only or read-primarily apps like dashboards, report browsing, book reading, etc – this is a perfectly wonderful capability. Going to lose a connection to the Web ? Not to worry the data, images and Web coding to continue browsing offline is what the Offline API allows the developer to create for the user. The key for making this possible is an offline manifest file describing all the resources needed , where to get them and then, with Web storage where to place them on the local device.
Hence again, this underlines the importance of Web Storage and the Web Database APIs to HTML5. Mark indicates that Microsoft and Opera are remiss on supporting the Offline API; but the new Opera 10.6 browser changes that with increased support that HTML5Test.com measures as 10/14. IE awaits the IE9 beta and to determine what Microsoft will be doing … and then there are a number of workarounds ….
Mark then describes how to make sure Offline works on your server, if its Apache and you have access to it[no other servers discussed]. The three important sections of the Cache Manifest file , Network:, Cache:, Fallback: are explained. And then theOffline proceedings get interesting [i.e. not hard to program; but hard to debug when things go wrong]. The whole problem is with caching the manifest file. Fortunately, Mark provides a work around but again, only for the Apache Server, Mark concludes with an example linked to the Halma Game that users found in the <canvas> section of the book. Again a nifty fit. Even better , Mark provides a good set of links to additional demos and tutorials.
First, lets get the usual concern off the books – yes, IE to date is remiss on HTML5 Forms support – and yes there are variety of work arounds in case IE9 fails to deliver. But surprise! Mozilla Firefox, even with the latest 4.0 beta, scores only 6/38 in the HTML5test.com tests. This is truly strange given that Mozilla has been a charter member of the WHATWG group that split off from W3C and now drives the HTML5 spec. WHATWG’s major first task was working on XForms from the very beginning.
However Mark does not raise that issue but proceeds to describe some of the new features XForms brings to HTML5 Forms:
1)HTML5 XForms are fully backward compatible to HTML4. All the old forms will work;
2)HTML5 forms features neatly degrade and work well in HTML4 form mode ;
3)there are work around s available for browsers currently not supporting HTML5 forms;
4)but no validations or regular expression like checks are provide except for numbers;
5)there are seven new <input> types which ease forms development
What reaklly surprised me was that this chapter produced the most examples using the new iPhone and other smartphone devices. The example are fascinating; but book readers will have to content themselves with this one and only sampling of smartphones/devices. Also I was surprised that Mark did not raise the issue of a laclk of unform browser support for the XForms capabilities.
Microdata is about editional, tags and meta elements. There are three competing technologies :
Microformaters – see microformats.org
RDFa – originally intended for XHTML
Mark takes a tongue in cheek approach to explaining these Microdata offering – and well he might given the contenders.
You have to look at whats missing from two viewpoints. What is missing from the HTML5+upcoming WHATWG Web Application working draft proposal which gets routed to the W3C HTML5 or other standard group [see history above]. And then what is missing from the book.
From the HTML5 standard the big yawning gap is UI multi-touch + gestures. There is a W3C group working on the topic but they are 1-3 years away from a recommended standard. Apple has done their own defacto thing. Adobe , despite Steve Jobs assertions to the contrary, also has multitouch+gesture up and ready in Flash. And then one discovers that everybody in the software GUI business has some ideas and/or software doing multi-touch+gestures. Itis a mixed meal as so does every other browser vendor but they don’t agree on what should be the exact form of the gesture and what function/operation that gesture/multi-touch should trigger. So perhaps in self defense the HTML5 committe has taken a pass so far on multi-touch.
In the book Mark is also silent about both of these topics. I was a bit surprised because lots of discussions with Web developers turn on these two topics. In the Details section of this review, I also have highlighted the sections of the “full” HTML5 that is not covered in the book:
Communications- fast evolving;
Web Sockets – fairly specialized;
Devices – also fast evolving and like multi-touch percolating with possible controversy;
So I am not surprised that Mark did not cover these topics. However, Web Workers which involves threading mechanisms enabled in HTML5, I did think there would be more coverage. But given the constantly changing landscape and the target of a flight from Chicago to San Francisco to get the status and promise of HTML5 across; it appears Mark has focussed and chosen well.
The book’s title begs an answers to some questions –
HTML5: Is it up and running?
Yes, in parts. The best areas to start working in are <canvas>, SVG, offline operation, geolocation, and audio. Surprisingly the new tag elements and forms are being held back by some unnamed browser vendors – check out our status section or take you browser over to HTML5test.com. But realistically, the HTML5 spec itself is about 80-90% done but still missing key elements in Web Database, devices and no real work on multi-touch+gestures. The browser vendors are anywhere from 65 to 75% done. But the problem is the different gaps among the browsers.
HTML5: Is it an adequate replacement for Flash now?
No, and likely will not be until Apple and Microsoft and other browser and iDevice vendors get on side with one version of components to support the <video>. Until they do, developers will have to deliver two versions of their videos to reach all browsers. Also Flash will continue to have a features, search, animation, and SEO advantages over HTML5 which will take W3C and the browser vendors anywhere from 1 to 6 years to close the gap.
HTML5: What are the key missing elements right now?
Given the Apple vs Adobe battle one would think the browser vendors, and particularly Apple, would at least get the <video> implementation going with one uniform video+audio codec offering. Sadly, not so. The fact that standards for multi-touch+gestures is not even close is another big blemish on the Apple idea that you can start using HTML5 right away. Also Keep an Open Eye was very disappointed with missing cross browser support for Web Database and XForms – this is really bad form by many of the standards “players” here.
HTML5:How is Microsoft with IE doing on HTML5?
Users will get to see September 15th [of this year], when IE9 beta is unveiled. So far the version tests have been reasonably promising, especially for HTML graphic features. But don’t take my word. Download the beta, take it over to HTML5test.com and see what Redmond has chosen to deliver with its HTML5 test scores. Ohhh … if you have Windows XP or earlier – you are at out of luck. If you run any other Windows version other than Vista or Windows 7, you are out of luck [ including Windows 2000 and the new Windows Phone 7. It is telling that the Web Development community is gearing up for the worst with lots of shivs and other work arounds.
HTML5:Is there a good book that gets one upto speed in HTML5 quickly?
I am glad you asked. If you are taking a flight from Toronto to Miami or Chicago to Los Angeles and you bring a copy of HTML5: Up and Running along you will a) finish the book and b)get get one of the best intros to HTML5 I have found. Mark combines thoroughness with well chosen snippets of code and full examples. The style is puckish – and it has to be given the nature of establishing Web standards. The references at the end of each chapter are always relevant and fill in the missing blanks on his code and examples.
Mark chose not take on the Communications and Devices sections of the evolving HTML5 – and given their semi-finished state that is understandable. I was surprised that Mark did not mention anything about multi-touch+gestures; but who wants to handle a can of worms. Also if you are looking for how to do HTML5 in Android or iPhone – this is not the place. But if you want to get a solid feel for what is in HTML5 [lots, Ian Hickson and crew have had an enormous task and done fairly well given the players with the exception of Web SQL Database] and what you can get started on this is the book to read.
HTML5: Are there some good references?
I am glad you asked again – see immediately below for a starting list.
Microsoft’s Participation in HTML Standards – blog interview with Phillipe Hegret W3C director
HTML5 Markup – summary of latest HTML5 working draft status
Is this HTML5 – Explanation back at whatwg.org by HTML5 editor what is part of WHATWG and W3C HTML5 standard
HTML5 Official Specification – Editor’s Working draft dated August 24th, 2010
W3C HTML History – HTML major events from 1997 through 2008
Microsoft History of W3C Standards Upstaging – 2003 walk out on Web Services Choreography , form own group with IBM
Microsoft Hiatus on IE development – from release of IE6 in Aug 2001 til launch of IE7 beta and final code from
Flash vs HTML5 – a detailed examination of Flash features versus HTML5
Canvas + SVG Demos
Bomomo – Draw and paint by clicks on canvas with unique paintbrushes
Canvas Cheatsheet – great PDF file cheatsheet for most <canvas> functions
Canvas: BillMalone – detailed example of using canvas to create icons
Canvas: Paint – use paint program to discover how much of <canvas> tag is supported by your browser
Canvas: Diving Into HTML5 – excellent tutorial on <canvas> with Halma game.
Canvas Demos – dozens of examples, games and tutorials for using HTML5 Canvas
Canvas Demos 2 – 48 top notch demos mostly of <canvvas> in action
Canvas: Ben Joffe – again some great examples of what can be done with canvas tag
SVG: Animated Audio – animations added to audio play back
SVG: Charting – World Cup data from 2002 charted
SVG: Images – drag and drop, rotate, plus resize bitmap images
CSS3 Features – backgrounds, rounding, and drop shadows
HTML5Demos – these are primarily not <canvas> demos but other sections of HTML5
HTML5 Doctor – articles about and questions answered about HTML5
HTML5 Tester – tests/validates the full HTML5 spec, like ACID3 test
Quackit HTML5 Tester – edit and tryout HTML5 code in your browser
W3schools HTML5 Tester – edit and tryout HTML5 code in your browser here too
Web Database Debacle – read it and weep as false praise and self-interest prevail