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:
<div id="wrapper">
<div id="header"></div>
<div id="body">
<div id="main_content">
<p>Lorem Ipsum...</p>
</div>
<div id="sidebar"></div>
</div>
<div id="footer"></div>
</div>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:
<header></header>
<section>
<article>
<p>Lorem Ipsum...</p>
</article>
<nav></nav>
</section>
<footer></footer>Tip
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.
Note
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/.
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.
As stated earlier, one of the strengths of HTML5 is the way it reflects real-world needs, and brings elegant solutions to such needs. Features that don't get used a whole lot by developers (or that don't get wide adoption by browser makers) eventually find their way out of the spec. Likewise, repeated efforts by developers to solve recurring problems eventually cause new features to be suggested, then added to the spec. As new recommendations become accepted as part of the spec, browser makers implement these new features, and the end result is that the browser is extended, and becomes capable of doing what developers had to code by hand.
As an example, let's take a look at placeholder fields. A placeholder is the text inside an input field found in HTML forms, which take the place of a separate label. When the input field is empty, the text inside it describes the data that the field expects (such as a first name, or an e-mail address). Once the user begins to type into the field, that placeholder text disappears, and the actual input from the user replaces it.
While this technique is very intuitive, it takes more physical space to represent, which becomes especially challenging on smaller screen sizes.
A much more dynamic solution, as shown in the following screenshot, is to use a combination of JavaScript and CSS to move the field label inside the field itself:
Before HTML5, this effect took quite a few lines of boilerplate JavaScript code:
<style>
.hint-on { color: #ddd; }
.hint-off { color: #333; }
</style>
<input type="text" name="firstName" value="First Name" class="hint-on"
onblur="if (this.value == '') {
this.className='hint-on';
this.value='First Name';
}"
onfocus="if (this.value == 'First Name') {
this.className='hint-off';
this.value='';
}" />
Of course, there are many ways to achieve this same effect using JavaScript. In HTML5, this same feature, called placeholder, can be achieved with a single line of code, as shown in the following code snippet:
<input type="text" placeholder="Last Name" />
The reason that this second version works is because the attribute placeholder was added to the browser, as well as the logic required to make it work. While this may seem like a nice little trick that the browser has learned, let's take a closer look at some of the main benefits this provides us with:
You, as the developer, have potentially hundreds fewer lines of code to write and test throughout the course of your entire project, since the browser exposes such a simple alternative
Development time decreases for two reasons: you have less code to write, and you have less code to test
Your code will be more portable and reliable, since you don't need to write specific implementations of your code logic for each browser, and you can trust that each browser will implement the feature properly (even if it takes a couple of updates for them to get there)
In other words, instead of putting a lot of your efforts into normalizing your code so it runs the same way in as many browsers as possible, or writing a lot of boilerplate code just to bring your application to the latest accepted standards, you can now invest the majority of your time building unique applications, since the repetitive code is abstracted away by the browser.
One last exciting point about this positive cycle of HTML5 that I'd like to point out is, how, since HTML5 is responsive to common use cases and real world needs, as time goes by we can only expect more and more really neat and useful features being added to the browser natively. Who can even imagine what new features the browser will support natively in the next few years?
As of this book, the following are some native features that modern browsers support (more detail about these features will be given in the following chapters, but this list should give you a good foretaste of what is to come).
You tell the browser the exact format that your want user input to be in, and the browser will enforce that format. Any invalid input provided (based on your settings), and the browser will even report back to the user, letting the user know what went wrong.
Collect data from the user in a variety of formats beyond text, lists, or checkboxes and radio buttons. For values within a given numerical range, you can use a slider input (also known as a range input). You can also take precise input related to dates, colors, telephone numbers, or e-mail addresses. All it takes to specify such restrictions in your input is a single HTML element attribute.
When browsing through text documents, the browser has always been very good at navigating from one document to the next. All it takes to tell the browser where to go next is an anchor tag. Now that smart phones make up nearly half of all Internet usage in some parts of the world, a hyper link can have a different context—such as telling your device to dial a number, for example. With HTML5 you can tell that same anchor tag to treat its link as a phone number to be called, similar to how you currently tell it to treat its resource as an email address.
Unless you have lived under a rock for the past five years or so, you will have heard of, and possibly used the most popular JavaScript library today—jQuery. One of the main reasons that jQuery has become so popular, and has gained such wide acceptance by web developers, is the revolutionary way in which it allows you to access DOM elements. Before jQuery, the three most common ways of accessing DOM elements were as follows:
document.getElementsByTagName()document.getElementsByClassName()document.getElementById()
Based on jQuery's solution to this limited way of accessing document nodes, you can now retrieve an element (or a collection of elements) from your document by specifying a CSS selector. Any or all nodes that match such CSS selectors are returned by the new selecting commands:
document.querySelector("css query goes here");document.querySelectorAll("css query goes here");
Text-to-speech is probably one of the most exciting and powerful features being added natively to the browser. While your user can simply type some input into an input field, and you can do with that text input what you wish, the browser now gives you the ability to take voice input from your user. Whatever the user literally tells the browser through a microphone, the browser will use its own text analysis algorithms, and give you the equivalent text transcription. By adding a single line of code to your application (and a web-based application, no less), you can now get that much closer to the type of interface only portrayed in movies (or offline, in desktop-based applications).
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:
<style>
p {
color: #cc0000;
font-size: 23px;
}
</style>
<p>Hello, World!</p>
<p style="color: #cc0000; font-size: 23px;">Hello, World!</p>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).
(file: /my-style sheet.css)
p {
color: #cc0000;
font-size: 23px;
}
(file: /index.html)
<!doctype html>
<html>
<head>
<link rel="style sheet" href="my-style sheet.css" />
(...)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 |
|
|
Mozilla Firefox |
|
|
Microsoft Internet Explorer |
|
|
Opera |
|
|
Safari |
|
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 |
|---|---|
|
|
This specifies how much to round each corner or a box |
|
|
This specifies an image to render over the border of a box |
|
|
This specifies the direction and size of a drop shadow relative to a box |
|
|
This specifies the size of a background image |
|
|
This specifies the offset position of background images |
|
|
This specifies how much to draw a background image |
|
|
This specifies various aspects of animation, such as keyframes, timing, effect, and so on |
|
|
This specifies various types of 2D and 3D transformations |
|
|
This specifies how two attributes should transition from one to the other |
|
|
This specifies the direction and size of a drop shadow relative to text |
|
|
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 |
|---|---|
|
|
It selects an |
|
|
It selects an |
|
|
It selects an |
|
|
It selects an |
|
|
It selects the Nth |
|
|
It selects the Nth |
|
|
It selects the Nth |
|
|
It selects the Nth |
|
|
It selects the last |
|
|
It selects the first |
|
|
It selects the last |
|
|
It selects an |
|
|
It selects an |
|
|
It selects an |
|
|
It selects an |
|
|
It selects an |
|
|
It selects an |
|
|
It selects an |
|
|
It selects an |
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:
div { background: RGBA(255, 255, 255, 0.5);This CSS rule specifies a completely white background, with an opacity of 50 percent (half transparent) represented by the decimal fraction:
div { background: RGBA(100%, 100%, 100%, 50%);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.
div { background: HSL(359, 100%, 50%);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:
div { background: HSLA(359, 100%, 50%, 50%);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.
@media (orientation: portrait) {
body {
background: RGB(100%, 0%, 0%);
}
}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.
Note
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.
@media (max-width: 240px) {
body {
background: RGB(100%, 100%, 100%);
}
}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.
@media (min-width: 800px) and (max-width: 1200px), (min-height: 5000px) {
body {
background: RGB(0%, 100%, 0%);
}
}As a last example for now, we tell the browser to check for a few different conditions in the previous code snippet. If at least one of the conditions evaluates to true, then the CSS rules inside that media query block will be made available to the page. This can be very helpful when reusing rules for different conditions, or when simply creating different rules to be applied in different situations. In this particular case, we set the background color of the body tag to a bright green whenever one of two (or both) conditions are true: the window is at least 5000 pixels tall, or the window's width is between 800 pixels and 1200 pixels (both values inclusive).
As stated earlier, when HTML was created, it was not meant to be used for the development of large enterprise applications. When JavaScript was first created back in 1995, its main goal was to provide a simple scripting language that would allow web designers to add some logic to their web pages. This too was not meant to be a foundation tool from which large, complex applications would be developed.
However, as we have seen with HTML itself, as well as CSS, JavaScript has become very widely used, and developers have outgrown its limited capabilities. Seeing the direction in which developers were taking the language, in an attempt to leverage the Web as a platform, browser vendors started to make improvements to JavaScript as much as was in their power. As a result, very powerful JavaScript engines have emerged. So, as JavaScript become even more used, and as browser became even more powerful, a new set of additions has been added to JavaScript.
Today JavaScript is the most popular scripting language used on the Web. Given its capabilities and the latest tooling available for it, JavaScript has become a very good option for the development of large applications, especially for games. The latest JavaScript APIs allow for 2D and 3D graphics rendering, thread-like behavior, sockets, embedded databases, and a whole lot more. Best of all, this new functionality is built with security in mind, and is not only available on desktop computers, but can also be used in most devices connected to the World Wide Web.
While the following is not a comprehensive list of all the new and upcoming APIs and language features, it does cover the most significant, stable additions to JavaScript, especially ones that we can leverage for game development. A more detailed explanation of each of the APIs listed in the following list, as well as usage examples, are available in subsequent chapters:
Note
There was another persistence API in HTML5 that was known as WebSQL. The spec for this API defined an asynchronous way to store and query data in the client using an actual built-in SQL-based database engine. The specification has been deprecated, and was replaced in its entirety by the more robust and more accepted IndexedDB API.
One of the most exciting things about HTML5 is that it is the main language of the World Wide Web. In other words, just about any device connected to the Web is able to run any games or applications you write in it. That makes the Web a very unique platform.
Doubtlessly, you have heard about or experienced such things as "the console war", where different video game console manufactures fight to win a larger percentage of the market over their competitors. While some people own more than one video game console, the majority of gamers own only one system. So what that means for a game developer is that, in order for their games to sell well, or in other words, in order for their games to be played and enjoyed by the largest possible amount of players, they need to develop the same version of a game for multiple platforms. This is an expensive and very time consuming process. Creating one game is already expensive and time consuming, let alone duplicating all that work for one or two other platforms.
Today, with more and more users world wide using the Internet, you don't have to go through what console video game developers do. As long as your game runs properly in a standard, modern web browser, it will run the same in just about any other browser across the world. In other words, your same code base can be enjoyed by over a billion people because they all run browsers that conform to HTML5. This makes the Web the largest, and greatest platform of all time. And the best part about it—it's totally free to develop for it. You don't need to have a special license or pay royalties to anyone in order to develop games or other applications for the Web.
As we mentioned earlier in the chapter, there are many buzz words in circulation today, whose meaning is unclear at best. Depending on who is telling you about the future of the human race, the specific definition of the term Open Web may vary.
Most commonly, the term Open Web refers not to a collection of technologies, but rather to a philosophy, if you will. The word open is meant in the sense that the Web is not closed up to a select few, or restricted by someone, or to a certain purpose. The World Wide Web is designed to be a place where all are welcome to come, create, innovate, consume, and enjoy. There is no centralized governing body over the Web. In reality, everybody owns the Web, especially in the sense that without the millions of individual servers and files, the Web would not be what it is.
You may be asking yourself what this all has to do with HTML or HTML5, or what is it in for you. Simply put, everything. Really. The reason the Open Web is such an exciting thing (and such a success so far) is because for the most part, everybody is on equal ground there. While there are dozens of different server-side languages and technologies, the part of the application that users interact with is written in three basic technologies, namely HTML, CSS, and JavaScript. The reason that now is such an exciting time to be a part of the Open Web, and the reason that you should consider yourself lucky to be able to be a part of it, is that these technologies are ripening and getting more mature.
HTML5 is built for the Open Web. It has enough power to leverage the distributed paradigm of the Web, and allows you, whether you're an independent developer or a member of a very large corporation with hundreds of other programmers, to create a desktop-like experience right on a browser, instantly reaching hundreds of millions of people world wide, all the time.
Back when the World Wide Web was first introduced, its founders had one thing in mind—information exchange. Later, HTML was developed, with the goal of describing text documents. Again, the main aim was to aid the exchange and distribution of text documents.
Although HTML5 is fully backwards compatible, and still provides a terrific paradigm for information distribution, it is also designed with applications in mind. Today the Web is no longer used only for information exchange. People are now using the Web as a means to find entertainment—to watch movies, listen to the radio, and especially to play complete, full-featured video games.
HTML5 is a game changer in at least three ways, namely its wide adoption, its powerful capabilities, and the fact that it brings its features right to the browser—no plug-ins required. These three ways are explained as follows:
Wide adoption: Not only are there over a billion people using the World Wide Web, but just about any device connected to it is able to execute HTML5 code. That means your program HTML5 games to be played on desktop computers, laptops, smart mobile phones, tablets, and even television sets.
Powerful capabilities: Before HTML5, many commonly used tasks and features had to be programmed every time by developers—the drag-and-drop functionality, form validation, custom font faces, and so on. With HTML5, all of those things (and much more) are done for you by the web browser. You no longer need tens or hundreds of lines of code to create a drag-and-drop effect. The browser makes that job trivial for you, the developer.
No plug-ins: While many of the features that HTML5 bring to the table had already bee seen before by means of third-party software, such as Macromedia Flash (which was later acquired by Adobe), or Java applets. The challenge with using these technologies as part of your web applications was that users had to install (and frequently upgrade) plug-ins that extended the browser's native capabilities. No only that, but developers also needed to learn and maintain at least two separate code bases, written in different languages. HTML5 solves that problem by cooking its own powerful feature set, allowing users to have a similar, and often better experience with the software, and best of all, without installing or worrying about a single plug-in.
In summary, the Web has gone from being a place to exchange information, to a place where users go to find quality entertainment. Responsive to this change, HTML5 has been designed to empower you to create the entertainment that users are looking for on the Web, in the form of fun video games.
In this book we will learn all about HTML5. We'll learn what each feature is meant to do and how you can use them. More than that, however, we want to make this teaching process fun, simple, and memorable. Thus, our approach might be somewhat different than most other books.
If you pay close attention to the way most teachers and authors teach new concepts, you will notice the following pattern: first the topic is explained, then, in an attempt to solidify the student's understanding of the material just covered, an example is given in order to show how the subject may be applied. The problem is that often this example is neither useful nor usable. For example, in computer programming books, you will see a common theme describing animals, food, or other abstract concepts that do not lend themselves well in real-world application. Thus, the student may become frustrated by the lack of real-world applications.
The key to effective learning, then, is a good example or use cases where the student may apply the newly acquired information. This way, when the student finds himself or herself in a real-world situation when their new skill could indeed be applied, they may readily recognize the opportunity and use the knowledge just gained. Furthermore, if the learning process is too abstract and theoretical, the student tends to get distracted or even bored. If the teaching process is involving and fun, on the other hand, the student is more likely to remember the concepts, but better yet, he or she is more likely to understand what is being taught.
Our approach in this book will be slightly different than what you might be accustomed to, in that we will focus most of our efforts not in listing as much theoretical information as we can about HTML5 and all that it involves, but rather in illustrating each topic through a fun game.
Why teach HTML5 through game development, you ask? There are many reasons for this. For starters, games are fun. Game development, although some of your friends might disagree, is also fun and very rewarding. Also, it just so happens that most of the features of HTML5 lend themselves so well to game development, that teaching HTML5 and not making the application for games is also rude. Finally, games are so fun, that learning a new programming technology through game development will provide the learner with both a very exciting set of examples to show each concept in action, and also a powerful physical product as the outcome of the learning process.
Our goal in this book is not, however, to teach you how to develop video games. What we're setting out to do is to teach you HTML5 first and foremost. If you already know game development, and have some experience in this arena, you will not only learn the latest and greatest features of HTML5, but also learn how they can be applied directly to designing and programming video games. If you're not a very experienced game developer, or haven't done any game development at all as a matter of fact, do not fear! You will still learn some techniques of game development, since we'll walk you through the concepts involved, but keep in mind that the focus of the book is HTML5.
The games we will be writing in the book will be fun, complete, and easy to extend. We will be building each game in layers, so that adding more capabilities or refactoring parts of it will be simple enough. At the end of each chapter you will have your own HTML5 game, which because of the Open Web, you will be able to share with all your friends with access to the Internet, as well as with hundreds of millions of people world wide.
Finally, since HTML is nothing more than text markup, and JavaScript is a dynamic, interpreted language, we will not be needing expensive or complex tools in order to develop our games. If you have a text editor program in your computer, and a modern web browser such as Google Chrome, Mozilla Firefox, Opera, Safari, or the latest Internet Explorer, then you are good to go. You will also need one type or another of a web server, which we'll go into more details about in the next chapter.
Thanks to the nature of the Open Web and HTML5, it doesn't matter one bit what kind of computer system you have. Whatever HTML5 code you write on your particular system will run just the same on somebody else's different computer. Best yet, there will be no installations required, which further lowers any barriers that could keep your games from being enjoyed by hundreds of millions of people world wide.
In this chapter we took a look at what HTML is, where it came from, and where it's headed. We discussed how the Open Web is a place where anyone with at least some knowledge of the technologies that make it work, and a lot of ambition (or enough curiosity) can reach an unprecedented audience at a virtually non-existent cost.
Although HTML5 is an upgrade of previous versions of HTML, the term also makes reference to the upgrade of other technologies that go hand in hand with the markup language, such as CSS and JavaScript. All three of these languages have been upgraded in response to current needs, and in order to take the Web to the next level. Many of the new features added to the languages attempt to shift the hard work of implementing commonly used functionality from the developer to the browser. What was once done by many developers through arduous, time consuming, and often expensive work, can now be done by the browser with minimal effort by the programmer. Also, many of the new features and capabilities of HTML5 make the web platform a very aggressive opponent to the desktop paradigm. The idea of individual desktop computers running in complete isolation from each other, each running program from its own central storage system is steadily going away. The replacement is a cloud-based paradigm, where the software in question is sent to each user from one central server connected to the Web. And since these web applications are executed in the users' browser, some of the major parts of the application are written in pure HTML5.
HTML5 is the perfect technology to master right now because it is at the core of the Open Web. Thanks to the responsive and evolving nature of HTML5, we can only wait to see what the future has in store for us, as browsers continue to get more powerful, and the cost of computing continues to decline.
We will explore the exciting world of HTML5, and cover its major concepts and building blocks by designing and developing fun and engaging games. We're taking this approach not only because games are fun, but also because many of the new capabilities in HTML5 lend themselves so well to the complex problems of programming video games. Also, by successfully programming full games in pure HTML5 technology, we will be able to test and prove the true capacity of HTML5 and the Open Web.
In the next chapter we will take the first step towards building awesome web-based games. First we'll set up a development environment by installing a web server. Next we will build an HTML5 web portal from which we can access our games, as well as get a bit of practice using the new semantic elements.
