By Jennifer Kyrnin. Published August 22, 2013 by Sams. Part of Sams' "Teach Yourself" series.

What You’ll Learn in This Hour:

  • How HTML has grown and changed since it was invented
  • Where HTML5 fits in with the other versions of HTML
  • What the Open Web Standard is and how it relates to HTML5
  • How a web application differs from typical web pages
  • How to build a very simple HTML5 web page
  • Why you want to use HTML5 for your mobile applications

HTML5 is the latest version of HTML, and although adoption on desktop browsers such as Internet Explorer is slow, mobile devices are jumping on the bandwagon in record numbers. Nearly every smartphone and tablet device sold today supports HTML5, and those numbers are growing.

In this hour you will learn how HTML5 came into being and how it has changed the landscape for web designers and developers as well as the customers viewing your pages. You’ll learn to build a simple HTML5 document and why HTML5 is the language you should know if you want to design and develop mobile applications.

Understanding How We Got to HTML5

In March 1989, Sir Tim Berners-Lee wrote a proposal that suggested using hypertext to link related documents together over a network. After collaborating with others at CERN, hypertext eventually became HTML or Hypertext Markup Language.

HTML was based on a language already in use for marking up documents-SGML (Standard Generalized Markup Language). In September 1991, a discussion began across the internet about how the web and HTML should evolve.

Up until around 1993, the only browser available was a text-only browser called Lynx. Then Mosaic came out with features such as images, nested lists, and forms. Most designers these days take these things for granted, but back in the early 1990s many people browsed the web in a black-and-white (or green-and-black), text-only environment. Getting a browser to support images was very exciting.

It wasn’t until 1994 that the HTML working group was set up by the IETF (Internet Engineering Task Force). In July it released a working draft of HTML 2. Later that year, the W3C, or World Wide Web Consortium, was formed at MIT to act as a standards body for HTML. HTML 3 was released as a draft in 1995, and HTML 3.2 was endorsed as a standard in 1997. HTML 4 was published as a recommendation in 1999.

XML and XHTML

After 1999 things began to change. The W3C no longer felt that HTML should remain as it was. Instead, they wanted to make it more machine-readable, more consistent, and much stricter. So, rather than working on a new version of HTML, they began turning HTML into a strict markup language called XHTML.

XHTML was created as a version of HTML 4.01 that was rewritten in XML (eXtensible Markup Language). It was developed in 1998 as a way to create markup languages that are machine readable. XHTML documents must be well formed and valid. In fact, the W3C wanted all browsers that read XHTML to stop rendering the page if the page’s HTML was not valid or well-formed.

XML is still used by many companies. For example, many content management systems (CMSs) use XML on the back end to manage large websites; many books are written in DocBook, which is an XML language for publishing; and ePub books use XML to create ebooks.

Well-Formed Versus Valid

A document that is well-formed has the declaration statement at the top-including the specification, all attributes are surrounded by quotation marks, all elements are closed, and there is only one container element. A document that is valid is one that is checked against the specification and has no errors.

HTML5 is Born

XHTML, because it is based on XML, has the same strict requirements as XML, which makes XHTML very difficult to write. Although most web designers recognize the importance of creating HTML that is valid, at the end of the day the most important thing is that the HTML works in readers’ browsers. Every beginning web designer who has ever validated a page knows that just because a page isn’t valid doesn’t mean browsers won’t be able to display it. In fact, web browsers have no problem displaying technically invalid HTML.

Because of these difficulties, a group of web designers and developers as well as browser makers and others got together in 2004 and formed the Web Hypertext Application Technology Working Group (WHATWG). They started building the HTML5 specification to address the needs of designers, developers, and browser makers. Finally, in 2008, the W3C decided to scrap XHTML development in favor of reintegrating with the HTML5 community, and added the HTML5 specification into the W3C framework.

Learning What’s Different with HTML5

HTML 4 is the last recommendation developed by the W3C alone. Most web pages right now are built in HTML 4 because it is widely supported by web browsers and editors.

XHTML was created by rewriting the HTML 4.01 specification as XML, which means that all tags must be closed, the XHTML tags must be written in all lowercase, all attributes must have quotation marks around them, and tags must be nested without overlapping.

Nesting Tags Correctly

When you nest two HTML tags, you should think of them as a stack of bowls-one inside the other. Always close the nested tag first, and then close the outer tag.

Incorrect:

This text is <em>italic, and this is <strong>bold and italic</em></strong>

Correct:

This text is <em>italic, and this is <strong>bold and italic</strong></em>

HTML5 goes back to a less restrictive version of HTML. End tags are no longer required for all elements, you can write in upper- or lowercase, and attributes don’t need to have quotations around them all the time.

HTML5 also adds a lot of new elements, including a streamlined doctype (or DTD-the first line of your HTML document. It tells the browser that this document is an HTML5 one), sectioning elements, many new form features, and support for drag and drop and other features useful for creating web applications.

A New HTML5 Doctype

HTML5 has a new streamlined doctype that is very easy to remember-<!doctype html>. Nothing else is required. It doesn’t even have to be written in all caps.

Defining Web Applications

Applications are software programs that are used on a local computer to do various tasks. The most commonly used applications are web browsers (such as Internet Explorer or Firefox), document editors (such as Word), and email clients (such as Outlook or Thunderbird). These programs are very similar to one another because they all run on the same operating system.

They have features such as

  • A similar look and feel, such as the menus at the top
  • Functionality such as drag-and-drop, saving to the hard drive, and interactivity

Web applications are web pages that are attempting to look and act like desktop applications. They are written to run inside a web browser, rather than directly on the computer. This means that they are limited by the functions that the web browser can and cannot do:

  • Web applications rely on the web browser for functionality that would otherwise have to be coded (such as the back button, rendering the page, and so on).
  • Web applications are limited the same way a browser is limited. They can’t save data to the hard drive, they have only limited scripting functions, and they can’t interact directly with the computer operating system.

Web applications, unlike desktop applications, are not limited to one operating system. A web application runs in a browser, and so anywhere a browser will run, the web application will run.

Using the Open Web Standard

HTML5 was written primarily as a way to develop better, more efficient web applications, and it is part of the suite of APIs and specifications developed under the Open Web Standard. The Open Web Standard or Open Web Platform is a collection of royalty-free technologies that enable the web.

Many people think HTML5 includes more than it does. In fact, features such as the History API (discussed in Hour 22, “Controlling the Browser History with the History API”), local storage (Hour 21, “Web Storage in HTML5”), and geolocation (Hour 23, “Adding Location Detection with Geolocation”) are all separate specifications that work with HTML5 to create a suite of tools you can use to build web pages, web applications, mobile applications, and more. These all are part of the Open Web Standard.

Some of the specifications in this standard include:

  • HTML5
  • CSS3
  • Web Fonts
  • HTML Canvas
  • SVG
  • Web storage
  • Geolocation

By using standards-based specifications for your web applications, you will know that your pages and applications will work for a wider audience, and that your pages and applications will last longer.

Try It Yourself: Building Your First HTML5 Document

HTML5 is, at its heart, HTML, which is what you use to build web pages. So before you can get started on the applications that you’ll develop in later hours, you need to know how to build a web page. Video 1.1 shows an example of building an HTML5 document.

You start by writing some HTML, which is very easy to write. All you need is a text editor.

Video 1.1. Building Your First HTML Document

See Video here: http://ptgmedia.pearsoncmg.com/imprint_downloads/informit/learningkits/9780672336263/ch01.html

Finding Your Computer’s Text Editor

If you have access to a computer, you have access to a text editor for writing HTML. On Windows type in Notepadin the Search programs and files box in your Start menu. On Macintosh, type inTextEdit in the Spotlight. Use either the vi or Emacs command on a Linux computer.

After you have a text editor up and running, you can begin writing your HTML, which is defined by tags that are written inside of less-than (<) and greater-than (>) signs.

Open your text editor and type the following:

<!doctype html><html> <head> <title>This is my first HTML5 page</title> </head> <body> <h1>My First HTML Document</h1> <p>This is my first HTML5 document. </body></html>

2. Save your file as mypage.html.

Check That File Extension

Make sure to check the extension of your HTML file in your file system. Notepad will often convert it to a .txt file if you aren’t careful. If it does, simply close Notepad and replace the .txt extension with .html.

Now open this page in your favorite web browser (by browsing to it in the File menu) to test that your page displays correctly. If it doesn’t display correctly, you’ll need to check that you opened the right file and that you wrote the HTML correctly.

As you can see from the missing closing tags, the HTML is not nearly as strict as XHTML, and the first line (the doctype or DTD) is simple to use and easy to remember.

Using HTML5 with iOS and Android Devices

Many designers are reluctant to get started using HTML5 on their web pages because Internet Explorer has relatively little support for it. In fact, only Internet Explorer 9 has decent HTML5 support. Other computer browsers, such as Firefox, Chrome, Opera, and Safari, all have good support for most HTML5 features.

Testing Is Critical

If you plan to create pages and applications for iOS and Android devices as well as desktop browsers, always test your documents in Internet Explorer 8. This browser (and IE 7) still has the lion’s share of the browser market, and if your page or application doesn’t work with it, your page or application won’t work for most people browsing the web. If you don’t have a Windows machine you can use an online tool such as Browsershots (http://browsershots.org/) to test in Internet Explorer and other browsers.

But what about mobile devices running on Android and iOS, such as a Xoom tablet or iPad? They all come with HTML5 support pretty much out of the box because they each run a browser (Safari on iOS and Chrome on Android) based on WebKit, which has excellent support for HTML5.

The best thing about designing web pages and applications using HTML5 for Android and iOS is that what you are creating will work on future devices. Right now operating systems exist that run on tablets and phones and to some extent televisions. But these operating systems are moving into other devices such as cars, picture frames, and even refrigerators.

Writing Mobile Websites

In some ways, writing websites for mobile devices is a lot easier than it used to be. Although a lot more devices are out there, including smartphones and not-so-smart phones, tablets, internet TV devices, and even some picture frames, the devices are converging in what HTML5 features they support, and even in their sizes and shapes (to some extent).

When you’re creating a mobile website, the first thing to remember is that a mobile website is just a website. The best websites are built for every browser and operating system, or as many as possible.

However, you should still consider some basic questions when building a website that is intended for mobile devices:

  • What is the screen size and resolution of the mobile device?
  • What content do your mobile users need?
  • Is your HTML, CSS, and JavaScript valid and compact?
  • Should your site have a separate domain for mobile users?
  • What testing does your mobile site need?

What is the Screen Size and Resolution of the Mobile Device

When you’re working with mobile devices, obviously the screen size is going to be smaller than on a desktop. In general, with smartphones, you have to prepare for a few standard sizes:

  • 128 × 160 pixels-Phones such as the Fujitsu DoCoMo F504i
  • 176 × 220 pixels-Phones such as the HP iPAQ 510
  • 240 × 320 pixels-Smartphones such as Blackberry 8100 or the HTC Elf
  • 320 × 480 pixels-PDAs such as the Garmin-AsusA50 or the Palm Pre

Tablets add to the mix by having not only an increased screen size, but also having a variation in how they can be viewed. For example, most tablets (and some smartphones for that matter) can be viewed in portrait or landscape mode. This means that sometimes you might have a 1024-pixels-wide screen to work with, and other times 800 pixels wide or less.

However, in general, the tablets provide a lot more screen space for you to play with on mobile devices. You can assume you have around 1024-1280 pixels by 600-800 pixels for most tablet devices.

Browsing most websites in their standard format on an iPad is easy because the browser is as clear and easy to use as on a computer monitor. Plus, with the zooming capabilities on both iOs and Android, making small, harder-to-read areas bigger is easy.

What Content Do Your Mobile Users Need?

When you are designing a site for mobile devices, remember that users don’t always want to access the same content as someone browsing on a desktop.

Don’t Limit the Content

One thing mobile sites often get wrong is that they remove content from the mobile version of the site. Adjusting the content so that information that is most important to mobile users is easily available is essential. But if the content they need isn’t on the mobile site, you must allow the user the opportunity to look for the content on the full site.

For example, mobile customers are often, well, mobile. In other words, they may be in motion or away from their home or office and have a very specific need or desire when they visit your site. For example, when visiting a restaurant website on a mobile phone, a user riding in a car might need to quickly find the location of the restaurant and the phone number. If the mobile site doesn’t have the phone number and location front-and-center, the user might quickly give up on the site.

Content for mobile sites shouldn’t be limited, however. In fact, the W3C recommends “...making, as far as is reasonable, the same information and services available to users irrespective of the device they are using.”

This doesn’t mean that you can’t change the format or location of your content, but getting to the same content on a mobile device as on a computer should be possible.

Is Your HTML, CSS, and JavaScript Valid and Compact?

You don’t have to worry about writing well-formed XHTML for mobile devices, but sticking to correct, standards-based HTML, CSS, and JavaScript ensures that your pages are visible by the largest number of devices. Plus, by validating your HTML, you will know it is correct.

Video 1.2. Using an HTML Validator

See Video here: http://ptgmedia.pearsoncmg.com/imprint_downloads/informit/learningkits/9780672336263/ch01.html

Beyond writing valid HTML, you should consider avoiding a few things if you are writing web pages for mobile devices:

The W3C Validator

The W3C has a validator located athttp://validator.w3.org/ that you can use to check HTML, XHTML, and other markup languages. But you can also validate CSS and RSS, and even find broken links on your pages from this site. Don’t be afraid to check your site in the validator periodically. You may be surprised at what you find. Video 1.2 shows an example.

  • HTML tables-Avoiding tables as much as you can in mobile layouts is best because of the small size of the screen. Scrolling horizontally is difficult and makes the tables hard to read.
  • HTML tables for layout-You shouldn’t use HTML tables for layout of web pages in general, but on mobile devices they can make the pages load slower and look bad, especially if the table doesn’t fit in the browser window. Plus, when you use tables for layout, you almost always use nested tables, which make the pages load slower and are much more difficult for mobile devices to render.
  • Pop-up windows-Pop-up windows are often annoying in general, but on mobile devices they can make the site unusable. Some mobile browsers don’t support them and others open them in unexpected ways (often by closing the current window to open a new one).
  • Graphics for layout-Like using tables for layout, adding invisible graphics to add spaces and affect layout typically make many older mobile devices choke or display the page incorrectly. Plus, they add to the download time.
  • Frames and image maps-Many mobile devices don’t support these features in HTML. In fact, HTML5 no longer includes frames (other than the iframe) as a part of the specification because of the usability issues involved.

Fewer Limitations for iOS and Android

Although avoiding tables, popup windows, and image maps in mobile pages is best, if you are focusing on mobile pages for iOS or Android, you can rest easy. Both of these handle them without trouble. Frames, however, are not part of HTML5, and you should not rely on their being supported in iOS or Android.

Also remember that mobile users often have to pay a fee for their bandwidth, so your web pages should be as small (in KB) as you can make them. The fewer HTML tags and CSS properties you use and server requests you make, the better browsing will be for mobile users.

Should Your Site Have a Separate Domain for Mobile Users?

Many websites have a separate subdomain for their mobile site. This makes finding the mobile site without having to bother with the regular domain easy for mobile users. These domains are typically something like m.example.com.

Having a separate mobile domain offers several advantages:

  • It makes your mobile site easier to find.
  • You can advertise the mobile URL separately from the normal URL, giving you more reach.
  • Having a separate mobile domain enables people on tablets or smartphones to switch to the full site just by switching domains.
  • Detecting mobile users and sending them to a separate domain is much easier than scripting changes to your CSS for mobile users.

When trying to decide how to handle your mobile site version, consider how you are going to maintain the site. You can create the mobile domain manually with completely separate pages, or you can use a content management system. Hour 4, “Detecting Mobile Devices and HTML5 Support,” covers this topic in more detail.

What Testing Does Your Mobile Site Need?

Be prepared to test your site on as many mobile devices as you possibly can. Although you can use your browser to test or emulate things such as screen size, you won’t see some of the horrible things that can go wrong if you don’t test on mobile devices directly, such as the following:

  • Packet size limitations by mobile carriers preventing your page or images from loading
  • Images loading incorrectly or not at all
  • Inability to scroll horizontally (which is nearly impossible to do on some phones)
  • Device-specific features not working that you were relying on
  • File formats not being supported

You likely don’t have an unlimited budget for buying mobile phones (and their associated cellphone plans), so what do you do? Here are some suggestions:

  • Use emulators-Both online and offline emulators are available for many different mobile devices. Most are free to use and they give you at least a start at testing your site for mobile devices.
  • Rent time on devices-Services exist that will allow you to rent time on multiple phones. You can justify the cost by getting a sense of how the phones handle your applications.
  • Buy some phones-This might seem like an expensive option, but if you are planning on doing a lot of mobile web development, it could be a reasonable investment.
  • Get help from friends and co-workers-This is one of the least expensive ways to test your site-simply ask to borrow phones or tablets from people you know. You just need to put your site on a live web server.

Ultimately, if you are going to do mobile development, you should have at least one mobile device you can test your pages on directly. The more devices you can test on, the better your sites will be.

Summary

In this hour, you have learned how HTML started and the reasons for the move from HTML to XHTML to HTML5. You know the basic differences between HTML 4, XHTML 1, and HTML5 as well as what web applications are and how they relate to the Open Web Standard. You learned how to write a basic HTML web page and why HTML5 fits in so well with mobile devices. You also learned some powerful tips for building mobile web pages.

The most important things to remember from this hour are the best practices for building a website for mobile users:

  • Focus first on building a website or application for every user, not just mobile ones.
  • Determine who your mobile users are and what they are looking for, and present that content to them first, but not only that content.
  • Build a site that uses standards-based technology so that your applications are more future proofed.
  • Always test your sites and applications in as many web browsers and devices as you can.

Q&A

Q. I am not familiar with HTML, and I’m worried that I will have trouble building an HTML5 application. Do I need to know HTML 4 before I learn HTML5?

A. Although knowing HTML 4 will make moving forward easier for you, learning HTML5 is a fairly straightforward process. Although this book focuses mostly on HTML5, by copying the code samples provided and looking at the source files for the companion website (www.html5in24hours.com/), you should be able to figure it out.

Q. I already have a website, and I want to make sure that mobile users can get the most out of it. How do I make sure that I am providing what mobile users need?

A. The best way to do this is to ask them. Surveys asking your customers how they access your site and what parts are most useful to them are a good indicator of what they want. But you can also look at your web statistics. If you don’t have analytics on your website, I recommend installing one such as Google Analytics or Piwik to track what people are looking at on your site. After you know what the popular pages are, you can ensure those pages are easy to access in your mobile version.

You can also use your web analytics to see what browsers (Firefox, IE, Chrome, etc.) are visiting your website and how your customers use the site (pages they click on, where they leave, and so on). With this method, even if you can’t get direct customer feedback you can see what features they are currently using and adjust your site accordingly.

Q. You mentioned using a content management system for maintaining a mobile site. Do you have any you can recommend?

A. I use WordPress with the WordPress Mobile Pack to maintain a lot of sites for mobile and non-mobile users.