object(WP_Query)#70 (47) { ["query_vars"]=> array(56) { ["tag"]=> string(5) "html5" ["error"]=> string(0) "" ["m"]=> int(0) ["p"]=> int(0) ["post_parent"]=> string(0) "" ["subpost"]=> string(0) "" ["subpost_id"]=> string(0) "" ["attachment"]=> string(0) "" ["attachment_id"]=> int(0) ["name"]=> string(0) "" ["static"]=> string(0) "" ["pagename"]=> string(0) "" ["page_id"]=> int(0) ["second"]=> string(0) "" ["minute"]=> string(0) "" ["hour"]=> string(0) "" ["day"]=> int(0) ["monthnum"]=> int(0) ["year"]=> int(0) ["w"]=> int(0) ["category_name"]=> string(0) "" ["cat"]=> string(0) "" ["tag_id"]=> string(3) "126" ["author_name"]=> string(0) "" ["feed"]=> string(0) "" ["tb"]=> string(0) "" ["paged"]=> int(0) ["comments_popup"]=> string(0) "" ["meta_key"]=> string(0) "" ["meta_value"]=> string(0) "" ["preview"]=> string(0) "" ["s"]=> string(0) "" ["sentence"]=> string(0) "" ["fields"]=> string(0) "" ["menu_order"]=> string(0) "" ["category__in"]=> array(0) { } ["category__not_in"]=> array(0) { } ["category__and"]=> array(0) { } ["post__in"]=> array(0) { } ["post__not_in"]=> array(0) { } ["tag__in"]=> array(0) { } ["tag__not_in"]=> array(0) { } ["tag__and"]=> array(0) { } ["tag_slug__in"]=> array(1) { [0]=> string(5) "html5" } ["tag_slug__and"]=> array(0) { } ["ignore_sticky_posts"]=> bool(false) ["suppress_filters"]=> bool(false) ["cache_results"]=> bool(false) ["update_post_term_cache"]=> bool(true) ["update_post_meta_cache"]=> bool(true) ["post_type"]=> string(0) "" ["posts_per_page"]=> int(15) ["nopaging"]=> bool(false) ["comments_per_page"]=> string(2) "50" ["no_found_rows"]=> bool(false) ["order"]=> string(4) "DESC" } ["tax_query"]=> object(WP_Tax_Query)#206 (2) { ["queries"]=> array(1) { [0]=> array(5) { ["taxonomy"]=> string(8) "post_tag" ["terms"]=> array(1) { [0]=> string(5) "html5" } ["include_children"]=> bool(true) ["field"]=> string(4) "slug" ["operator"]=> string(2) "IN" } } ["relation"]=> string(3) "AND" } ["meta_query"]=> object(WP_Meta_Query)#205 (2) { ["queries"]=> array(0) { } ["relation"]=> NULL } ["post_count"]=> int(15) ["current_post"]=> int(-1) ["in_the_loop"]=> bool(false) ["comment_count"]=> int(0) ["current_comment"]=> int(-1) ["found_posts"]=> string(2) "22" ["max_num_pages"]=> float(2) ["max_num_comment_pages"]=> int(0) ["is_single"]=> bool(false) ["is_preview"]=> bool(false) ["is_page"]=> bool(false) ["is_archive"]=> bool(true) ["is_date"]=> bool(false) ["is_year"]=> bool(false) ["is_month"]=> bool(false) ["is_day"]=> bool(false) ["is_time"]=> bool(false) ["is_author"]=> bool(false) ["is_category"]=> bool(false) ["is_tag"]=> bool(true) ["is_tax"]=> bool(false) ["is_search"]=> bool(false) ["is_feed"]=> bool(false) ["is_comment_feed"]=> bool(false) ["is_trackback"]=> bool(false) ["is_home"]=> bool(false) ["is_404"]=> bool(false) ["is_comments_popup"]=> bool(false) ["is_paged"]=> bool(false) ["is_admin"]=> bool(false) ["is_attachment"]=> bool(false) ["is_singular"]=> bool(false) ["is_robots"]=> bool(false) ["is_posts_page"]=> bool(false) ["is_post_type_archive"]=> bool(false) ["query_vars_hash"]=> string(32) "b127f749731aaa4cc721bc2053386347" ["query_vars_changed"]=> bool(false) ["thumbnails_cached"]=> bool(false) ["query"]=> array(1) { ["tag"]=> string(5) "html5" } ["request"]=> string(342) "SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts INNER JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id) WHERE 1=1 AND ( wp_term_relationships.term_taxonomy_id IN (127) ) AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish') GROUP BY wp_posts.ID ORDER BY wp_posts.post_date DESC LIMIT 0, 15" ["posts"]=> &array(15) { [0]=> object(WP_Post)#261 (25) { ["ID"]=> int(4395) ["post_author"]=> string(1) "2" ["post_date"]=> string(19) "2012-08-10 10:21:14" ["post_date_gmt"]=> string(19) "2012-08-10 00:21:14" ["post_content"]=> string(3047) "

Andrew Fisher gets all touchy feely with the mobile web. See below for full session description and more resources.

Got a taste for it? Be there for the dev track at Web Directions South 2012.

This presentation was recorded at Web Directions Code in Melbourne on May 23 2012.

Session description

As the majority of web users shift to touch devices, the expectation is becoming that everything becomes touchable — including the mobile web. This session will provide a practical and pragmatic view of where touch is at from a web standards perspective and how you can start weaving touch interactions into your mobile web applications.

Resources from this presentation

About Andrew Fisher

Andrew Fisher is deeply passionate about technology and is constantly tinkering with and breaking something — whether it’s a new application for mobile computing, building a robot, deploying a cloud or just playing around with web tech. Sometimes he does some real work too and has been involved in developing digital solutions for businesses since the dawn of the web in Australia and Europe for brands like Nintendo, peoplesound, Sony, Mitsubishi, Sportsgirl and the Melbourne Cup.

Andrew is the CTO for JBA Digital, a data agency in Melbourne Australia, where he focuses on creating meaning out of large, changing data sets for clients. Andrew is also the founder of Rocket Melbourne, a startup technology lab exploring physical computing and the Web of Things.

" ["post_title"]=> string(60) "Getting all touchy feely with the mobile web - Andrew Fisher" ["post_excerpt"]=> string(497) "

Photo of Andrew FisherAs the majority of web users shift to touch devices, the expectation is becoming that everything becomes touchable — including the mobile web. This session will provide a practical and pragmatic view of where touch is at from a web standards perspective and how you can start weaving touch interactions into your mobile web applications.

" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(4) "open" ["ping_status"]=> string(4) "open" ["post_password"]=> string(0) "" ["post_name"]=> string(58) "getting-all-touchy-feely-with-the-mobile-web-andrew-fisher" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2012-08-10 10:21:14" ["post_modified_gmt"]=> string(19) "2012-08-10 00:21:14" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(36) "http://www.webdirections.org/?p=4395" ["menu_order"]=> int(0) ["post_type"]=> string(4) "post" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" ["post_category"]=> string(1) "0" } [1]=> object(WP_Post)#260 (25) { ["ID"]=> int(4376) ["post_author"]=> string(1) "2" ["post_date"]=> string(19) "2012-07-12 16:11:36" ["post_date_gmt"]=> string(19) "2012-07-12 06:11:36" ["post_content"]=> string(2267) "

Rob Hawkes uses HTML5 technologies for game development. See below for full session description and more resources.

Got a taste for it? Be there for the dev track at Web Directions South 2012.

This presentation was recorded at Web Directions Code in Melbourne on May 24 2012.

Session description

With Angry Birds, Cut the Rope and other block­buster games now working in modern web browsers, it’s fair to say native, browser based gaming has arrived for real. But how do they do it? In this session, Mozilla Technical Evangelist Rob Hawkes looks at the features now in your browsers to help develop games (and other interactive web based experiences) including the Canvas and WebGL, HTML5 Audio API, Mouselock and the Joy­stick API.

Resources from this presentation

About Rob Hawkes

Rob thrives on solving problems through code. He has an addiction to visual programming and can’t get enough of HTML5 and JavaScript. He’s the author of Foundation HTML5 Canvas and is a Technical Evangelist at Mozilla. He leads the gaming side of Mozilla’s work within the developer community.

" ["post_title"]=> string(52) "HTML5 technologies and game development - Rob Hawkes" ["post_excerpt"]=> string(596) "

Photo of Rob HawkesWith Angry Birds, Cut the Rope and other block­buster games now working in modern web browsers, it’s fair to say native, browser based gaming has arrived for real. But how do they do it? In this session, Mozilla Technical Evangelist Rob Hawkes looks at the features now in your browsers to help develop games (and other interactive web based experiences) including the Canvas and WebGL, HTML5 Audio API, Mouselock and the Joy­stick API.

" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(4) "open" ["ping_status"]=> string(4) "open" ["post_password"]=> string(0) "" ["post_name"]=> string(39) "html5-technologies-and-game-development" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2012-08-10 10:15:21" ["post_modified_gmt"]=> string(19) "2012-08-10 00:15:21" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(36) "http://www.webdirections.org/?p=4376" ["menu_order"]=> int(0) ["post_type"]=> string(4) "post" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" ["post_category"]=> string(1) "0" } [2]=> object(WP_Post)#259 (25) { ["ID"]=> int(4368) ["post_author"]=> string(1) "2" ["post_date"]=> string(19) "2012-07-09 21:14:40" ["post_date_gmt"]=> string(19) "2012-07-09 11:14:40" ["post_content"]=> string(3573) "

Divya Manian designs in the browser. See below for full session description and more resources.

Got a taste for it? Be there for the dev track at Web Directions South 2012.

This presentation was recorded at Web Directions Code in Melbourne on May 24 2012.

Session description

Each website is a product used daily by people to take actions, not just read the content on it. Your product is amorphous, it takes the shape of whatever container it fills: a mobile browser, a touch enabled desktop browser, or a 30″ iMac that is connected to the Internet via tethering. Photoshop is just one of the means to an end in this new age of utilitarian web sites. The new technologies available in HTML5 already allow you to create prototypes quickly in the browser. Learn how to create a prototype from start to finish using these new technologies while taking advantage of quick prototyping tools.

Resources from this presentation

About Divya Manian

Divya Manian works for the Adobe Web Platform Team in San Francisco. She made the jump from developing device drivers for Motorola phones to designing websites and has not looked back since. She takes her duties as an Open Web vigilante seriously which has resulted in collaborative projects such as HTML5 Readiness and HTML5 Boilerplate.

" ["post_title"]=> string(39) "Designing in the browser - Divya Manian" ["post_excerpt"]=> string(771) "

Photo of Divya ManianEach website is a product used daily by people to take actions, not just read the content on it. Your product is amorphous, it takes the shape of whatever container it fills: a mobile browser, a touch enabled desktop browser, or a 30″ iMac that is connected to the Internet via tethering. Photoshop is just one of the means to an end in this new age of utilitarian web sites. The new technologies available in HTML5 already allow you to create prototypes quickly in the browser. Learn how to create a prototype from start to finish using these new technologies while taking advantage of quick prototyping tools.

" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(4) "open" ["ping_status"]=> string(4) "open" ["post_password"]=> string(0) "" ["post_name"]=> string(37) "designing-in-the-browser-divya-manian" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2012-07-09 21:14:40" ["post_modified_gmt"]=> string(19) "2012-07-09 11:14:40" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(36) "http://www.webdirections.org/?p=4368" ["menu_order"]=> int(0) ["post_type"]=> string(4) "post" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "2" ["filter"]=> string(3) "raw" ["post_category"]=> string(1) "0" } [3]=> object(WP_Post)#258 (25) { ["ID"]=> int(4364) ["post_author"]=> string(1) "2" ["post_date"]=> string(19) "2012-07-09 21:13:00" ["post_date_gmt"]=> string(19) "2012-07-09 11:13:00" ["post_content"]=> string(1634) "

Faruk Ateş on The Web's Third Decade. See below for full session description.

Got a taste for it? Be there for the dev track at Web Directions South 2012.

This presentation was recorded at Web Directions Code in Melbourne on May 23 2012.

Session description

Our medium has entered its third decade of existence, and is ready for some growing up. Our definitions and understand­ing of the web are rapidly getting out of date, as, too, are our practices for building on it. It is time to re-evaluate where things are and, more importantly, where they are going.

About Faruk Ateş

Faruk is a designer, developer and web standards educator with a strong passion for accessible techniques and progressive enhancement. Now busy with a new startup of his own, Faruk previously worked as Lead Designer at Apture, User Interface Engineer at Apple, and before that he built and designed Content Management Systems at a startup in The Netherlands. Whenever time permits him, Faruk works on open source tools like Modernizr and jQuery Runloop, aiming to help people make better websites and applications. He also frequently writes for publications both online and print, and speaks at conferences and events all around the world. He now lives in San Francisco.

" ["post_title"]=> string(36) "The Web's Third Decade - Faruk Ateş" ["post_excerpt"]=> string(457) "

Photo of Faruk AteşOur medium has entered its third decade of existence, and is ready for some growing up. Our definitions and understand­ing of the web are rapidly getting out of date, as, too, are our practices for building on it. It is time to re-evaluate where things are and, more importantly, where they are going.

" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(4) "open" ["ping_status"]=> string(4) "open" ["post_password"]=> string(0) "" ["post_name"]=> string(32) "the-webs-third-decade-faruk-ates" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2012-07-09 21:13:00" ["post_modified_gmt"]=> string(19) "2012-07-09 11:13:00" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(36) "http://www.webdirections.org/?p=4364" ["menu_order"]=> int(0) ["post_type"]=> string(4) "post" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "1" ["filter"]=> string(3) "raw" ["post_category"]=> string(1) "0" } [4]=> object(WP_Post)#257 (25) { ["ID"]=> int(4340) ["post_author"]=> string(1) "2" ["post_date"]=> string(19) "2012-07-04 10:27:54" ["post_date_gmt"]=> string(19) "2012-07-04 00:27:54" ["post_content"]=> string(3040) "

John Allsopp takes HTML5 apps offline. See below for full session description and more resources.

Got a taste for it? Be there for the dev track at Web Directions South 2012.

This presentation was recorded at Web Directions Code in Melbourne on May 24 2012.

Session description

One of the perceived benefits of “native” apps is that they can be installed on a device, then run when the user isn’t connected. But web apps can do this too. In this session, John Allsopp will show you how to use HTML5 features such as appcache and webStor­age to create apps that the user can install, and which will work even when the user is cruising at 30,000 feet with no web connection. These features also have the added bonus of helping to improve the performance of web sites and apps, and even work in all modern browsers and devices, including IE8 up!

Resources from this presentation

About John Allsopp

John Allsopp has spent more than 15 years developing for the web, creating software like the acclaimed CSS editor Style Master, and writing and publishing training for web developers. John frequently speaks at conferences and delivers workshops around the world. He is a co-founder of the Web Directions conferences for web designers and developers, held on several continents. In 1999, John wrote the still highly regarded Dao of Web Design and his Microformats: Empowering Your Markup for Web 2.0 was the first book published on Microformats. He is also the author of Developing with Web Standards. When not bathed in the glow of various computer screens, he’s a volunteer surf lifesaver and lives at the southern edge of Sydney with his wife and young daughters, who are the light of his life.

" ["post_title"]=> string(87) "Getting offline: appcache, localStorage for HTML5 apps that work offline - John Allsopp" ["post_excerpt"]=> string(728) "

Photo of John AllsoppOne of the perceived benefits of “native” apps is that they can be installed on a device, then run when the user isn’t connected. But web apps can do this too. In this session, John Allsopp will show you how to use HTML5 features such as appcache and webStorage to create apps that the user can install, and which will work even when the user is cruising at 30,000 feet with no web connection. These features also have the added bonus of helping to improve the performance of web sites and apps, and even work in all modern browsers and devices, including IE8 up!

" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(4) "open" ["ping_status"]=> string(4) "open" ["post_password"]=> string(0) "" ["post_name"]=> string(83) "getting-offline-appcache-localstorage-for-html5-apps-that-work-offline-john-allsopp" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2012-07-04 11:36:57" ["post_modified_gmt"]=> string(19) "2012-07-04 01:36:57" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(36) "http://www.webdirections.org/?p=4340" ["menu_order"]=> int(0) ["post_type"]=> string(4) "post" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" ["post_category"]=> string(1) "0" } [5]=> object(WP_Post)#256 (25) { ["ID"]=> int(4334) ["post_author"]=> string(1) "2" ["post_date"]=> string(19) "2012-07-04 10:03:31" ["post_date_gmt"]=> string(19) "2012-07-04 00:03:31" ["post_content"]=> string(1621) "

Dave Johnson HTML5, device APIs and PhoneGap. See below for full session description and more resources.

Got a taste for it? Be there for the dev track at Web Directions South 2012.

This presentation was recorded at Web Directions Code in Melbourne on May 24 2012.

Session description

Where once web pages were sand­boxed, with little if any access to the underlying device capabilities, increasingly, this is no longer the case. From the first steps of geolocation, which enables any web site or application to ask the browser for a user’s location, an increasing range of device features are being exposed in the DOM: the file system, camera, gyrosopes, address book, com­passes and more. In this session, Dave Johnson, originator of the phoneGap project delves into HTML5 and related device APIs, enabling us to build richer, more sophisticated applications in the browser.

About Dave Johnson

Dave is a co-founder of Nitobi. He holds a BASc in Electrical Engineering (UBC) and a PhD in Solid State Physics from London’s Imperial College which both have pretty much nothing to do with mobile phones or software development. Dave spends most of his time working on and talking about the PhoneGap project.

" ["post_title"]=> string(46) "HTML5, device APIs and PhoneGap - Dave Johnson" ["post_excerpt"]=> string(754) "

Photo of Dave JohnsonWhere once web pages were sand­boxed, with little if any access to the underlying device capabilities, increasingly, this is no longer the case. From the first steps of geolocation, which enables any web site or application to ask the browser for a user’s location, an increasing range of device features are being exposed in the DOM: the file system, camera, gyrosopes, address book, com­passes and more. In this session, Dave Johnson, originator of the phoneGap project delves into HTML5 and related device APIs, enabling us to build richer, more sophisticated applications in the browser.

" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(4) "open" ["ping_status"]=> string(4) "open" ["post_password"]=> string(0) "" ["post_name"]=> string(43) "html5-device-apis-and-phonegap-dave-johnson" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2012-07-04 10:04:13" ["post_modified_gmt"]=> string(19) "2012-07-04 00:04:13" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(36) "http://www.webdirections.org/?p=4334" ["menu_order"]=> int(0) ["post_type"]=> string(4) "post" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" ["post_category"]=> string(1) "0" } [6]=> object(WP_Post)#255 (25) { ["ID"]=> int(4301) ["post_author"]=> string(1) "2" ["post_date"]=> string(19) "2012-06-29 09:07:26" ["post_date_gmt"]=> string(19) "2012-06-28 23:07:26" ["post_content"]=> string(1941) "

Anson Parker gives us the lowdown on this excellent HTML5 feature. See below for full session description and more resources.

Got a taste for it? Be there for the dev track at Web Directions South 2012.

This presentation was recorded at Web Directions Code in Melbourne on May 23 2012.

Session description

Get the low-down on this excellent HTML5 feature and learn how you can add it to your own web projects (and why you'd want to!). We'll also look at some of the missteps made along the way (like the 2011/12 Twitter web interface).

Resources referred to in this presentation

About Anson Parker

Anson Parker is a web developer based in Melbourne, Australia. His past has included stints at Optus and News Limited in Sydney, as well as a couple of years with a tech startup in San Francisco. Over that time he has moved from design to programming to product development. He is the man behind the domain name search engine Domize and plans on launch­ing an automotive search engine in 2012.

" ["post_title"]=> string(36) "The HTML5 History API - Anson Parker" ["post_excerpt"]=> string(387) "

Photo of Anson ParkerGet the low-down on this excellent HTML5 feature and learn how you can add it to your own web projects (and why you'd want to!). We'll also look at some of the missteps made along the way (like the 2011/12 Twitter web interface).

" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(4) "open" ["ping_status"]=> string(4) "open" ["post_password"]=> string(0) "" ["post_name"]=> string(34) "the-html5-history-api-anson-parker" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2012-06-29 09:07:26" ["post_modified_gmt"]=> string(19) "2012-06-28 23:07:26" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(36) "http://www.webdirections.org/?p=4301" ["menu_order"]=> int(0) ["post_type"]=> string(4) "post" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" ["post_category"]=> string(1) "0" } [7]=> object(WP_Post)#254 (25) { ["ID"]=> int(4282) ["post_author"]=> string(1) "2" ["post_date"]=> string(19) "2012-06-27 07:53:31" ["post_date_gmt"]=> string(19) "2012-06-26 21:53:31" ["post_content"]=> string(2530) "

Tammy Butow has a look at the new HTML5 form features. See below for full session description and more resources.

Got a taste for it? Be there for the dev track at Web Directions South 2012.

This presentation was recorded at Web Directions Code in Melbourne on May 23 2012.

Session description

Let’s have a look at how new features such as autofocus, required fields, native date pickers, place­holder text and popping up tailored keyboards for numbers and email addresses on mobile devices can make life more enjoyable!

Resources referred to in this presentation

About Tammy Butow

Tammy is studying a Master of Computer Science at RMIT and is the co-chair of @GGDMelb. She also spends her time making HTML5 mobile apps, travelling, blogging and filming music videos for chuckingamosh.com.

" ["post_title"]=> string(44) "Fantastic forms for mobile web - Tammy Butow" ["post_excerpt"]=> string(384) "

Photo of Tammy ButowLet’s have a look at how new features such as autofocus, required fields, native date pickers, place­holder text and popping up tailored keyboards for numbers and email addresses on mobile devices can make life more enjoyable!

" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(4) "open" ["ping_status"]=> string(4) "open" ["post_password"]=> string(0) "" ["post_name"]=> string(42) "fantastic-forms-for-mobile-web-tammy-butow" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2012-06-27 07:53:31" ["post_modified_gmt"]=> string(19) "2012-06-26 21:53:31" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(36) "http://www.webdirections.org/?p=4282" ["menu_order"]=> int(0) ["post_type"]=> string(4) "post" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" ["post_category"]=> string(1) "0" } [8]=> object(WP_Post)#253 (25) { ["ID"]=> int(3858) ["post_author"]=> string(1) "7" ["post_date"]=> string(19) "2011-11-06 11:40:56" ["post_date_gmt"]=> string(19) "2011-11-06 01:40:56" ["post_content"]=> string(2243) "

Web Directions South 2011, Sydney, October 14th.

Presentation slides

Session description

If this year is all about the mobile space maturing, then your web skills are where it’s at and a key player is PhoneGap, which supercharges your code and gets you into the app store(s).We look at one small framework’s journey from birth at a 2 day hacking event to become the preeminent method for distributing packaged web apps on mobile devices. We will have a look at the all the goodies that PhoneGap provides, then peek inside and see how it integrates with the web stack. We will explore some of the pain points and work arounds. Then, we take a quick pass through the community and resources available. Finally, we finishing up with a look at where PhoneGap is going and explore the interesting places your web dev skills could take you in the next 12 months.

About Ben Birch

Photo of Ben BirchBen is Senior UI Engineer and Beer Baron at Aconex in Melbourne. About 5 years ago a revelation turned him from back end programming to concentrate full time on client side development. At Aconex he brought the rigours of testing to javascript and css well before it was easy and along the way built a lightweight UI framework. The same framework now drives jQuery Mobile using pure javascript.By day he builds enterprise tablet apps on PhoneGap and by night he contributes to several open source projects and changes nappies. He is slightly over excited by all the awesome technology and rapid pace of change in the web space and it’s open and collaborative buzz.Ben has a wife, two small kids and hangs out at #melbjs and on GitHub.Follow Ben on Twitter: @mobz" ["post_title"]=> string(45) "Ben Birch - HTML5, PhoneGap and What’s Next" ["post_excerpt"]=> string(338) "

Photo of Ben BirchIf this year is all about the mobile space maturing, then your web skills are where it’s at and a key player is PhoneGap, which supercharges your code and gets you into the app store(s).

" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(4) "open" ["ping_status"]=> string(4) "open" ["post_password"]=> string(0) "" ["post_name"]=> string(39) "ben-birch-html5-phonegap-and-whats-next" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2011-11-06 17:14:40" ["post_modified_gmt"]=> string(19) "2011-11-06 07:14:40" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(36) "http://www.webdirections.org/?p=3858" ["menu_order"]=> int(0) ["post_type"]=> string(4) "post" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "1" ["filter"]=> string(3) "raw" ["post_category"]=> string(1) "0" } [9]=> object(WP_Post)#252 (25) { ["ID"]=> int(3797) ["post_author"]=> string(1) "7" ["post_date"]=> string(19) "2011-11-06 08:37:38" ["post_date_gmt"]=> string(19) "2011-11-05 22:37:38" ["post_content"]=> string(2408) "

Web Directions South 2011, Sydney, October 14th.

Presentation slides

Session description

Since the early days of the web, the only reliable way to get movement on your site was through Flash, or more recently, Javascript. But now, with WebKit and Mozilla leading the way, transformations and transitions can be done with pure CSS, even on mobile devices. And for those in need of even more movement, CSS3 provides for keyframe-based animations. In this session, we’ll take a look at all of the possibilities and explore what works and where — from the simplest effects, to creative usability enhancements including the combination of CSS with mobile Javascript frameworks.

About Greg Rewis

Photo of Greg RewisGreg Rewis is the Principal Evangelist for Adobe Systems, focusing on Adobe’s open web products and technologies such as HTML5, CSS3 and Javascript. With over 20 years of computer industry experience, Greg spends in excess of 200 days of the year on the road, talking with customers, giving product demonstrations at seminars, and speaking at industry conferences.Greg has been passionate about the web since putting his first “home page” online in 1994. His career has taken him around the world, from the early days of desktop publishing, to a start-up in Hamburg, Germany, the glory days of the web at Macromedia and finally his current role at Adobe.The original GoLive Cyberstudio Product Manager and former Dreamweaver Technical Product Manager, Greg is the co-author of “Mastering CSS with Dreamweaver CS3″ and “Mastering CSS with Dreamweaver CS4″ published by New Riders, as well as a regular contributor to industry publications.Follow Greg on Twitter: @garazi" ["post_title"]=> string(53) "Greg Rewis - Move it! CSS3 Transitions and Animations" ["post_excerpt"]=> string(386) "

Photo of Greg RewisIn this session, we’ll take a look at all of the possibilities and explore what works and where — from the simplest effects, to creative usability enhancements including the combination of CSS with mobile Javascript frameworks.

" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(4) "open" ["ping_status"]=> string(4) "open" ["post_password"]=> string(0) "" ["post_name"]=> string(50) "greg-rewis-move-it-css3-transitions-and-animations" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2011-11-06 08:47:37" ["post_modified_gmt"]=> string(19) "2011-11-05 22:47:37" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(36) "http://www.webdirections.org/?p=3797" ["menu_order"]=> int(0) ["post_type"]=> string(4) "post" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" ["post_category"]=> string(1) "0" } [10]=> object(WP_Post)#251 (25) { ["ID"]=> int(3768) ["post_author"]=> string(1) "7" ["post_date"]=> string(19) "2011-10-23 10:22:31" ["post_date_gmt"]=> string(19) "2011-10-23 00:22:31" ["post_content"]=> string(2022) "

Web Directions South 2011, Sydney, October 14th.

Presentation slides

External slides.

Session description

Most jaw-dropping apps use multiple HTML5 APIs in creative ways, rather than a single API in isolation. In this session we will explore ways you can implement and combine HTML APIs such as websockets, web workers, local storage, and geolocation to make awesome web apps. Then just for fun we’ll look at how you can dish up something really special by throwing in ingredients like canvas, video and WebGL.

About Damon Oehlman

Photo of Damon OehlmanDamon Oehlman is an experienced web and mobile applications developer. He has worked with small and large companies to develop software solutions for desktop, web and most recently mobile devices. His first technical book, Pro Android Web Apps, was released earlier this year by Apress. Damon currently runs his own software development and consulting firm Sidelab, which specializes in cross-platform mobile solutions. Damon’s aptly titled tech blog Distractable offers a mix of articles, tutorials and other shiny things. He is a proud dad, husband and one day dreams of owning his own underground lair.Follow Damon on Twitter: @damonoehlman" ["post_title"]=> string(30) "Damon Oehlman - HTML5 API Soup" ["post_excerpt"]=> string(347) "

Photo of Damon OehlmanIn this session we will explore ways you can implement and combine HTML APIs such as websockets, web workers, local storage, and geolocation to make awesome web apps.

" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(4) "open" ["ping_status"]=> string(4) "open" ["post_password"]=> string(0) "" ["post_name"]=> string(28) "damon-oehlman-html5-api-soup" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2011-10-28 13:13:28" ["post_modified_gmt"]=> string(19) "2011-10-28 03:13:28" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(36) "http://www.webdirections.org/?p=3768" ["menu_order"]=> int(0) ["post_type"]=> string(4) "post" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" ["post_category"]=> string(1) "0" } [11]=> object(WP_Post)#250 (25) { ["ID"]=> int(3638) ["post_author"]=> string(1) "3" ["post_date"]=> string(19) "2011-09-02 11:11:32" ["post_date_gmt"]=> string(19) "2011-09-02 01:11:32" ["post_content"]=> string(13129) "

In the infancy of JavaScript, there was little if any concept of an HTML document object model (DOM). Even though JavaScript was invented to enable web developers to manipulate parts of a web page, and in the original implementation, in Netscape 2.0, developers could only access the form elements, links, and images in a page. Useful for form validation, and first widely used for image rollover techniques (think :hover, before CSS), but far from the general purpose tool to create modern web applications we now know (and love/hate).

Newer iterations of the DOM provided developers with access to far more than just that original limited range of elements, as well as the ability to insert, modify and delete elements in an HTML document. But, cross-browser implementations very often differed, and full support for the W3C's DOM standards have arguably been treated as far more optional than CSS or HTML support.

One of the many reasons for the success of JavaScript libraries like jQuery and Prototype, on top of their easing the pain of cross-browser development was how they made working with the DOM far less painful than it had previously been, and indeed how it was with the standard DOM. Being able to use arbitrary CSS selector notation to get matching elements from a document made the standard DOM methods seem antiquated, or at the every least, far too much like hard work.

Luckily, the standards and browser developers took notice. The W3C developed the Selectors API, a way of easily accessing elements in the DOM using standard CSS selector concepts, and browser developers have baked these into all modern browsers, way back to IE8.

In this short (by my standards) article, we'll look at the Selectors API, how you use it, browser support, and some little things you might like to keep in mind while using it. Rest assured, it's now widely supported, so in many cases, you can safely use it, potentially with a fallback for older browsers (IE7 and older specifically) via libraries like jQuery (or more lightweight selector engines like Sizzle, which provides this functionality for jQuery, and other libraries).

The Selectors API

The Selectors API, which many would consider to be part of HTML5, is in fact a separate, small specification from the W3C. It provides only two new methods, querySelector, and querySelectorAll, for the Document, Element, and DocumentFragment objects (typically, you'll use these methods on the document or element objects.) But do these methods make life easier for developers?

Before the Selectors API, to access an object in the DOM we could use these methods:

  • getElementById (from DOM Level 2 Core) - available for the document element
  • getElementsByClassName, standardized in HTML5, after long non standard browser support, which is supported on documents and elements
  • getElementsByTagName, from DOM Level 2 Core, available on the document and element objects

And there are some legacy ways of accessing elements on a page, which date from the earliest days of JavaScript:

  • links is a property of the document object which contains all anchor (a) and area elements with an href attribute
  • anchors is a property of the document object which contains all a elements
  • forms is a property of the document object which contains all form elements

We can also "traverse" the DOM, using:

  • childNodes, a property of the document and node objects
  • nextSibling, a property of a node, which contains the element directly following it in the same parent element
  • parentElement, a property of a node, which contains its parent element.

and related DOM traversal properties and methods.

But, what developers really often want to be able to do (as the success of jQuery and other libraries has shown) is simply say "give me all the elements which match this selector", or "give me the first element which matches this selector". And that's precisely what the simple, powerful Selectors API does. It doesn't completely do away with the need for DOM traversal, and legacy methods and properties, but it goes a long, long way.

querySelector

querySelector is a method of the document or any element, which returns the first descendent element which would be selected by its one argument, a CSS selector string. We can use this in place of the document.getElementById('content') like so: document.querySelector('#content') (like me, you'll probably find yourself forgetting to add the # from time to time in querySelector, something which doesn't throw an error, so can be frustrating to track down).

And we can do things like find the first header element in an HTML5 document, with querySelector('header'). So far so good. But where querySelector really shines is we can use any selector (attribute, structural, dynamic, UI, and even selector groups) with it. In most cases, this makes traversing the DOM, and locating a specific element far simpler, and most likely far quicker, as we won't be looping in JavaScript and accessing all kinds of DOM properties, rather, the query is taking place inside the browser's far faster native DOM engine.

querySelectorAll

Often, when working with the DOM, we want to manipulate several elements at once, For example, we might want to unobtrusively attach an event listener to all the links with a given class value. Here, querySelectorAll is your friend. Just like querySelector, it takes a single string as an argument, which is a CSS selector. Instead of returning a single element, it returns a NodeList (a kind of JavaScript array) of matching elements. We can then iterate through this array, and manipulate these objects.

For example, we could use it to replace document.links like so:

document.querySelectorAll('area[href], a[href]')

This finds all area elements with the href attribute set, as well as all a elements with this attribute set as well (notice how we've used a selector group, which is quite acceptable with the Selectors API).

Matching elements are returned in the order they appear in the DOM parse tree.

Document or Element?

I mentioned that both the document, and element objects implement these two methods - what's the difference? Well, as you might have guessed, these methods find elements that are descendants of the object you query on. So, if you use the method on a paragraph element, it will only find the descendant elements of that paragraph which match the selector. Other elements in the document which might match it won't be returned. But, if you use the methods on the document, then any matching element in the document can be found.

Gotchas

If you've really got your hands dirty with the DOM, you'll know that when DOM methods return a NodeList, it is live—that is, the members of the list change, depending on the state of the document.

Let's say we get all the elements with a class of "nav" using document.getElementsByClassName('nav'), and it returns 5 elements, which we keep in a variable.

Now, if we add a new element with class nav, or remove one of the existing elements with a class of nav, the NodeList in our variable will be updated to reflect these changes (that's why it is called a live NodeList).

But querySelector and querySelectorAll are different. While they return a NodeList, it is static. So, if we similarly get all elements with a class of nav using document.querySelectorAll('.nav'), then regardless of what we subsequently do to the DOM, the length and contents of the NodeList won't change. Which means, it's always best to query the DOM just before you need the elements, rather than holding on to elements if your DOM is going to change.

There's also a performance consideration. Tests of various browsers indicate that querySelectorAll is slower than getElementByTagName (though not it would appear in Opera). But, it's also possible that once available, manipulating the static NodeList may be higher performance than manipulating a dynamic NodeList. And this issue will likely only have an impact in extreme cases. I'd certainly not recommend prematurely optimising by using getElementsByTagName, getElementsByClass, getElementById and so on in place of querySelectorAll, but it is worth noting you might be able to squeeze a little more performance out by doing so if you really need to.

And it is worth noting too that querySelector and querySelectorAll don't work with every kind of selector. While pseudo-class selectors (like :visited) work with these methods, pseudo-element selectors, like :first-letter, :first-line, :before and :after although permissible as arguments, will return null in the case of querySelector, and an array of length zero for querySelectorAll.

A little gotcha this aging developer has found I'm so used to getElementById and getElementsByClassName that I find myself forgetting the # or . required in the selector string in querySeletor and querySelectorAll. As I mentioned a moment ago, it can be frustrating, as this won't throw an error, but simply return null or an empty NodeList.

Support

All modern browsers, including IE8 and up support both querySelector and querySelectorAll. It is however worth noting that the results returned are dependent on what selectors the browser supports. IE8 supports CSS2.1 selectors, though not CSS3 selectors. IE9 supports many CSS3 selectors, but not a number of the UI related pseudo-classes, such as :required and :invalid. IE CSS support for versions 5 through 9 is extensively covered here by Microsoft.

So, keep in mind, even where these methods are supported, what they return is only as good as the CSS selector support in that browser.

The Wrap-up

If you're more of a web designer who's always been a little intimidated by the thought of wading through the DOM in search of elements (trust me, even seasoned developers often wince at the thought), then querySelector and querySelectorAll are a boon for you. Or, if you're a developer who finds yourself going straight for jQuery or another library as soon as the DOM is involved, the Selectors API might just save you a few KBs, additional files and fussing around. And, if you're one of those seasoned DOM experts, I'm sure there's plenty of times you'll breathe a sigh of relief that rather than wading through an entire document with childNodes, nextElementSibling and the like, a single call to querySelectorAll will return all the elements you want. I reckon these two are my favourite, and now most used DOM methods, and I'm only surprised they aren't more widely covered, as they really are like a Swiss Army Knife for the DOM. Perhaps we need a "top 2 Selectors API methods" article. Then again...

Reading

Here's a few articles and other resources which delve into the Selectors API.

" ["post_title"]=> string(62) "HTML5 selectors API - It's like a Swiss Army Knife for the DOM" ["post_excerpt"]=> string(0) "" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(4) "open" ["ping_status"]=> string(4) "open" ["post_password"]=> string(0) "" ["post_name"]=> string(59) "html5-selectors-api-its-like-a-swiss-army-knife-for-the-dom" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2011-09-03 09:57:21" ["post_modified_gmt"]=> string(19) "2011-09-02 23:57:21" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(36) "http://www.webdirections.org/?p=3638" ["menu_order"]=> int(0) ["post_type"]=> string(4) "post" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "5" ["filter"]=> string(3) "raw" ["post_category"]=> string(1) "0" } [12]=> object(WP_Post)#249 (25) { ["ID"]=> int(3475) ["post_author"]=> string(1) "3" ["post_date"]=> string(19) "2011-07-11 21:05:05" ["post_date_gmt"]=> string(19) "2011-07-11 11:05:05" ["post_content"]=> string(23748) "

Taking your web sites and apps offline with the HTML5 appcache

There's a general (and understandable) belief by even many developers that web sites and web applications can only be used when the browser has a web connection. Indeed, this is routinely cited as one of the real advantages of "native" apps over web apps. But as unintuitive as it sounds, in almost every modern browser and device (except even for now IE10 developer previews, but here's hoping that changes), that's not the case, provided the developer does a little extra work to make their app or site persist when a browser is offline. (Of course the user must have visited your site while their browser did have a connection)

In this article, I hope to clear this whole areas up once and for all, show you how to do it, and point to some great resources out there for learning more about creating offline versions of your web sites and apps. Perhaps most importantly, introduce a simple new tool I've built to do the heavy lifting for you, ManifestR.

Even if you develop web sites, rather than applications, you can benefit from the techniques outlined here, because caching resources can seriously decrease the load time for your site, particularly on a visitors subsequent site visits.

Making a cache

As I'm sure you know, browsers cache HTML, CSS, JavaScript files, images and other resources of the sites you visit, to speed up the subsequent loading of pages. However, you never know when the browser might discard cached files, and so this is not a reliable way for sites to work offline. But what if we could tell the browser what to cache? Well, with HTML5 application caches (also known as applications caches or "appcaches") we can do just that. Let's look at how.

Making it manifest

The heart of the technique is to create an appcache manifest, a simple text file, which tells the browser what to cache (and also what not to). The resources are then cached in an "application cache", or "appcache", which is distinct from the cache a browser uses for its own purposes. The anatomy of an appcache manifest is straightforward, but there are a few subtleties.

An appcache manifest

  • begins with the string "CACHE MANIFEST" (this is required)
  • has a section, introduced by the string "CACHE:" which specifies the URLs of resources (either absolute, or relative to the location where the manifest file will be located on the server) to be cached.
  • We can also optionally specify which resources should not be cached, in a section of the manifest file introduced by the string "NETWORK:". These resources aren't just not cached, but further, won't be used when the user is offline, even if the browser has cached them in its own caches.
  • We can also optionally specify fallback resources to be used when the user is not connected, in a section of the file called "FALLBACK:"
  • You can add comments to the file with, simply by beginning a line with "#"

It's recommended that the extension for a manifest file is .appcache (previously, .manifest was the recommended extension).

Here is a very straightforward example

CACHE MANIFEST

CACHE:

#images
/images/image1.png
/images/image2.png

#pages
/pages/page1.html
/pages/page2.html

#CSS
/style/style.css

#scripts
/js/script.js

FALLBACK:
/ /offline.html

NETWORK:
signup.html

The CACHE section

In the CACHE section we list the resources we want cached. We can use either a URL relative to the .appcache file, or an absolute URL. We can cache resources both in the same domain as the cache, as well as (in most cases) other domains (we'll cover this in more detail in a moment)

Often, the only section of an appcache manifest is this section, in which case, the CACHE: header may be omitted.

Be careful with what you cache. Once a resource, for example an HTML document is cached, the browser will continue to use this cached version, effectively forever, even if you change the file on the server. To ensure the browser updates the cache, you need to change the .appcache file. This can play havoc while you are developing a site, and we'll cover some techniques for managing this in a moment.

One suggestion is to add a version, and or a date stamp to the manifest as a comment. This way, you can quickly change the date or version number, and then browsers will refresh the appcache. Browsers do this intelligently, checking to see which resources might have changed since they were last cached, and only re-caching those which have.

The Network Section

Probably the most subtle aspect of app caching is the NETWORK section. Because a great many web sites, and particularly applications, have dynamically generated content, pulled in from APIs, CGIs and so on, we may want to ensure certain resources aren't cached, and are always directly loaded when the browser is online.

That's where the NETWORK section of the cache comes in. Here, we list the resources we never want to be cached, which is referred to as an "online whitelist". So, in our example above, we are specifying that the page signup.html (located at the root of our site - remember the entries in our manifest are either absolute or relative URLs) is never cached. When online, any request for this page will always cause the page to be loaded from the server (even if the browser might have previously cached it itself). When the user is offline, any request for this resource resuls in an error (again, even if the browser might have cached the resource in its own caches).

We can also specify a group of resources located within a site in the NETWORK section using a partial URL (technically a "prefix match pattern") (note that we can't use this technique in the CACHE section, where all resources must be explicitly listed to be cached in the appcache, with one exception we'll get to shortly). Any resources which have URLs beginning with this pattern are included in the online whitelist, and never cached. As developers we then need to handle the cases where these resources aren't available because the user is offline.

There's also a special wildcard, *. The asterisk specifies that any resources that aren't explicitly cached in the appcache manifest should not be cached.

Fallbacks

App caching also allow us to specify fallback resources. The form of an entry in the FALLBACK section is two resource identification patterns. The first (in the case above simply "/", which matches any resource in the site), specifies resources to be replaced with a fallback when the user is offline. The second specifies the resource to replace any resources matching the patter. So, in this case, when any resource in the site has not been cached, and the user is offline, the page offline.html will be used instead. We can also specify resources to be replaced more specifically. For example, we could specify an offline image for any images that haven't been loaded like so

/images/ /images/missing.png

Here we're specifying that any resources located in the directory images at the top level of our site that have not been cached, be replaced with the image called missing.png found in that same directory, when we are offline.

Using the appcache manifest

So now we've created our appcache manifest, we need to associate it with our HTML documents. We do this by adding the manifest attribute to the html element of a document, where the value of this attribute is the URL of the appcache file.

The current recommendation is the appcache file have the extension .appcache. So, if our manifest is located at the root of our site, we'd link to it like so

<html manifest='manifest.appcache'>

There are also suggestions that using the HTML5 doctype may be required for some browsers to use app cache, so, make sure you use the doctype

<!DOCTYPE html>

And we're all set. Well, almost. In order for the browser to recognize the appcache file, it needs to be served with the mimetype text/cache-manifest. How you set this up depends on your site's server. At the time of writing, it's likely that this is a step you'll need to take, so if caching isn't working, that's very likely why. One of the most common servers is Apache. There are two ways in which you can set up Apache to serve .appchace files as type text/cache-manifest. At the root directory of your site, add a file with the name .htaccess, with the entry AddType text/cache-manifest .appcache (if there's already a .htaccess file, just add this line to it).

Gotchas

App caching can be very powerful, allowing apps to work while the user is offline, and can increase site performance, but there are some definite gotchas it pays to be aware of. Here's a few well worth knowing about.

Resources in style sheets

You'd be forgiven for thinking that any images in a style sheet that has been cached will be included in the appcache, but that's not so. Images your style sheet refers to must be explicitly referenced in the CACHE section of the manifest as well.

Similarly, style sheets that are imported using @import, and resources included via JavaScript must also be explicitly cached.

To help build an appcache manifest, I've developed manifestR, which we'll look at in detail in a moment. It will generate an appcache manifest for you, which includes all the scripts, style sheets, including those @imported, images, linked pages at the same site, and any images linked to in stylesheets.

There's one exception to the rule that only explicitly listed resources are cached, and it is important to understand. Any HTML document that has a manifest attribute will be cached, even if it is not listed in the manifest. This can cause all kinds of headaches while developing, which we cover shortly.

Caching Cross Domain Resources

While there is some confusion on the issue, you can in general cache content from across different domains in an app cache. In fact, without this ability, the real world value of app caching would be limited, as content distributed via a CDN (content distribution networks like Akamai) could not be cached (even content served from a differently named server within the same domain couldn't be cached). The exception to this is that when content is served over secure http (https), then the specification says all resources must come from the same origin. In an exception to this exception, Chrome in fact does not adhere to this part of the specification, and it has been argued that the single origin policy for https is too restrictive in the real world for app caching to be of genuine value.

Refreshing the cache

In effect, unlike most caching of web resources, appcaches do not expire. So, once the browser has cached a particular resource, it will continue to use that cached version, even if you change the resource on the server (for example by editing the contents of an HTML document). The exception to this is when a manifest file is edited. When the manifest is changed, the browser will recache all the resources listed in the manifest.

Caching can cause real headaches while developing a site or application, so it is recommended that during development, you avoid appcaching. One way of achieving this is to serve .appcache files with the wrong mimetype. This way, you can include the manifest attribute in your HTML elements, and serve the appcache file, just as you wold in production, but not have the effects of appcaching. Moving from development to production is as simple then as associating .appcache files with the right mimetype.

Resource hogging and lazy loading

To improve the performance of a site, you might be tempted to preload the entire site, by adding all the pages, images etc in it to the appcache manifest. And, in certain circumstances this might be desirable. It will however place considerable demands on your server, and use more bandwidth, as the first time a person visits your site, they will download more resources than they otherwise might have. Luckily, appcaches have an additional feature that can help here.

You might recall earlier that even when an HTML document with a link to an appcache manifest isn't included in the manifest file, it will still be cached. The benefit of this is that rather than explicitly listing all the pages at your site in a manifest for them to be cached, each time someone visits a page that links to a manifest, it will then be cached.

If the primary motivation for using an appcache is to ensure your site or more likely app works offline, you'll likely want to explicitly list the pages of the site, so that they'll be available offline even if the user hasn't visited them. If your primary motivation is increased performance, then let pages lazily cache when the user visits them, but cache scripts, CSS, and perhaps commonly used images.

Cache failure

An important, but subtle gotcha with appcaching is that if even one of the resources you include in your cache manifest is not available, then no resources will be cached. So, it is really important to ensure that any resource listed in your appcache manifest is available online. There's a tool we discuss in a moment, the Cache Manifest Validator, to help ensure all those resources are online.

Size limits

While there specification places no limits on the size an appcache can be, different browsers, and different devices have different limits. Grinning Gecko reports that:

  • Safari desktop browser (Mac and Windows) have no limit
  • Mobile Safari has a 10MB limit
  • Chrome has a 5MB limit
  • Android browser has no limit to appcache size
  • Firefox desktop has unlimited appcache size
  • Opera's appcache limit can be managed by the user, but has a default size of 50MB
User Permission

In Firefox, when the user first visits an appcached site, the browser asks the user's permission (as it and other browsers do for location with the geo-location API). However, unlike with geo, other browsers don't ask the user's permission. Just something to be aware of, as there'll be no guarantee with Firefox that appcaching is being used, even when supported.

Flakiness and browser support

It must also be noted that the general consensus is that appcaching is currently far from perfect across all browsers which support it. The specification is still in draft, but it should also be noted that most browsers have supported at least some appcaching for quite some time.

According to an amalgam of When can I use, Dive into HTML5 and other online resources:

  • Safari has supported offline web apps since version 4
  • Chrome has supported the feature since version 5
  • Mobile Safari has supported offline apps since iOS 2.1
  • Firefox has supported it since version 3.5
  • Opera has supported appcache since version 11
  • Internet Explorer as yet does not support offline web apps, including in IE10 developer previews
  • Android has support appcache since version 2.1

Introducing ManifestR

We've already mentioned that a particular challenge in creating an appcache is identifying all the resources you need to add to the manifest. To help you with this, I've developed ManifestR, an online tool to help you create an appcache manifest for any page. I don't recommend you use it without at least a little additional fine tuning, as what it attempts to do is locate any resources referenced from a given page. As discussed above, depending on the purpose of your appcache, this is likely to be overkill.

Drag me to your bookmarks bar.

When you use ManifestR on a page, here's what it looks for

  • images both in the same and other domains referenced in the src attribute of any img element in the page.
  • links to pages in the same domain. This can improve the performance of your site for visitors viewing other pages, and is vital if you want the entire site/app to work offline, but means potentially considerable additional load on your server the first time someone visits the site. Whether you choose to keep this list, or remove some or all of the links is an important decision to make.
  • style sheets, linked, or included via @import statements, located both in your domain, or other domains
  • images linked to in any style sheet, both those in the same domain, or other domains
  • JavaScript files, both those in the same domain, and served from other domains. Here too, you'll need to consider carefully which to include and which you want to add to the online whitelist via the NETWORK section of the manifest.

it then puts them all together in a manifest, ready for you to cut and paste, tweak, save and upload.

I hope you find it useful in building appcache manifests (and make sure you let me know via twitter what you think, and how we can improve it).

More reading

There's quite a bit available online about app caching, though keep in mind the specification, and implementations are still somewhat in a state of flux. Here's some articles and other online resources I have found very helpful -

Overviews and specifications
Tutorials and how-tos
Critiques and gotchas

as we know, all is not yet perfect in the world of the offline web just yet. Here are a couple of critiques of the current, and collections of gotchas discovered by offline pioneers.

Tools

We've already mentioned ManifestR, but you should find the The Cache Manifest Validator another really useful tool. Remember, for appcaching to work, every resource you list in your manifest must be available, or nothing will be cached. The Cache Manifest Validator can make sure all your resources are available.

Compatibility

Probably the best place to keep up to date with the ever changing field of HTML, CSS3 and other new web technology support in all modern browsers is When Can I Use?. You can find a snapshot of current browser support above.

" ["post_title"]=> string(13) "Get off(line)" ["post_excerpt"]=> string(0) "" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(4) "open" ["ping_status"]=> string(4) "open" ["post_password"]=> string(0) "" ["post_name"]=> string(11) "get-offline" ["to_ping"]=> string(0) "" ["pinged"]=> string(146) "http://www.standardista.com/html5/offline-applications-application-cache-manifest-files http://hacks.mozilla.org/2010/01/offline-web-applications/" ["post_modified"]=> string(19) "2011-08-07 14:35:54" ["post_modified_gmt"]=> string(19) "2011-08-07 04:35:54" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(36) "http://www.webdirections.org/?p=3475" ["menu_order"]=> int(0) ["post_type"]=> string(4) "post" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(2) "48" ["filter"]=> string(3) "raw" ["post_category"]=> string(1) "0" } [13]=> object(WP_Post)#248 (25) { ["ID"]=> int(3368) ["post_author"]=> string(1) "7" ["post_date"]=> string(19) "2011-06-04 16:56:02" ["post_date_gmt"]=> string(19) "2011-06-04 06:56:02" ["post_content"]=> string(2252) "

Web Directions @media 2011, London, May 27th 10:45am.

Presentation slides

Presentation slides (external site)

Session description

With HTML5, we can now cache our applications and the data that goes with them. This means our favourite programming platform can now be used to build apps that work offline, survive intermittent downtimes, and gain in performance from cached content. In this session we’ll get hands-​​on with the application cache to make the app run when it’s not online. We’ll check out the techniques for client-​​side persistence: web storage and indexed database. Finally, we’ll look at the latest techniques for file access — reading and writing files on the user’s hard drive from a web app is being defined by web standards and implemented in today’s modern browsers.

About Michael Mahemoff

Photo of Michael MahemoffMichael Mahemoff is a Chrome Developer Advocate for Google, based in London, always looking at ways to make the web a more habitable place for users and developers alike. He’s been programming on the web since the mid ’90s, in a range of public-​​facing and enterprise (Java, what else?) contexts, and is the author of Ajax Design Patterns (O’Reilly, 2006) and a blogger for Ajaxian​.com. Server side, he’s mostly a Ruby, PHP, and NodeJS guy and sushi is his preferred coding fuel. Michael holds a PhD from the University of Melbourne, covering software design patterns for improving user experience.Follow Michael on Twitter: @mahemoff
" ["post_title"]=> string(56) "Michael Mahemoff - HTML5 offline for fun and performance" ["post_excerpt"]=> string(593) "

Photo of Michael MahemoffIn this session we’ll get hands-​​on with the application cache to make the app run when it’s not online. We’ll check out the techniques for client-​​side persistence: web storage and indexed database. Finally, we’ll look at the latest techniques for file access — reading and writing files on the user’s hard drive from a web app is being defined by web standards and implemented in today’s modern browsers.

" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(4) "open" ["ping_status"]=> string(4) "open" ["post_password"]=> string(0) "" ["post_name"]=> string(54) "michael-mahemoff-html5-offline-for-fun-and-performance" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2011-06-26 17:31:36" ["post_modified_gmt"]=> string(19) "2011-06-26 07:31:36" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(36) "http://www.webdirections.org/?p=3368" ["menu_order"]=> int(0) ["post_type"]=> string(4) "post" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" ["post_category"]=> string(1) "0" } [14]=> object(WP_Post)#247 (25) { ["ID"]=> int(3363) ["post_author"]=> string(1) "7" ["post_date"]=> string(19) "2011-06-04 16:16:02" ["post_date_gmt"]=> string(19) "2011-06-04 06:16:02" ["post_content"]=> string(2128) "

Web Directions @media 2011, London, May 26th 1:40pm.

Presentation slides

Session description

A much-​​​​hyped feature of HTML5 is native multimedia. In this session we’ll look at embedding

Presentations about html5

Podcasts, slides, videos and more

Getting all touchy feely with the mobile web — Andrew Fisher

Photo of Andrew FisherAs the majority of web users shift to touch devices, the expectation is becoming that everything becomes touchable — including the mobile web. This session will provide a practical and pragmatic view of where touch is at from a web standards perspective and how you can start weaving touch interactions into your mobile web applications.

See the slides and hear the podcast »

HTML5 technologies and game development — Rob Hawkes

Photo of Rob HawkesWith Angry Birds, Cut the Rope and other block­buster games now working in modern web browsers, it’s fair to say native, browser based gaming has arrived for real. But how do they do it? In this session, Mozilla Technical Evangelist Rob Hawkes looks at the features now in your browsers to help develop games (and other interactive web based experiences) including the Canvas and WebGL, HTML5 Audio API, Mouselock and the Joy­stick API.

See the slides and hear the podcast »

Designing in the browser — Divya Manian

Photo of Divya ManianEach website is a product used daily by people to take actions, not just read the content on it. Your product is amorphous, it takes the shape of whatever container it fills: a mobile browser, a touch enabled desktop browser, or a 30″ iMac that is connected to the Internet via tethering. Photoshop is just one of the means to an end in this new age of utilitarian web sites. The new technologies available in HTML5 already allow you to create prototypes quickly in the browser. Learn how to create a prototype from start to finish using these new technologies while taking advantage of quick prototyping tools.

See the slides and hear the podcast »

The Web’s Third Decade — Faruk Ateş

Photo of Faruk AteşOur medium has entered its third decade of existence, and is ready for some growing up. Our definitions and understand­ing of the web are rapidly getting out of date, as, too, are our practices for building on it. It is time to re-​​evaluate where things are and, more importantly, where they are going.

See the slides and hear the podcast »

Getting offline: appcache, localStorage for HTML5 apps that work offline — John Allsopp

Photo of John AllsoppOne of the perceived benefits of “native” apps is that they can be installed on a device, then run when the user isn’t connected. But web apps can do this too. In this session, John Allsopp will show you how to use HTML5 features such as appcache and webStorage to create apps that the user can install, and which will work even when the user is cruising at 30,000 feet with no web connection. These features also have the added bonus of helping to improve the performance of web sites and apps, and even work in all modern browsers and devices, including IE8 up!

See the slides and hear the podcast »

HTML5, device APIs and PhoneGap — Dave Johnson

Photo of Dave JohnsonWhere once web pages were sand­boxed, with little if any access to the underlying device capabilities, increasingly, this is no longer the case. From the first steps of geolocation, which enables any web site or application to ask the browser for a user’s location, an increasing range of device features are being exposed in the DOM: the file system, camera, gyrosopes, address book, com­passes and more. In this session, Dave Johnson, originator of the phoneGap project delves into HTML5 and related device APIs, enabling us to build richer, more sophisticated applications in the browser.

See the slides and hear the podcast »

The HTML5 History API — Anson Parker

Photo of Anson ParkerGet the low-​​down on this excellent HTML5 feature and learn how you can add it to your own web projects (and why you’d want to!). We’ll also look at some of the missteps made along the way (like the 2011/​12 Twitter web interface).

See the slides and hear the podcast »

Fantastic forms for mobile web — Tammy Butow

Photo of Tammy ButowLet’s have a look at how new features such as autofocus, required fields, native date pickers, place­holder text and popping up tailored keyboards for numbers and email addresses on mobile devices can make life more enjoyable!

See the slides and hear the podcast »

Ben Birch — HTML5, PhoneGap and What’s Next

Photo of Ben BirchIf this year is all about the mobile space maturing, then your web skills are where it’s at and a key player is PhoneGap, which supercharges your code and gets you into the app store(s).

See the slides and hear the podcast »

Greg Rewis — Move it! CSS3 Transitions and Animations

Photo of Greg RewisIn this session, we’ll take a look at all of the possibilities and explore what works and where — from the simplest effects, to creative usability enhancements including the combination of CSS with mobile Javascript frameworks.

See the slides and hear the podcast »

Damon Oehlman — HTML5 API Soup

Photo of Damon OehlmanIn this session we will explore ways you can implement and combine HTML APIs such as websockets, web workers, local storage, and geolocation to make awesome web apps.

See the slides and hear the podcast »

HTML5 selectors API — It’s like a Swiss Army Knife for the DOM

In the infancy of JavaScript, there was little if any concept of an HTML document object model (DOM). Even though JavaScript was invented to enable web developers to manipulate parts of a web page, and in the original implementation, in Netscape 2.0, developers could only access the form elements, links, … Read more »

Get off(line)

Taking your web sites and apps offline with the HTML5 appcache

There’s a general (and understandable) belief by even many developers that web sites and web applications can only be used when the browser has a web connection. Indeed, this is routinely cited as one of the real advantages of “native” … Read more »

Michael Mahemoff — HTML5 offline for fun and performance

Photo of Michael MahemoffIn this session we’ll get hands-​​​​on with the application cache to make the app run when it’s not online. We’ll check out the techniques for client-​​​​side persistence: web storage and indexed database. Finally, we’ll look at the latest techniques for file access — reading and writing files on the user’s hard drive from a web app is being defined by web standards and implemented in today’s modern browsers.

See the slides and hear the podcast »

Bruce Lawson — Native multimedia with HTML5

Photo of Bruce LawsonWe’ll look at the pros and the cons of HTML5 multimedia and see how to write simple controls with JavaScript. Most excitingly, we’ll also look at how HTML5 builds in support for subtitles and captions for multimedia accessibility. And you might pick up a Turkish dancing tip on the way.

See the slides and hear the podcast »