C H A P T E R  8

The Road Ahead

There are many fringes to HTML5, areas that are still being molded and sculpted toward a standard perfection, but to a large degree the road ahead has less to do with HTML5 and more to do with where HTML5 will be used. It is a connected world, and more people are connected via cellular phones than desktop computers. In the years ahead, Internet-enabled smartphones will likely spread to the masses, like low-end “dumb” mobile phones did years ago,¹ and the Web will have visitors who are on the move, surfing web pages on crowded buses, on street corners, in cafés, in restaurants, and, dare I say it, in movie theaters. Mobile devices offer special challenges for you, the web developer/designer. The screen resolution is more complicated, and the screen real estate is more confined, but with a helping hand from CSS3, HTML5 is well supported on contemporary smartphones. What you learned from prior chapters applies here, albeit things may be a little slower and there is a smaller screen area to work with, but those are the design challenges to work around, and they are counterbalanced by the unique possibilities of the mobile space. This chapter will discuss those challenges and possibilities and finish with a discussion of some last corners of the HTML5 specification.

Challenges of the mobile Web

Over the past few years, a host of new Internet-enabled handheld devices have become widely available. While Internet-enabled mobile devices have been around since the 1990s, they arguably first became widely viewed as a viable platform for viewing web pages (as opposed to just using them for e-mail, for instance) with the introduction of the iPhone and its large colorful touchscreen in 2007. What followed was an explosion of large touchscreen devices running iOS, Google's Android OS, Microsoft's Windows Phone 7 platform, and more. Designing for the Web suddenly became a multifaceted process, many times more so than before. A web page might be viewed on a large wide-screen display in a desktop computer environment with loads of processing power, but it may be viewed on a small handheld mobile phone, with processor constraints and a display of just a few inches across. And then there are tablet devices that fall in between the two, such as Apple's iPad or the Samsung Galaxy Tab. However, designing for more than desktop displays is about more than taking differences in screen size and processing power into account. Mobile devices won't have a mouse, and clicking will likely be done with a finger (or stylus if the device is older), so small buttons are best avoided. Then there is the issue of connectivity. Mobile devices may drop their connection as the user is moving about.

__________

Responsive design

Let's consider screen size to begin with, because it is the most obvious difference between desktop computers and handheld devices. There are two broad approaches to mobile design. The first is to essentially develop two different sites, one for a desktop environment and another one for a mobile device. The user is directed to one or the other depending on what browser they view the site in. This may be a viable approach for complex sites that may need lots of effort to accommodate a mobile viewing experience and are better off presenting a simpler version of the site for mobile users. A problem with this approach is the potentially high maintenance involved. If a different site is created for desktops, tablet devices, and mobile phones, what happens if another device with a different form factor becomes popular? For example, Opera has a web browser for the Nintendo Wii game console, and Internet-enabled wristwatches running Android OS have even been developed! The other option is to change the style sheet in use based on the screen size of the viewing device. Media queries (discussed a little later) can be used to change the CSS depending on the physical qualities of the viewing device, such as changes based on the display size and resolution. Combine this approach with a fluid layout, and you get what is termed responsive design,² which aims to accommodate a broad range of screen sizes.

A fixed 960-pixel-wide grid has long been a web design standard that uses CSS to create rows and columns. Developed from this has been responsive grid design, which increases or decreases the amount of columns on the page based on the width and expands the columns visible to the width of the browser viewable area. Development kits such Skeleton (http://getskeleton.com) have emerged to help develop flexible layouts of this sort.

The viewport

On a desktop environment, the viewport is the area of a web page visible in a web browser. For instance, if you opened up a web page on your desktop and resized the page down to the physical size of a mobile phone display, the area you see is the viewport. You will likely see scrollbars appear so you can scroll to the rest of the content. You'll also notice the text may wrap to fit in the visible area, if it is not otherwise sized with CSS.

The behavior of the viewport on a mobile device is slightly different. Unlike a desktop environment, in a mobile environment, the web browser covers a fixed area. The viewport defines the area in which text would be wrapped and so forth, which may extend outside the viewable area. The default viewport on iPhone, for instance, is 980 pixels wide (to comfortably accommodate the 960-pixel web page width commonly used in web design), but the page may be scaled down so it fully fits in the 320-pixel viewable area (Figure 8-1).

__________

Figure 8-1. The viewable area on a typical smartphone is 320 pixels, while the viewport the page is laid out in may be much larger, requiring the user to pan to see all content on the page when viewing at actual size.

Ideally, the web page width would correspond to the viewable area, and this is what can be done to optimize a web page for mobile viewing. To begin with, there is a meta element value that tells a mobile device to set the width of the layout viewport to the width of the viewable area. To do this, the following would be added in the head section of the web page:

Next, an additional option can be added to prevent the page from zooming unnecessarily. Add initial-scale=1.0 to the meta element:

The viewport meta element value is a fairly recent addition; it was added by Apple for use on the iPhone but has since been incorporated into other contemporary mobile OSs. However, to accommodate older mobile browsers, it is a good idea to add two additional meta elements:

Both these values herald from the earlier days of the mobile Web, so eventually they will no longer be necessary to include, but for now it is a good idea to include them.

Now if the page layout is optimized for a 320-pixel-wide viewing area, it will fit right into the display area of most modern mobile phones, but to actually achieve this width and allow the site to still be comfortably viewable in a desktop environment, you will very likely use media queries, which we'll look at next.

Media queries

Media queries are a new addition in CSS3 that allows CSS to inspect the physical characteristics of the viewing device and change the CSS rules accordingly. Media queries grew out of the need to tailor CSS for different media types, such as for print or for screen. A typical media query might look like this:

This appears in an external CSS file linked into the page. It specifies both the type of media the enclosed CSS rules will apply to (in this case it's for displaying on a screen) and the minimum and maximum width of the viewing screen on which the enclosed rules would apply. It's not necessary to specify both the minimum and maximum widths. A lot of other values can be selected against as well, such as an exact width, height, orientation, color, resolution, and so on.³

Using media queries in a tiered configuration is useful for accommodating ranges of screen sizes, each fitting the content into a smaller and smaller screen area:

These three rules constrain the width of the page through three screen size changes. This example just shows constraining the width, but you will want to style the content all-around for mobile viewing, which would likely mean larger text and larger link areas. For example, the City Press news tips form used in Chapter 4 might be altered using media queries to appear in a mobile browser, as shown in Figure 8-2. To tailor the content for the mobile environment, extraneous information has been positioned out of view using CSS, and styles have been added to make the menu more prominent.

__________

Figure 8-2. The City Press mobile-optimized news tip submission form page

TESTING MOBILE WEB PAGES

Offline application cache

The offline application cache is a way to ensure that critical files are stored on the client so that if the connection is lost and the page is reloaded, the cached files will still be loaded. If all necessary files are cached, the website can be navigated normally even when the user is offline. This may be particularly useful in a mobile web context, where the Internet connection might be intermitted.

The application cache uses the manifest attribute found on the root html element to associate the web page with a cache manifest file that lists the files to cache (or in some cases, not cache!). The cache manifest file is just a text file with the .manifest file extension. It must be served from the web server using the text/cache-manifest MIME type. It use a relative or absolute URL but typically looks something like this:

The sitecache.manifest file (depending on your configuration; you may name it differently) must begin with the key phrase CACHE MANIFEST and then is followed optionally by three sections. These are the following:

• CACHE: The files to cache.
• NETWORK: The files that always should be retrieved from online.
• FALLBACK: Fallback content for files that were not found in the cache. The file to find is given first, followed by the fallback file's location.

The cache manifest can also contain comments, which are ignored. Comments begins with the hash sign (#). A cache manifest file might look something like this:

This would need to appear on any page that was using the cache. The files listed under the CACHE section will be stored on the client machine and retrieved as necessary to navigate the site. Any files appearing under the NETWORK section will always be fetched from the server. The FALLBACK section maps pairs of files together so that if the first one is not found, the second one will take its place on a page. Using fallbacks, you can provide visual clues to the user that they are surfing a cached version of the page. For example, you could provide alternate images that are branded “offline,” which would show up only when the user was viewing the cached images.

Other HTML5 technologies

There are a number of technologies in the HTML5 family that either are not mature enough or are too broad to address within the scope of this book. However, that is no reason you shouldn't be aware of their existence! What follows is a high-level overview of these technologies.

Microdata

Microdata is HTML5 for machines. It's for search engines and other external applications that may want to derive meaning from your content but need more information to understand it. To do this, existing HTML elements can be annotated with attributes that define the type of data on the page to a much finer degree than what is possible with existing semantic HTML elements.

At its most basic level, Microdata uses three attributes: itemscope, itemtype, and itemprop. Consider, for instance, a paragraph about this book:

To mark this up using Microdata, first the itemscope property is added to indicate that this paragraph contains a collection of data that is related, a book and authors in this case:

This annotation means that any elements inside the paragraph are related to each other. The itemtype attribute is then used to give a URL of a Microdata vocabulary, which is a defined set of property values for different types of common data, such as people, places, events, and things. The website http://schema.org (which was launched by Microsoft, Google, and Yahoo!) contains a number of vocabularies for an assortment of data. We'll use their documentation on a Book to annotate this paragraph. The itemtype is added with the URL to the vocabulary definition:

Visiting the vocabulary address, you will see there are a large number of properties that could be used, many more so than what we need in this simple example. We'll use the itemprop attribute to annotate the content with properties from the documentation. To separate the title from the authors, we'll also need to add span elements for the annotations to attach to:

First the name of the book is annotated, followed by the authors. The authors are a bit of a special case, because they are another object in the Microdata universe, that of a Person, which means they could have their own itemscope property and have additional information marked up about them, such as birth date, address, telephone number, nationality, and so on.

Search engines or other applications could parse this paragraph and be able to pick out where the book title began and ended and who the authors are. This is just a taste, but you should now have an idea of what Microdata is about. The concept is rather simple: keys and values are used to provide detailed metadata for content on a page.

There's some contention over Microdata, because it overlaps with two other formats that existed before it, Microformats and RDFa⁴ (Resource Description Framework in attributes). Also, since http://schema.org was launched by several large corporations with vested interests in search engine technology, the neutrality of the syntaxes advocated by this website have been questioned. It is, however, a good starting point to familiarize yourself with the concepts of annotating your page content.

__________

Undo manager API

The undo manager API is a new interface for allowing a web page access to the undo/redo transaction manager inside the web browser. What does this mean? Well, think about when you type some text in the search bar in a web browser; you will likely be able to select Edit Undo to undo the text that you entered. This is the browser's native undo manager allowing you to undo an operation you have done. However, if you have an interactive web application, such as a rich text editor or drawing application built on canvas, which is controlled by JavaScript, the browser's native undo manager would not pick up the modifications performed by the script. This is where the undo manager API would come in, because it would provide a method to add actions performed via JavaScript to the browser's undo/redo manager. Just as the history API operates by adding URLs to the history “stack,” the undo manager allows a particular set of changes to the page (together called a transaction) to be added to the browser's native undo stack. Since this feature is still under development, don't expect it to work in browsers today, but keep it in mind as a capability that will likely arrive in browser implementations in the not-too-distant future.

Upcoming CSS technologies

As you know, this one isn't an HTML5 technology, but it goes hand in hand with HTML. As there are many developments in HTML5, there are also many in CSS3. An interesting area has to do with page layout, and the specifications in this area have yet to fully coalescence into a dominant method(s). Eventually it's expected there will be three main specifications in this area: multicolumn layouts (discussed in Chapter 6); Flexible Box Layouts,⁵ or FlexBox, which provides better alignment and positioning of elements within their parent container; and grid/template/region layouts. Currently, grid/template/region layouts are broken into four distinct specifications, but these will likely merge in the future. Grid positioning and grid layouts are for handling rows and columns and specifying how elements are positioned in this type of layout (a multicolumn layout can already be thought of as a rowless grid layout). The template layout uses a grid as well but defines a template such as “abc” or “bca,” where each of the letters corresponds to an element, which can then be rearranged by changing the template lettering order. Lastly, the region layout proposes a means by which content would “flow” from one element to another when it overflows its bounds. Positioning in CSS has always been a headache, particularly for novice designers, so these new proposals to the specification will likely empower CSS coders in the same way that HTML5 has provided an explosion of possibilities for HTML coders (and very likely these two people are one and the same, so the creative possibilities will likely be dramatically expanded!).

Lastly, it's worth noting some of the new selectors that are defined in the Selectors Level 4 specification.⁶ See Table 8-1 for a list of the upcoming new selectors and a description of their use. Don't expect these to work in the near future, but down the road these will likely be supported by your preferred web browser.

__________

Summary

Predicting the future is easy if you assume that the direction things were headed in was wrong and set out to define your own new path. And it seems this has been the way HTML5 has turned out. Web developers disillusioned by the confines of XHTML turned to HTML5 with the hope that it would provide the platform they needed for a new generation of web applications. Now that it has paved its own path forward, the momentum to reinvent the Web has brought a whole new palette of possibilities. There is the flexibility of syntax, the new elements, and the multimedia and richness of JavaScript and CSS features. We've covered a lot, and there is more to come, but for now we've come to the end of this journey. Let this be the beginning of your exploration. There are many roads you can take from here, such as delving deeper into mobile development, CSS3, or the extensive HTML5 APIs. The details of the specifications will no doubt evolve, because that is the nature of the Web, but the fundamentals of what you learned here and the concepts behind the components of HTML5 will continue under the same foundation of knowledge, even if there are changes in the syntax in the future. It is time to play with these technologies and see what is possible in the world of open standards. Go on and craft pages that are semantically sound and rich in content. Go on and make the Web a better place.