Mobile HTML5

Introduction

We’re going to learn how to develop mobile web applications. Note the word “web.” This book focuses on web application development for mobile devices like Android, iPod, iPhone, BlackBerry, and tablets. This book is not about native application development requiring the iOS or Android SDK. Nothing we will learn is operating system specific.

Mobile web applications are websites or web applications that leverage the markup of desktop web applications with the functionality of touch-enabled devices. Web applications, whether accessed via a phone, tablet, or laptop, are built with HTML, CSS, and JavaScript, optionally with image, video, and audio assets and server-side technologies.

By upgrading to using newer HTML5, CSS3, and JavaScript features, we can create web applications with the look and feel of native applications. Because mobile web apps are web based, they are compatible with desktops, smartphones, tablets, and any other device that has a modern browser. Because our web applications are web based, we can distribute them directly to our users, with no need to be listed in the Apple App Store or Google Play, with their sometimes complex, expensive, and lengthy approval processes.

This book will teach you what you need to know to create applications that work in a browser using CSS3, HTML5,^[1] and JavaScript. This is about technologies you already know: technologies that are portable to most devices. Everything discussed is operating system agnostic.

In other words, what we learn will not only work on the iPhone, the iPad, and Android devices, but also on other mobile platforms, including Firefox OS and Windows Phone, and on modern desktop browsers and other devices that have a modern browser (such as gaming consoles like the Wii). Yes, this book is focusing on developing for mobile, but what you learn here is usable on a plethora of devices, big and small, as long as that device has a browser that adheres to modern web standards.

The abilities of applications on native platforms stayed rather consistent for over 10 years, but the past several years have seen the web platform increase its ability to handle web applications, with almost the same fidelity as native applications.

The iPhone added canvas, application cache, database, and SVG. Safari 4.0 included those features, adding video, audio, and web workers. Later in 2009, we saw the addition of geolocation and canvas—not just to the iPhone, but to Chrome, Opera, Firefox, Internet Explorer, and Android.

With web browsers, we’ve been able to take advantage of HTML, CSS, the DOM, SVG, and XHR for years. In this book, we expand our horizons to include HTML5 and CSS3: the skills needed to make web applications that are comparable to native applications, features that are already supported in modern mobile and desktop browsers.

Native Applications Versus Web Applications

Yes, you can sell native iPhone applications in the App Store, which sounds cool. You can sell native Android applications via Google Play, Amazon, or a plethora of other online venues. But with web-based applications, you can bypass the app stores with their approval^[2] processes,^[3] annual fees, and sales fees, and market directly to your consumer base via your website and through other marketing channels. Yes, you miss the very slim opportunity of having your application noticed among the hundreds of thousands of applications available through the app store, but the benefits of web application versus native application development greatly outweigh the costs.

With web applications, it is easier to build and iterate. You can make changes to your live web application whenever you want—multiple times a day if need be.

With a native iPhone app for example, you have the 3-week+ approval process. Once your application is approved and pushed to production, you have to wait for users to sync and update their application. With web applications built using CSS3 and HTML5, your changes are live basically immediately, but can also be accessible when the user is offline—just like native applications.

If you accidentally forget to include your boss or misspell your mother’s name in the credits of your native application, those oopsies are going to haunt you not only until you are able to push the correction through the app store, but they’ll stick around until the user syncs your app with an updated iTunes download. That could be a long time.

Note

I am skilled at becoming “obsolete.” I never updated from the original versions of Bump, Twitterific, and Gowalla on my original iPhone. I assume I am not the only one who has “antique” iPhone applications. Don’t assume that your native application users update their applications.

By using HTML5 to develop your web applications, your application can be available offline, just like a native application. Although the native application can take weeks to update, the web application can be forced to update itself the next time your application is used when connected to the Internet. We’ll cover this when we discuss offline applications in Chapter 6.

HTML5 web application development takes advantage of the HTML and CSS skills you already know. We’re building upon your existing skills rather than asking you to learn completely new ones. Not a different technology, not a different platform. Not a new language that only works on one platform!

Using browser markup of HTML5 and CSS3 gives you the potential to be cross-platform over time. Native iPhone applications work on the iPod touch and on ithe Phone, and most likely on the iPad, but not on Windows, BlackBerry, or Android (and they never will). Native Android applications work only on Android devices, not on iOS-based products. Native GoogleTV applications will never work on iOS either. Et cetera. Unlike native applications, your HTML5/CSS3 web applications can be made to work on all WebKit, IE10, Blink, Opera Mobile (not mini), and Firefox mobile browsers. And your web applications will work on other devices that have modern browsers that by default support features of HTML5 and CSS3.

Web applications built with HTML5 and CSS3, for the most part, already work in modern browsers. While not supported in Internet Explorer 8 or earlier versions, Internet Explorer 9 has support for some, but not all, of HTML5 and CSS3. Internet Explorer 10 has come a long, long way in supporting many features in the ever-evolving specifications.

Since the release of the iPhone SDK in 2008, most of the applications for the iPhone have been created as native apps. Before the release of the SDK, we only had web applications. People moved from web applications to native applications because HTML5 just wasn’t ready. Now that mobile browsers support many HTML5 APIs, we are able to create fast, responsive, and visually appealing web applications.

One last reason: video! The iPhone, iPod, and iPad do not support Flash, and they never will. However, all iOS devices have the Safari WebKit browser that supports the HTML5 <video> element, which we’ll discuss in Chapter 5.

Pep Talk (or Leaving Old Internet Explorer Behind)

With the proliferation of standards-compliant and forward-thinking browsers, which handheld devices have helped disseminate, we now have the opportunity to move the discipline of web development forward into the twenty-first century.

While learning the lessons of this book, I want you to forget about old versions of Internet Explorer. The Web is moving forward, and it’s moving forward fast. Have you been holding back from learning and using CSS3 and HTML5 because of IE6, IE7, or even IE8? These old browsers are not found on mobile devices, and their popularity on desktop computers is dwindling. Stop holding yourself back.

Because of the continued omnipresence of legacy, non-standards-compliant browsers—most notably, Internet Explorer 6 through 8—web developers have been held back from developing kickass websites. Catering to the whims and quirks of IE6 and IE7 forced us to use archaic code; it prevented us from implementing, without some trepidation, advanced older standards as well as not-so-new proposed standards. In this book, we’ll learn all about technologies that we can use because we don’t have to cater to behind-the-times browsers.

As you work through this book, take HTML5 and CSS3 as far as you can. Don’t think: “Oh, this may not work in browser X.” Instead think: “This is awesome!” Learn the skills. Learn the syntax. You’ll be ahead of the game when all browsers eventually support these newer features. And, in the meantime, you’ll have learned some major skills and possibly created a kickass web application.

The Browser Landscape

Safari, Chrome, Firefox, Opera, and IE10 (in both their desktop and mobile versions) all support modern web standards, including HTML 4.01, XHTML, and parts of HTML5; almost all of CSS 2.1 and most of CSS3; JavaScript, including AJAX technologies; and DOM Level 2. Windows was a bit late to the game, but newer phones are supporting HTML5. Did you even know anyone with a Windows mobile phone in 2010? Not until February 2012 when I asked “Who here has a Windows phone?” in a conference hall did someone answer “me.” Now Windows phones are becoming a little more popular. We’re not catering to the old “Windows Mobile,” but this book does cater to those buying the new Windows phone.

This book focuses on designing and developing websites for mobile browsers, providing us the opportunity to use the most cutting-edge web technologies. We’ve decided that we don’t need to think about archaic browsers (you’re with me on that one, right?). However, I like my websites and web applications to render correctly (though not necessarily identically) on all browsers. I assume you do, too. When relevant, we’ll briefly discuss quirks, tips, and tricks to handle the feature at hand in other common, nonmobile browsers.

Web Applications Versus Native Applications: A Brief History

Within a week of the original iPhone launch in June 2007, the first iPhoneDevCamp was held in San Francisco, CA. When the iPhone was originally released, there was no SDK available. Therefore, all the original iPhone applications were web based.

When the iPhone first launched, the iPhone’s OS was less powerful than the newer phones on the market today, and being on the EDGE network, downloads were painfully slow. With these limitations, a main focus in developing applications was ensuring less than 10 KB downloads, less than 10 KB of images, and less than 10 KB of JavaScript.

At the first iPhoneDevCamp, participants developed their own documentation, helping each other gain the skills to develop fun (all web-based) iPhone applications. Originally, there was no default onOrientationChange event. Instead, we added a timer to regularly check the phone’s orientation, and switched CSS classes with JavaScript based on the returned value.

During that first weekend after the iPhone’s launch, Joe Hewitt wrote iUI, the first JavaScript and CSS library for the iPhone and shared it with the developers present. He, Nicole Lazarro, and three others created Tilt, the first iPhone game that used iPhone’s motion-sensing capacity. Dori Smith created iPhone Bingo, a purely JavaScript iPhone game. Richard Herrera, Ryan Christianson, Wai Seto, and I created Pickleview, a Twitter/Major League Baseball AJAX mash-up that allows users to virtually watch any baseball game and tweet about it. It was liberating: for the first time, I was using multiple background images, border images, CSS3 selectors, and opacity without having to worry about supporting a multitude of browsers, browser versions, and operating systems.

For the first nine months of the iPhone’s life, there were only web applications and Apple-controlled native applications: there was no native iPhone app development in the wild. Because of bandwidth limitations and a dearth of Apple developer documentation, iPhone web applications didn’t skyrocket. Because of the inability of the iPhone WebKit Safari browser to access native iPhone OS features, web application development for the iPhone did not take off. Application development for the iPhone finally skyrocketed with the release of the SDK.

Release of the SDK: Beginning of Third-Party Applications

The iPhone SDK was first released on March 6, 2008. The iPhone SDK allowed third-party (i.e., non-Apple) developers to make applications for the iPhone (and later the iPod touch and iPad), with availability in the App Store following in July of 2008. With the release of the SDK, and the opening of the App Store, not to mention the ability for developers to make money from selling their Apps in the App Store, the focus of iPhone development quickly and wholeheartedly switched to building native iPhone applications.

The fact that the focus of iPhone application development has been mostly on the development of native iPhone applications since the release of the SDK makes sense to a great extent—but we’re going to change that! In 2008, the limitations of web-application over native-application development discouraged focusing on web apps, as the following lists show:

Cons for web apps in 2008

• 10 MB file-size limit in iPhone Safari

• Lack of storage for data via web apps, and very limited cache

• Lack of support for most CSS3 and HTML5 features in not only Safari for the iPhone, but all browsers

Pros for native apps in 2008

• Ease of development using XCode

• Ability to sell applications in the App Store

In 2013, however, the tables have turned. The arguments for developing web apps versus native apps has caught up, if not surpassed, the arguments against, as the following lists show:

Pros for web apps in 2013

• Easier to build and iterate (developers can push multiple times a day, providing for quick iteration)

• Uses existing skills in HTML and CSS (building upon skills rather than requiring developers to master completely different ones)

• Same technology, same platform

• Potential to be cross-platform

Cons for native iPhone apps in 2013

• 3-week+ approval process for distributing in the App Store

• Risk of censorship of content and noninclusion by application stores

• $99+ annual Apple Developer membership fee, plus 30% sales fee

• Long waits to push code changes to production, as well as for users to sync and update their application (with HTML5, your changes are live immediately)

What’s New(t)? New Elements and APIs

HTML5^[4] has been in the works for many years, since efforts began in 2004 on what was originally called Web Applications 1.0. While not finalized, some parts are fairly complete and already supported—oftentimes fully supported—by modern browsers. Modern, or A-grade, browsers include Safari, Chrome, Internet Explorer 10+, Firefox, and Opera. IE8 and older is not in this list. IE9 has some HTML5 support, but is a browser that is holding back the Web. So, while not all browsers provide support for HTML5, it is supported by all WebKit/Blink browsers, Opera Mobile,^[5] Firefox OS, and the new Windows phones. It is finally time to start playing with HTML5.

HTML5 is an umbrella term describing the new web API standards, some of which are in the HTML5 specification (e.g., drag-and-drop), and some that aren’t (e.g., geolocation).

With HTML5 and the associated APIs, we are no longer limited to native applications. Between the specification for HTML5 and those of the associated APIs, we could kill a tree if we wanted to print it all. I won’t describe all of the features in this book, but I will cover some of the more useful ones you can implement today, such as the subjects covered in the following sections.

Semantic Grouping Tags

HTML5 provides new tags used for defining logical groups of tags or sections in your markup. Grouping semantically, instead of using the nonsemantic <div> and <span> elements to define headers, footers, navigation, etc., assists search engines in defining your site structure. We’ll cover the new grouping elements in Chapter 3.

Web Forms

There are millions of forms on the Web, and millions of scripts for each of those forms to validate emails, create pop-up calendars, ensure required elements are filled in before submission, and clear out the placeholder text when a form element receives focus. With HTML5, you may no longer need to validate forms with JavaScript! Form elements have been updated in HTML5 with new features and methods for defining data types.

In Chapter 4, we’ll look at some of these revamped form elements, learning how to create native sliders, placeholder text, and calendar date pickers, plus validating email addresses, ensuring all required fields are entered, and displaying custom keyboards based on input type—all without JavaScript!

SVG and Canvas

With HTML5, images no longer have to be embedded objects. HTML5 adds both <svg> and <canvas> as native HTML elements, which are enhanced with CSS and accessible via the DOM. By adding either element, the browser provides a blank canvas in which you can “draw” programmatically. We will cover <svg> and <canvas> in Chapter 5.

Video and Audio

To date, all browser video and audio have required plug-ins. With HTML5, we now have native browser support for video and audio. And they’re scriptable! HTML5 browsers natively support webM and mp4 formats. With the DOM, you can control video and audio, including muting, forwarding, and stopping. With CSS, you can style the players. While iOS devices may never support Flash or Silverlight, all mobile browsers support HTML5 video and audio. We will learn about <video> and <audio> in Chapter 5.

Geolocation API

Geolocation is not part of the HTML5 specifications, but rather an associated API, and a very useful module at that. Geolocation is the identification of the geographic location of mobile and desktop devices. The geolocation API is covered in Chapter 6.

Offline Content and Storage

Stating the obvious: phones are mobile devices. Internet service goes in and out (especially for those of us bound to use AT&T). The HTML5 application cache, local storage, and database APIs enable the use and enjoyment of web applications even when AT&T drops you. The APIs that enable your applications to work offline are discussed in Chapter 6.

Other APIs

In Chapter 6, we will also briefly cover microdata, ARIA, and web workers. Though it has no visual or functional effect on your web pages or web application, microdata is a method by which you can add machine-readable semantics to your content to feed the search engine spiders. ARIA, or Accessible Rich Internet Applications, has no visual impact on your content either, but enables better accessibility by providing attributes that explain the role and function of hijacked elements (elements that are used to convey information that is not the default usage of the element). We also briefly cover web workers, which enable you to use additional JavaScript threads to run intensive JavaScript without impeding the UI thread. Chapter 6 is indeed an exciting chapter!

What’s New in CSS?

CSS3 provides us with some new great features. CSS3 selectors, described in Chapter 7, provide us with a method of targeting just about every element on the page without adding a single class, including media queries to enable responsive web development. RGBA and HSLA are new alpha-transparent color values, which are discussed in Chapter 8, along with other value types. For designers and prototypers, Chapters 9 and 10 will likely be the most exciting chapters of the book, covering new and not-so-new CSS3 features, including:

• Multiple backgrounds

• Transitions

• Transforms

• 3D transforms

• Gradients

• background-size

• border-image

• border-radius

• box-shadow

• text-shadow

• opacity

• animation

• columns

• text-overflow

Web Fonts

Web fonts allow you to use font faces other than the traditional half dozen web-safe fonts. Different browsers have different implementations, including different support for iPhone versus desktop. While all smartphone browsers support @font-face, it is a sans-serif font—Helvetica, Roboto, or whatever the default operating system font is—that should be the font of choice when developing for mobile. I can’t encourage requiring mobile users to download huge font files. I do encourage using smaller icon fonts in Chapter 11, but web fonts are not largely covered in this book. If you are interested in learning more about web fonts for desktop, there is a link in the online chapter resources to a tutorial I wrote. These resources are available at http://www.standardista.com/mobile, and contain links to external resources, code examples, and all the links referenced in this book.

Mobile-Specific Considerations

With desktop browsers, most people navigate a stationary Web with a mouse and a keyboard. On phones and tablets, we often navigate the Web with our fingers, rotating, shaking, touching, and tapping the device, but we don’t—and can’t—click anything. Even the skinniest, scrawniest of users still has “fat fingers” compared to the precision possible with a mouse. And, with relatively small screens and often with smaller user attention spans, there are different considerations when it comes to the user interface and the limited space for including content.

Mobile tablets are often used at home on WiFi, or other wireless access points. Mobile phones can use these same access points, but generally access the Web via inconsistent and limited shared services. They also have smaller screens, so not much room for developer toolbars, or bandwidth for ginormous JavaScript libraries and images.

Chapter 11 covers responsive web development features. Chapter 12 covers design considerations. We cover mobile and touch screen unique-event handlers in Chapter 13. Mobile performance, debugging, and device limitations are covered in Chapter 14.

Why This Book?

As web developers, we’ve been stuck in the past. We’ve been catering to a browser that is over 12 years old. When you don’t have to worry about cross-browser compatibility, and you don’t have to live within the constraints of CSS2, development gets exciting. Mobile devices ship with advanced browsers that implement cutting-edge technology. Use that technology!

Mobile has opened up this exciting new world. WebKit with HTML5 support is on Android tablets, iPhones, OpenMoko, BlackBerry phones, and more. In addition to BlackBerry, Android, and iOS devices, WebKit is the engine for the Bolt, Dolphin, Ozone, and Skyfire browsers. Firefox, Opera, and IE are also found on cell phones, and the advanced Presto-based Opera browser is still found on a multitude of non-“computer” devices. Opera and Chrome are porting to Blink. Soon, everyone will have a fully fledged web browser on their phone, on their TV, in their car, and even in their refrigerators.

Screen Size

Right now, on the desktop, we may feel held back by Internet Explorer’s lack of support for new and upcoming standards. With the proliferation of standards-compliant browsers and the dwindling use of older versions of Internet Explorer, we’ll soon be able to rely on CSS3 everywhere. Moving to mobile, we can think past CSS2 constraints. However, we have new issues to deal with: real estate constraints! One size does not fit all. The mobile browser is, obviously, smaller than the desktop browser.

For some sites, you can have a one-size-fits-all approach, but most HTML files and CSS documents do not fit all browser sizes.

Depending on the complexity of the content and design, you may want to serve up different HTML and different CSS depending on the medium.

Sometimes you may just be able to temporarily hide certain content. At other times, you’ll want to serve a smaller header and smaller images. You may also want to have a multicolumn layout on a wide screen, and a single column layout on the phone. You will want to alter appearances based on device size: for example, a three-column layout is easiest to read on the desktop. Placing those columns vertically on top of the other makes more sense in the mobile arena.

Mobile web design is all about keeping it simple. You can only fit so much in the small area that the phone provides. Scrolling is only for longer articles, not for home or navigational pages.

You may want to provide separate markup for the mobile version of your website. But you don’t have to. And unless you’re creating a real web application rather than a simple website, you really shouldn’t.

User Goals

Internet access on mobile devices used to be thought of as something only for people on the go. Yes, some mobile browser users are simply quickly looking for access to specific information. They may be checking their online grocery list, looking up the ingredients for a casserole, or trying to find the best Italian restaurant within a five-minute walk.

While perhaps that user is not currently interested in the corporate structure of the food supplier, it doesn’t mean that when they are interested in locating that information that they won’t try to do so from the same mobile device. While we may perform such in-depth research on a desktop computer, more and more users are only accessing the Internet with their mobile devices.

Perhaps your average mobile user will just want to get an address, a phone number, or a status update on the go, and will not want to delete, reorganize, edit, or research stuff on her iPhone. But she might. The mobile device may be her only computer. So while you should make sure the most necessary information is easily accessible, you do want to ensure your users can perform all tasks that can be done on a widescreen monitor in the mobile space if needed.

You also have to think about usability. Touch screen devices use fingers instead of mice as input devices. Fingers are fatter than cursors. For touch screen devices, action targets need to be large and have padding. We discuss suggested user interface changes for touch devices in Chapter 13.

Nonpresentational images should be removed from mobile device markup: images are generally optimized for the desktop not the mobile device; they take up space that should be reserved for content when real estate is scarce, and bandwidth can be very slow and very expensive. Yes, include content images if the images are contextual, but use (or omit) background images for images that are decorative in nature.

What’s in This Book

In Chapter 1, we’ll get our development environments set up and discuss the examples used throughout this book.

Chapters Chapter 2–6 discuss what is new in HTML5. We discuss best practices in coding semantic markup that is compatible with all modern browsers, both in the desktop and mobile spaces. We cover the new HTML5 semantic elements, Web Forms 2.0, and several of the HTML5 APIs and related APIs, like geolocation. We’ll touch on SVG, canvas, web forms, video, audio, AppCache and database, and web workers.

Chapters 7–11 introduce everything that is up and coming in CSS3, from new color types, to shadows, to border images, to rounded corners, to animation—you will have all the tools you need to create beautiful web applications for both mobile and modern desktop browsers, with responsive web design features highlighted in Chapter 11.

In Chapters 12–14, we focus on the mobile platform, including touch events, user experience design, and mobile performance considerations. Lessons covered will ensure site performance, user experience, and reliability of web pages on all platforms.

Yes, our goal is to develop kickass websites for mobile. The first step to creating a great website for a mobile device is to create a great website! While you should be developing your website in the desktop browser for ease of development, you should design and develop with mobile always in mind. Then, with minimal modifications, your site will look great and perform well on most, if not all, platforms. Our goal is to develop web applications that work on the phone, by creating web applications that work on all modern browsers.

Conventions Used in This Book

The following typographical conventions are used in this book:

Italic

Indicates new terms, URLs, email addresses, filenames, and file extensions.

Constant width

Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.

Constant width bold

Shows commands or other text that should be typed literally by the user.

Constant width italic

Shows text that should be replaced with user-supplied values or by values determined by context.

Tip

This icon signifies a tip, suggestion, or general note.

Caution

This icon indicates a warning or caution.

Using Code Examples

The chapter resources are available at http://www.standardista.com/mobile. There you can find links to external resources, code examples, and all the links referenced in this book.

This book is here to help you get your job done. In general, when example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.

We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Mobile HTML5 by Estelle Weyl (O’Reilly). Copyright 2014 Estelle Weyl, 978-1-449-31141-4.”

If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at [e-mail].

Safari® Books Online

Note

Safari Books Online (www.safaribooksonline.com) is an on-demand digital library that delivers expert content in both book and video form from the world’s leading authors in technology and business.

Technology professionals, software developers, web designers, and business and creative professionals use Safari Books Online as their primary resource for research, problem solving, learning, and certification training.

Safari Books Online offers a range of product mixes and pricing programs for organizations, government agencies, and individuals. Subscribers have access to thousands of books, training videos, and prepublication manuscripts in one fully searchable database from publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technology, and dozens more. For more information about Safari Books Online, please visit us online.

How to Contact Us

Please address comments and questions concerning this book to the publisher:

O’Reilly Media, Inc.

1005 Gravenstein Highway North

Sebastopol, CA 95472

800-998-9938 (in the United States or Canada)

707-829-0515 (international or local)

707-829-0104 (fax)

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://oreil.ly/mobilehtml5_1e.

To comment or ask technical questions about this book, send email to [e-mail].

For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com.

Find us on Facebook: http://facebook.com/oreilly

Follow us on Twitter: http://twitter.com/oreillymedia

Watch us on YouTube: http://www.youtube.com/oreillymedia

Acknowledgments

Thank you to Bruce Lawson, Adam Lichtenstein, Jennifer Hanen, Tim Kadlec, Jeff Burtoft, Tomomi Imura, and Justin Lowery.

Bruce Lawson coauthored the first book on HTML5, Introducing HTML5 (New Riders). He’s one of the founders of HTML5Doctor.com, and was a member of W3C’s Mobile Web Best Practices Working Group. He evangelizes open web standards for Opera, the oldest browser manufacturer, whose mobile, desktop, TV, and embedded browsers are used by 300 million people across the world (see www.opera.com). Follow Bruce on Twitter at @brucel, or www.brucelawson.co.uk.

Justin Lowery created the look for CubeeDoo. He is a UX architect at his company, Cerebral Interactive, which specializes in the design and development of web and mobile applications. He’s been a graphic/print designer since 2001 and a web developer since 2006. He’s also an informatics nurse (RN), which lends well to his current focus on revolutionizing information technology for health care education. Follow Justin at @cerebralideas, or www.cix.io.

Adam Lichtenstein is a frontend developer and a OOCSS/Sass junkie. He is the creator of FormFace, which focuses on semantic building and styling of HTML5 forms. He is currently the frontend developer and designer at Wufoo and authoring his first book on frontend development. When not coding or writing about coding, his main hobby is thinking about coding. Follow him at @seethroughtrees, or http://seethroughtrees.github.io.

Jenifer Hanen is a mobile designer, developer, and photographer with a passion to make everyone fall as deeply in love with mobile as she is. Ms. Hanen developed her first public website for a friend’s band in 1996 and has had a mobile and web consultancy since 2000, as well as stints as an adjunct web design and art history professor. Follow her at @msjen, or http://blackphoebe.com/msjen.

Tomomi Imura is an open web advocate and frontend engineer with mobile focus who has been active in the mobile space since before it was cool. She has been developing mobile web, platform UI/UX, and frameworks at Yahoo! Mobile and webOS at Palm before joining Nokia, to work with the W3C and evangelize HTML5. Follow her at @girlie_mac, or http://girliemac.com.

Jeff Burtoft is an HTML5 Evangelist for Microsoft and an avid supporter of the JavaScript/HTML5 community. Mr. Burtoft is a huge proponent of web standards, and loves all programming languages, as long as they are JavaScript. Additionally, he is coauthor of HTML5 Hacks (O’Reilly Media) and a founding blogger of html5hacks.com. He lives in South Texas with his wife and three kids. Follow him on Twitter at @boyofgreen.

---

^[1] We will be using the term “HTML5” to mean what is also called “HTML: The Living Standard.”

^[2] Apple actually censors applications. No risqué pictures. No adult violence. It appears that cute violence can get approval, so if you want to include violence, target children?

^[3] You have to pay Apple an annual “developer fee” to submit your native iPhone applications to the App Store, whether or not your application is successful or even approved.

^[4] HTML5 has become an umbrella term. HTML5 is just a component of the HTML5 “umbrella.” Bruce Lawson has suggested the term NEWT for this large umbrella, for “New Exciting Web Technologies.” I would have thought that term silly, but I loved the newt mascot.

^[5] Opera Mini does not have good HTML5 support, and never will. It is a different type of browser—a proxy browser—intentionally having limited features in favor of lower bandwidth usage. Opera Mini requests web pages through Opera’s servers, which process and compress them before sending them to the mobile phone, dramatically reducing the amount of data transferred. The preprocessing increases compatibility with web pages not designed for mobile phones, but limits the interactivity and features of the site.