39,59 €
HTML is fast, secure, responsive, interactive, and stunningly beautiful. It lets you target the largest number of devices and browsers with the least amount of effort. Working with the latest technologies is always fun and with a rapidly growing mobile market, it is a new and exciting place to be."Learn HTML5 by Creating Fun Games" takes you through the journey of learning HTML5 right from setting up the environment to creating fully-functional games. It will help you explore the basics while you work through the whole book with the completion of each game."Learn HTML5 by Creating Fun Games" takes a very friendly approach to teaching fun, silly games for the purpose of giving you a thorough grounding in HTML5. The book has only as much theory as it has to, often in tip boxes, with most of the information explaining how to create HTML5 canvas games. You will be assisted with lots of simple steps with screenshots building towards silly but addictive games.The book introduces you to HTML5 by helping you understand the setup and the underlying environment. As you start building your first game that is a typography game, you understand the significance of elements used in game development such as input types, web forms, and so on.We will see how to write a modern browser-compatible code while creating a basic Jelly Wobbling Game. Each game introduces you to an advanced topic such as vector graphics, native audio manipulation, and dragging-and-dropping. In the later section of the book, you will see yourself developing the famous snake game using requestAnimationFrame along with the canvas API, and enhancing it further with web messaging, web storage, and local storage. The last game of this book, a 2D Space shooter game, will then help you understand mobile design considerations.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 516
Veröffentlichungsjahr: 2013
Copyright © 2013 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: June 2013
Production Reference: 1190613
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-84969-602-9
www.packtpub.com
Cover Image by Duraid Fatouhi (<[email protected]>)
Author
Rodrigo Silveira
Reviewer
Thomas Mak
Acquisition Editor
Andrew Duckworth
Commissioning Editor
Shreerang Deshpande
Lead Technical Editor
Madhuja Chaudhari
Technical Editors
Veena Pagare
Priya Singh
Sampreshita Maheshwari
Project Coordinator
Apeksha Chitnis
Proofreaders
Aaron Nash
Bernadette Watkins
Indexer
Hemangini Bari
Graphics
Ronak Dhruv
Valentina Dsilva
Production Coordinator
Nilesh R. Mohite
Cover Work
Nilesh R. Mohite
Rodrigo Silveira is a web engineer at Deseret Digital Media. His responsibilities include back-end system development, tools, and maintenance, front-end application development and design, and more recently, he's been involved in mobile development of various products on the Android platform.
He received his Bachelor's of Science in Computer Science from Brigham Young University, Idaho, as well as an Associate's Degree in Business Management from LDS Business College in Salt Lake City, Utah.
His fascination for web development began in his early teenage years, and his skills grew as he discovered the power of a library subscription, a curious and willing mind, and supportive parents and friends. Today Rodrigo balances his time between the three great passions of his life—his family, software development, and video games (with the last two usually being mingled together).
Thomas Mak, also known as Makzan, is a developer with a specialty in web development and game design. He has over ten years of experience building digital products, including real-time multiplayer interaction games and iOS applications.
He is currently a founder of game development learning company, 42games (http://42games.net), where he makes game development tutorials and online learning resources.
He has written two books with Packt publishing and one screencast series for building Flash Virtual World and making games with HTML5 and related web standards.
I would like to thank my family and my wife, Candy Wong, for supporting all my writings.
You might want to visit www.PacktPub.com for support files and downloads related to your book.
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at <[email protected]> for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
http://PacktLib.PacktPub.com
Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book library. Here, you can access, read and search across Packt's entire library of books.
If you have an account with Packt at www.PacktPub.com, you can use this to access PacktLib today and view nine entirely free books. Simply use your login credentials for immediate access.
If you would like to write a software that can reach billions of people world-wide, then this book will help you get started on that journey. Today, most of the devices people use every day (computers, laptops, tablet computers, smart phones, and so on) are capable of running HTML5 code. What's more, as modern web browsers continue to get more and more powerful, your HTML5-based games and applications can run at or very near native application performance levels.
This book will help you learn all about HTML5, including the semantic markup elements, CSS3 styling, and the latest supporting JavaScript APIs. With this knowledge and skill, we'll be able to create fun games that can be played by anyone using a device connected to the Internet.
Chapter 1, An Overview of HTML5, explains what HTML5 is, and how it fits into the Open Web platform paradigm. It also introduces the three pillars of HTML5, namely the new HTML elements, CSS3, and new JavaScript APIs.
Chapter 2, HTML5 Typography, introduces the first game in the book, namely, a DOM-based typography game. The main HTML5 features described in the chapter include web forms, metadata, web fonts, transitions, animation, text shadow, box shadow, window.JSON, and querySelector.
Chapter 3, Understanding the Gravity of HTML5, builds a basic jelly-wobbling gravity game. This chapter includes a discussion of cross-browser support, polyfills, and how to get around different API implementations among different browsers. The main HTML5 features described in the chapter include web audio, SVG graphics, and drag-and-drop.
Chapter 4, Using HTML5 to Catch a Snake, creates a traditional snake game using the new HTML5 canvas element, with its accompanying 2D rendering context. Other HTML5 features described in the chapter include web workers, offline storage, and RequestAnimationFrame.
Chapter 5, Improving the Snake Game, builds on the same game created in the previous chapter, adding features such as window messaging, web storage, local storage, session storage, and IndexedDB.
Chapter 6, Adding Features to Your Game, focuses the discussion on advanced HTML5 concepts, as well as the latest features. Although no game is built in this chapter, the JavaScript and CSS APIs described represent the current state of the art in HTML5 and web development. The major features described in the chapter include WebGL, web sockets, video, geolocation, CSS shaders, CSS columns, and CSS regions and exclusions.
Chapter 7, HTML5 and Mobile Game Development, concludes the book by building a 2D space shooter game completely optimized for mobile game play. The focus of the chapter is mobile-specific considerations in web development, including a discussion about the differences between desktop and mobile platforms. The major HTML5 features described in the chapter include media queries and touch events.
Setting up the Environment, walks through the setup of a local web development environment, including installing an open source Apache server. In addition to setting up the development environment, it demonstrates how to build a web portal using the new HTML5 elements, from which we can access the games developed throughout the book. This chapter is available online at: http://www.packtpub.com/sites/default/files/downloads/Setting_up_the_Environment.pdf.
You need the latest version of a modern web browser, which, at the time of writing' includes Google Chrome, Mozilla Firefox, Safari, Opera, and Internet Explorer (at least Version 10). You also need a basic text editor of your choice, although any code editing software you may be familiar with will also suffice. Prior knowledge of, or experience with HTML, CSS, and JavaScript is helpful, but not required.
This book is primarily written for developers with prior experience with game development, who are now making the transition to HTML5. The focus of the book is not the complexities and theories of game development, but rather, it focuses on helping the reader learn HTML5, and how the Open Web platform can be a means to reaching billions of users world-wide.
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply send an e-mail to <[email protected]>, and mention the book title via the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the erratasubmissionform link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded on our website, or added to any list of existing errata, under the Errata section of that title. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
You can contact us at <[email protected]> if you are having a problem with any aspect of the book, and we will do our best to address it.
Welcome to the fascinating world of web development! As we begin our journey towards HTML5 development, we'll take the time and review the past. After all, you can't really get anywhere unless you know where you're coming from. Unless you have been living under a rock for the past several years, you have certainly heard a lot about Web 2.0, the Open Web, and definitely HTML5. If you have heard those terms from, say, three different people, you will probably have also heard at least three different definitions of each. For this reason, we will briefly describe what those terms mean, why you should be excited about them, and how HTML5 is a game changer.
The first term we need to be clear about before we start talking about the Open Web, and how HTML5 plays a central role in its success, is HTML. Simply put, HTML is a very basic markup language used to describe text files to the programs that read them. While that is possibly the most generalized definition of what it is, it is interesting how such a fundamental technology has played such a crucial part in the development of our entire society. From humble beginnings, and serving a very specific purpose at first, HTML has become the primary markup language of the Web, which in turn has found its way into almost every household throughout the world, as well as most briefcases, pockets, and other electronic devices.
Given this dramatic, widespread reach of HTML, it quickly became clear that the technology needed to do more than simply declaring the color of some block of text, or the width and height of a photograph stored in some research paper. Because of the many different ways in which the Web has been used over the years, HTML has grown and evolved, going from a simple markup language, to becoming the foundation for the development of powerful, highly complex online applications and services.
Hyper Text Markup Language, or HTML for short, as we know it today was first conceived in the mind of Tim Berners-Lee in 1989. At the time, while working at the European Laboratory for Particle Physics in Geneva, Switzerland, Tim Berners-Lee thought it would be beneficial to link the various research documents written and used by scientists. That way, instead of having a large collection of individual and independent documents that one could read, each document that referenced another research paper could have a hyper link to the other document, so that the reader could navigate from one document to the next with ease, and in a timely manner.
In order to implement his idea of hyperlinking documents together, Tim Berners-Lee looked to an existing markup language as the basis for his own markup language—Standard Generalized Markup Language or SGML for short—as a starting point. SGML was a simple language designed to structure text by using a tag vocabulary. For example, in order to specify that a block of text was to be interpreted as a paragraph, one would surround such text with a pair of "paragraph tags", which looked the same as today's paragraph tags in HTML. While the basic vocabulary in Tim's version of the language remained the same, one key tag was added—the hyperlink tag. Thus, HTML was born.
Keep in mind that Tim's vision for the language was very specific. Through HTML's ability to cross-reference documents together, published scientific research papers could be much more efficiently studied. It was not until many years later that HTML started being used for other purposes beyond sharing of interlinked text.
As the computer became more common place and more people started to own their own machine, and as the Internet became more widely used, people started finding new ways to use the new technology. Instead of using the Web simply to read what others had written, people began to use it to talk to people by writing and publishing documents. It wasn't long after that until the Internet became a giant virtual society.
The Internet continued to grow in popularity through the 1990s, and different uses for it continue to emerge. With each new idea of how that amazing infrastructure could be used, new ways had to be thought of in order to bring those ideas into reality, since the technology that supported the Internet was still the same. At its core, a web application was still nothing more than a text-based document, formatted using HTML. In order to add some logic to this otherwise static data, programmers used programs stored in the web server to manipulate input from the user, and create HTML documents dynamically. Again, the actual documents that users interacted with as they navigated the Internet, were nothing more than pure HTML.
In order for the Internet to continue to grow and adapt to the way and purposes for which it was being used, changes were needed. Instead of only sending plain text data to HTML readers (web browsers), it would be more efficient if there was a way to add some sort of code to the web pages, so that it could process information while on the browser. Thus, JavaScript was born.
Today the Web continues to grow both in terms of the amount of people using it, and in the ways and purposes in which it is used. The good news is that the technologies that support and run the Web are also growing and evolving, so that new use cases can be accommodated.
You undoubtedly have heard people using the term HTML5 in different contexts, which has probably caused at least some confusion. Like most so-called technical terms that find their way into the general population, and frequently fall from the lips of not-so-technical people, HTML5 finding it's way into the general population in fact means more than one thing. At the most basic level, HTML5 refers to the next version of the markup language created by Tim Berners-Lee, which now has a governing body guiding its progress. The other meaning of the term makes reference to other technologies that compliment the markup language, as well as the idea of an Open Web, which we'll talk more about later in the chapter.
Believe it or not, people have been trying to develop full-featured, complex applications intended to be executed in web browsers for a long time. For the most part, the greatest challenge has been the fact that the technologies required to accomplish this goal haven't been fully available until relatively recently. The reason why it was so difficult to create large web applications using earlier versions of HTML was that HTML was not originally designed for this. However, as the Web has evolved, so has HTML.
One of the goals of HTML5 is to accomplish exactly that—to enable developers to create powerful, non-trivial applications that run completely over the Internet. Another major goal of HTML5 is to be completely backwards compatible, so that web pages used for other purposes (namely the hyperlinking of research documents) can still function the same.
Just as Tim Berners-Lee added the hyperlink tag to SGML (among other tags), HTML5 is basically just that—more tags (or more functionality) to the previous version of the language. While that is a good, general overview of what HTML5 is, there is a bit more to the story. Beyond the new tags added to the HTML specification, the term HTML5 also refers to this next step in the evolution of the Web.
Some people have called this Web 2.0 and others have simply called it the future. When I refer to this next step in the history of HTML, I'll be referring to the upgrades done to HTML, CSS, and JavaScript, since these are the three major technologies behind this new Internet, where web applications (including online games) are the center of attention, as well as one of the focuses of this book.
Before providing the developer with new features, HTML5 tries to solve core problems that were exposed in previous versions of HTML, namely the programming architecture. Since HTML was not originally created with web application development in mind, as programmers started using it for such purposes, they soon found themselves with very messy code. The application data was heavily mixed with the presentation code, which was in turn tightly coupled with the application logic.
To solve this problem, developers were given Cascading Style Sheets (CSS), which allowed them to separate HTML markup (the information) from how the information was rendered. Thus, the term HTML5 really refers to three separate technologies, namely HTML5 (the new semantic elements or tags), CSS3, and JavaScript (all the new APIs, such as web storage, web workers, and web sockets, to name a few).
As developers see the need for, and experiment with different applications for existing technologies, they use what they have, and adapt it to the new circumstances. Such was the case with previous versions of HTML. Since only a handful of container tags existed, developers described very complex document structures with the same elements; while this accomplished the job, it also made it confusing and hard to maintain structures. Simply put, if all you have is a hammer, then everything you see will become a nail.
For example, it was common for developers to use the <div> tag to represent every single part of the document when describing a structure like the one represented by the following illustration:
Figure 1
The previous figure shows a very typical structure of most websites built in the last generation of web design.
Such a design could be represented by the following structure:
While using the <div> tag for any purpose under the heavens was one way to get the job done, you can see how this can quickly get out of hand, and turn the document into something hard to understand without great inspection. Looking at this type of code becomes especially troublesome when you see a long series of closing <div> tags—how can you know what each closing tag is actually closing, since all the tags have the same name? Worse yet, how can you know if you have just the right number of closing tags?
Another major problem with designing HTML structures after the <div> paradigm was that each tag was completely meaningless from a semantic point of view. In order to make each <div> tag slightly more meaningful and self-describing, extra attributes were added, normally in the form an an ID or a class. Again, this solution only added to the problem, since larger, more complex documents required more and more of these attributes, which one had to keep track of, thus increasing the complexity of what should be a simple solution.
Thankfully, in HTML5 this problem is solved in a very elegant manner. Seeing that a lot of documents used the <div> tags for the same purpose, namely to define common sections such as the header, footer, navigation, and main content, new tags were added to represent such common sections. With these new tags, you are now able to visually scan a design structure, and very quickly understand the way information is to be laid out. Furthermore, the need to create endless ID attributes in order to distinguish each <div> tag is completely gone.
Using some of the new tags provided by HTML5, the same design concept from figure 1 can be represented as follows:
Downloading the example code
You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
You can see how much more descriptive the code becomes. Keep in mind also, that the benefits of this more meaningful structure extend beyond better readability for humans. With the new semantic tags in HTML5, search engines (such as Google, Microsoft's Bing, and Yahoo!) are able to better understand the content of web pages, and can therefore better index your website based on its subject matter, thus making the Web a bit better. Also, by defining your HTML files with more specific tags, screen reader software is able to better understand the contents of web pages, thus allowing users who depend on such software to better use and enjoy the Internet.
Since the Internet seems to have made our world completely flat, you should never make the assumption that only your friends and neighbors will be accessing the content you publish online. Not only will your visitors come to your site from other countries and devices (such as smartphones, tablets, and even television sets), but many of the people surfing the Internet (thus, coming to your site to consume the material you make available to them) also have special needs such as visual or audio aid devices or software. For this reason, when you lay down any HTML code, keep that in mind, and consider how a screen reader program might interpret your content, and how easy it will be for that user to use and consume your work.
The following tags were added to HTML5 to accomplish this new, more streamlined semantic order. Keep in mind that each tag has several attributes, which we'll discuss in detail when we show sample usage in the next chapter. Also, because of the new data attributes, elements can be extended arbitrarily.
The following table has been taken from HTML5 W3C Candidate Recommendation 17 December 2012, which can be found at http://www.w3.org/TR/2012/CR-html5-20121217/.
Tag name
Description
<address>
This tag represents contact information related to its associated article element, or related to the entire document when associated with a body element.
<article>
This tag represents a standalone piece of content, such as an article or blog post. Article elements may be nested, in which case a child article node would be associated with its parent, yet it would still be independent of all other pieces of content in the document.
<aside>
This tag represents a piece of content related to other content elements within the document, yet could still be represented independently of its related elements. For example, sub-navigation sections, sidebars, and so on.
<audio>
This tag represents a sound or audio stream (or both) from a single source. Multiple sources may be specified, though the browser selects the most appropriate source to stream from.
<bdi>
This tag represents an isolated piece of text context that may be formatted in a bidirectional fashion.
<bdo>
This tag represents an element that controls the text direction of its children elements. The value of the dir attribute specifies whether text within the element is to flow from left to right (with a value of ltr) or from right to left (with a value of rtl).
<canvas>
This tag represents a rectangular panel that may have its contents manipulated through rendering context APIs exposed through JavaScript.
<command>
This tag represents a command that can be executed by the user, such as a keyboard shortcut.
<details>
This tag represents additional content related to some other element or content.
<figure>
This tag represents independent content that may be used as annotations for photos, illustrations, and so on.
<footer>
This tag represents a section of content with information about its elements, such as copyright information and other details about an article.
<header>
This tag represents a section heading, such as table of contents and navigational elements.
<hgroup>
This tag represents a section subheading, such as alternative titles and bylines.
<mark>
This tag represents a section of content marked up for referencing, similar in purpose as highlighting a block of text.
<meter>
This tag represents a value within a known range, such as the amount of energy left. Note that since there is a dedicated progress element, the meter element should not be used to represent a progress bar.
<nav>
This tag represents a navigation element with links to other documents, or links within the same document.
<progress>
This tag represents the amount of progress done within a known range, such as the number of steps completed in a registration process.
<rt>
This tag represents the text component of a ruby annotation.
<rp>
This tag represents the text component of a ruby annotation that is displayed by the browser when ruby annotations are not supported.
<section>
This tag represents a general-purpose section within the document, such as a slide, or the area of a document where a list of articles is displayed.
<summary>
This tag represents a summary of some content.
<time>
This tag represents a date and time in both human and machine-readable formats. The content displayed by the browser is meant for human consumption, whereas the data attributes are designed to be used by the browser and other applications.
<video>
This tag represents a video stream from a single source. Multiple sources may be specified, though the browser selects the most appropriate source to stream from.
<wbr>
This tag represents a line break opportunity, hinting to the browser where it would be appropriate to break a line when needed. Note that this element has no width, so that when a line break is not required, the element is not visible.
Something that is often overlooked in web design and front-end web development is performance. While today's major browsers make rendering HTML seem like a trivial task, there is actually a lot of work going on behind the scenes in order to turn a collection of HTML tags and CSS into a nice looking web page. What's more, as it becomes easier to add bells and whistles to a web page through rollover effects, drop down menus, and automatic slideshows, it is easy to forget about what the browser still needs to do to get that work done.
If you think about an HTML document as a tree structure, where each nested tag is like a branch in the structure, then it's easy to understand what a deep layout would look like compared to a shallow layout. In other words, the more nested tags you have, the deeper the structure.
With that said, always keep in mind that the slightest change in an HTML node (such as the physical size a text tag takes up on the page changing because a hover effect caused the text to become bold, thus taking a few extra pixels on the screen) may trigger what is called a reflow, which essentially will cause the browser to perform many calculations on each and every branch (tag) in your HTML structure, because it will need to recalculate where each element needs to go, so it can redraw the page properly.
The more shallow you can make your HTML structures, the less calculations the browser will need to make every time it needs to redraw the page, thus causing a smoother experience. While the argument that deeply nested <div> tags cause HTML files to become harder to read and maintain can be subjective, there is no arguing that deep HTML structures perform much worse than flatter alternatives.
Cascading Style Sheets, most commonly known simply as CSS, is another contributing technology to the success of HTML and the World Wide Web. CSS is a style language that controls the way an HTML structure is rendered. Some of the benefits of using a style language alongside a markup language include separation of concerns, reusability of visual design, ease of maintenance, and scalability. As part of the HTML5 revolution, there were some significant updates to the CSS spec, which have also taken the language to a whole new level.
The first, and possibly most apparent benefit that CSS brings to the game is separation of concerns. By allowing HTML to describe the data that it represents, and not worry about how that data is presented, CSS is able to control the way that data is displayed. This way the CSS expert can work on styling a web application without the need to touch the HTML file. Best of all, the CSS expert needs absolutely no knowledge of any of the possibly many other technologies used in a given project. This way, no matter how complex the rest of the project is, the styling can be done independently and separately.
There are many ways to include CSS rules into an HTML document. For example, you can write all the CSS code right into the same HTML file that uses it, you can write it inside each HTML element as you create them, or you can put the CSS style in a completely separate file, then import the stylesheet into the HTML file. Most commonly, what you'll want to do is write all your CSS code in one or more separate files (think separation of concerns), then import each file into the HTML files that you'd like to use for each set of styles. This way you can have a single stylesheet that describes a particular visual theme, then you can reuse that theme throughout an entire application (possibly composed of thousands of individual HTML files and pieces) simply by importing the stylesheet with a single line of code:
The previous code is an example of CSS rules written on a specific element. In this case, only this HTML paragraph tags will use the style defined by this simple rule (which tells the browser to render the text in red, and 23 pixels height).
The previous code is an example of CSS rules written in a separate document. In this case, any HTML paragraph tags in the file index.html will use the style defined by this simple rule (which tells the browser to render the text in red, and 23 pixels height). Other documents will not use the styling rules found in my-style sheet.css if the stylesheet is not imported into those files.
Another tremendous benefit that you get by separating the presentation of your HTML documents through external CSS files is that maintenance becomes very easy. Imagine the scenario where you write all your styles in the same document that uses them. If you only have one document, then that's not a big problem. However, most projects include multiple HTML files. So imagine that you simply copy and paste the CSS from one file into the next, since they both share the same CSS rules. How would you go about making a change to some of these rules if you now have tens or hundreds of files to update also, since the CSS to be updated in found in all of these HTML file?
Thus, if you only have a few CSS that only contain CSS code, and all the HTML files that use them simply import the stylesheet, whenever you need to change the style for your project, you only need to update one CSS file. Once that CSS file is updated, all other HTML files that import the CSS will automatically use the new style.
Lastly, the advantage of using CSS is that it makes the presentation layer of your project very scalable. Once the CSS code is in place, you can use it throughout hundreds of thousands of files (think of Wikipedia, for example), and the style will be consistent throughout all of them. If you then decide to upgrade your design, you only need to make changes to one file—the stylesheet.
Although the idea of having a separate style language to handle the presentation layer of HTML documents is unarguably brilliant, CSS has been somewhat of a nightmare to most designers. Since different browsers have always tried to be unique enough from other competing browsers in order to win the favor of users, different browsers have implemented certain features of CSS differently. For examples, a CSS rule that specifies an element with a width of 500 pixels would not behave consistently in all major browsers. By specifying an element's width attribute through CSS, most browsers would only set the content width of the element, while allowing any padding, border, and margin width to make the total width of the element even larger. However, there were browsers that included the width of an element's padding and border when setting the CSS width attribute.
The previous figure shows an example of a CSS box model. Note that the margin space is always transparent, while any padding space inherits the background color or image of its corresponding element.
Inconsistencies like this made the success of CSS limited and slow. When a designer took on a project, one design would need to be coded with many browsers in mind, which also meant that it would need to be tested in many different browsers. Not only that, but the actual set of features that CSS offered were limited. For example, before Version 3, the only way to create an element with rounded corners through CSS was by adding a background image to the element, where this image was a box with rounded corners. This was not very practical, and often involved changing the HTML structure, which partly defeated the purpose of external stylesheets.
Thanks to the responsive nature of web standards, however, a new version of CSS was released alongside the new version of HTML. Officially named CSS Level 3, the new specification builds on CSS Level 2 modules, and includes additional modules. Given the wide acceptance and usage of CSS, major web browsers have been doing a much better job at implementing features more consistently, meaning that one code base is more likely to run consistently on different browsers.
As new features are added to the spec, and the spec itself progresses, browser vendors attempt to stay on top of things and provide the latest and greatest features to designers and end users. As of this book, however, not all features listed on the CSS3 specification are fully implemented by all browsers. The way you can tell if a feature is not yet fully supported by the browser (or that a feature may stop being supported by a particular browser) is that the CSS rule is prefixed by a dash, followed by the code name for the browser. For example, -webkit-(rule name).
Vendor
Prefix
Google Chrome
-webkit-
Mozilla Firefox
-moz-
Microsoft Internet Explorer
-ms-
Opera
-o-
Safari
-webkit-
Eventually, the specification will stabilize even more, and all browsers will implement the CSS specification the same, and no vendor prefix will need to appear in your stylesheet code. But until then, you'll need to repeat some CSS Level 3 rules so that each browser will recognize the feature.
It can sometimes be difficult to keep up with all the CSS features and their corresponding browser support. Some features have already gone out of the prefix (meaning that all major browsers support the rule without the vendor prefix keyword in front of the rule keyword). Still, many others haven't completely outgrown this experimental stage, and only some of the major browsers support them without any vendor prefix.
Some brave developers make the effort to stay on top of the latest browser updates, and update their code accordingly, by removing superfluous vendor prefixes from their stylesheet code. Others find this proactive effort to be counter productive, and instead include all possible versions of the rule to their code, in which case they would only need to update their stylesheet code one day in the far future, if at all.
Of course, repeating the same rule with each vendor prefix in front of it, followed by the non-prefixed rule, quickly makes your stylesheet files very large, and a nightmare to maintain. Find an approach that works best for you. There are also various tools available that help you maintain your CSS files, especially with regards to this evolving situation with the vendor prefix.
The two most popular such tools (also known as CSS preprocessors) are LESS (see http://lesscss.org/) and SASS (see http://sass-lang.com/). Although each preprocessor is slightly different, they all accomplish the same thing, namely, taking plain CSS stylesheets, then adding all the required vendor prefixes where needed.
The new CSS Level 3 modules can be divided into several modules, namely, style attributes, selectors, colors, and media queries.
Style attributes tell the browser how an element is to be rendered (or styled). This could be anything from a string of text being styled with a font size of 23 px, to styling a list of images rotated 45 degrees about their y-axis and placed above its own reflection, to styling various HTML nodes to animate every half a second using keyframe animation.
Selectors are the way you tell the browser what elements are to be styled. That is, through the special expression language of CSS selectors, you can address one or more elements whose styling rules follow the selector declaration. The new CSS3 selectors basically extend this expression language, making it possible to target different elements in different, more flexible ways.
Colors, as the name implies, hints to the browser how an element is to be shaded. Colors can be applied to the actual text on a web page, to the border surrounding text or other elements, as well as the background of elements, following the box model scheme.
Finally, media queries allow the stylesheet to target the document (or parts of it) based on various conditions. What's more, media queries are triggered in real time by the browser. In other words, if, for example, you specify a media query that defines CSS rules that should only apply when the browser window is no wider than a certain width, the browser will update the web page automatically as needed as the window is resized. This way a web page can be responsive, meaning that it responds immediately to any changes in its environment that causes any media query to become valid.
A brief definition of these modules will follow, but a more in-depth discussion, along with usage examples, can be found in subsequent chapters as each model is added to our games.
Within the style attributes module, we can subdivide the features into smaller modules that deal with custom fonts, text effects, other effects, and animation.
Attribute
Definition
border-radius
This specifies how much to round each corner or a box
border-image
This specifies an image to render over the border of a box
box-shadow
This specifies the direction and size of a drop shadow relative to a box
background-size
This specifies the size of a background image
background-origin
This specifies the offset position of background images
background-clip
This specifies how much to draw a background image
animation
This specifies various aspects of animation, such as keyframes, timing, effect, and so on
transform
This specifies various types of 2D and 3D transformations
transition
This specifies how two attributes should transition from one to the other
text-shadow
This specifies the direction and size of a drop shadow relative to text
@font-face
This specifies a font file that the browser can download into the user's system and use as a native font
CSS selectors, first introduced in CSS Level 1, have always been fairly powerful and comprehensive.
Attribute
Definition
E[foo^="bar"]
It selects an E element with an attribute foo has a value that begins with bar
E[foo$="bar"]
It selects an E element with an attribute foo has a value that ends with bar
E[foo*="bar"]
It selects an E element with an attribute foo has a value that contains bar
E:root
It selects an E element at the root of the document
E:nth-child(n)
It selects the Nth E child element
E:nth-last-child(n)
It selects the Nth E child element counting from the last child element
E:nth-of-type(n)
It selects the Nth E sibling element of its type
E:nth-last-of-type(n)
It selects the Nth E sibling element of its type, counting from the last child element
E:last-child
It selects the last E element
E:first-of-type
It selects the first E sibling element of its type
E:last-of-type
It selects the last E sibling element of its type
E:only-child
It selects an E element if this is the only child node of its parent element
E:only-of-type
It selects an E element if this is the only sibling node of its type of its parent element
E:empty
It selects an E element if it has no child nodes and no text content
E:target
It selects an E element whose ID attribute matches the URL hash symbol
E:enabled
E:disabled
It selects an E element that has been disabled through its corresponding attribute
E:checked
It selects an E element that has been checked through its corresponding attribute, or through appropriate user interaction
E:not(S)
It selects an E element that does not match a selector expression S
F ~ E
It selects an E element preceded by an F element
Source: Cascading Style Sheets (CSS) Snapshot 2010, W3C Working Group Note 12 May 2011
The two main additions to colors in CSS Level 3 are the adoption of HSL colors, and an additional alpha channel. Before, you could specify a color using RGB by specifying a value between 0 and 255 for each channel (red, green, and blue). Now the extra alpha channel can be appended to the end of the attribute, allowing you to control the level of transparency:
This CSS rule specifies a completely white background, with an opacity of 50 percent (half transparent) represented by the decimal fraction:
Alternatively, you can specify the same CSS rule using percentages for all values, which might be easier to read, and make the expression more consistent.
Specifying colors using Hue, Saturation, and Lightness (HSL) is similarly easy, and arguably much more intuitive. Instead of using the RGB or RGBA keyword, you simply specify a color as HSL by using the keyword HSL (or HSLA if you would like to add the extra and optional alpha channel). Another benefit to using HSL over RGB is that RGB is hardware-oriented, whereas HSL is not.
Here you specify a very bright red background color by setting the saturation to its limit, and lighting the color half way. Remember that setting the lightness channel to 100% will cause the color to be completely white (as a super bright light would do), while setting it to 0% will cause it to be completely black, as you would expect in a dark room; for example, see the following line of code:
Alternatively, you can specify the same CSS rule with a semi-transparent look by adding the alpha channel, and setting it to the 50% opacity.
The hue channel of HSL is a number between 0 and 359, which represents an angle in the color wheel, with red being 0 degrees, green being 120, and blue being 240. Note that this number wraps (since it's an angle value), so that 360 represents the same location in the wheel as 0. The saturation and lightness channels represent the percentage between being fully represented, and not at all.
Media queries allow you check for specific features of the device rendering your HTML file. This is most commonly used in determining in real time the width and height of the window viewing your site. A common use case for this powerful feature is to determine whether the user is on a mobile device or not. A simple way to understand media queries is to think of them in terms of conditional statements, such as, "if the media is (…)". For example, as illustrated in the following screenshot, when a media is at least 500 pixels wide, one set of CSS rules gets applied. When the media is less than 500 pixels wide, an alternative set of CSS rules are used:
The same HTML structure is rendered differently based on the current state of the browser, thanks to media queries.
This simple example specifically targets any device in portrait mode, and defines the CSS rule that specifies a red background color to the body element.
Behind the scenes, the way that browsers implement this particular media query (the portrait mode) is by calculating the width of the window viewing the page with respect to the window's height. If the window happens to be higher than it is wider, then for all practical purposes, the page is considered to be in the portrait mode. Similarly, if you manually resize the window, or if it just happens to be in a position where it is wider than higher, then the browser will consider the page to be in the landscape mode, and any media queries targeting the mode will be triggered.
In the previous example, we tell the browser to check if the window is less than or equal to 240 pixels wide. If it is, we define the CSS rule that tells the body tag to render itself with a white background.
