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.
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.
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.
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.
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.
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.
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
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, 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.
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:
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.
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.
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:
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:
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.
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.
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
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 at http://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.
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.
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:
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.
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:
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:
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.
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:
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.
