All Flash developers generally have the same issues when transitioning to HTML5 development. Most of these problems arise from differences between platform syntax, as well as dealing with the interaction between each element within the HTML5 stack.
The first and most obvious change when moving to HTML5 development is the lack of the ever important Flash Stage. Dealing with element layout, asset animations, and interactivity with HTML5 is all taken care of purely with code. Although there are many web development IDEs with drag-and-drop type interfaces, to better understand how to build cleaner web pages, this book will cover all examples with hand written code examples.
One of the biggest initial issues many Flash developers have when moving into web development is the concept of positioning content and assets within the DOM. Unless specified, HTML elements are not simply placed in DOM with X and Y position values. Since elements within an HTML document are displayed inline by default, global X and Y position values are irrelevant. When positing an element within DOM with CSS, properties such as margin, padding, top, left, right, and bottom are used instead. As mentioned, if elements are specially styled with a position of absolute or utilized within a canvas element then X and Y values can be used. On top of the issues regarding simply controlling where elements are placed within your project, there is the ordeal of making sure that all of the web browsers that may view your content display it as per your specification.
Media optimization is the key to delivering content over the Web. When working with Flash, many of the assets used are vector-based and therefore lightweight on the compiled SWF file size. Bitmap data used within the Flash SWF is compressed during compilation, therefore automatically aiding you by minimizing file size. Since what the majority of HTML documents do is reference raw files publicly accessible on the Web, each asset used should be optimized for minimal file size while keeping the intended quality as close to original as possible. As we cover different aspects of HTML5 development throughout the chapters of this book, many optimization methods will be covered for the different types of media used in web pages.
Publishing content in Adobe Flash outputs a compiled binary SWF file, which is ready to be played in a compatible Flash Player. The code and assets used in the application are protected from prying eyes since the application was compiled into a single binary file. But when dealing with code and assets on the Web, the entire game changes. Pretty much everything you create and deliver in an HTML5 project, as with any website, is open for public viewing.
Code obfuscation is a practice some developers use while delivering production level client-side code. Many websites and applications are available to obfuscate your JavaScript code by rewriting the code in a hard to read, compressed format. Although this is not a foolproof way of securing code, it adds a level of deterrence when it comes to users poking around a document's source code.
Understanding client-side code usage and limitations is the key to writing secure JavaScript applications. Sensitive information should never be hardcoded into a document which can be viewed on client side. Chapter 2, Preparing for the Battle, covers the usage of client-side script in a more in-depth manner in comparison to ActionScript 3.
One of the major changes in development paradigm when moving from Flash to HTML5 development is the need to target multiple platforms with the same code base. While developing an application using Adobe Flash, you initially set a target version of the Flash Player for your application to run within. By compiling your application into a packaged SWF, the Flash runtime will have no issues rendering your application in any compatible Flash Player. Since every browser and platform tends to display web content a little bit differently, when developing HTML5 content and applications, one must take note of the platforms and browsers that may be used to view the content to better optimize the viewing experience.
Browser functionality checks can be written into JavaScript conditions to enable users with browsers that lack the support for specific HTML5 features to still view your HTML5 content. For instance, if a user visits a page with an HTML5 video playback element within it, without the support for it within his browser, JavaScript could alternatively embed a Flash video playback application instead.
Tip
Finding a modern web browser that doesn't support HTML5 is getting harder day by day. When it comes to choosing a browser to test code in while reading this book, Firefox (http://www.getfirefox.net/), Chrome (http://www.google.com/chrome), Safari (http://www.apple.com/safari/), and Opera (http://www.opera.com/) are all great choices and available online for free.
Within the chapters of this book, many of these popular web browsers will be utilized to show how content may sometimes differ in look and usage. Due to the speed at which browser updates and changes are released, testing your site as much as possible in every browser on every platform is a very important aspect of web development. Many of these web browsers now have built-in development and debugging tools, which allow for easier optimizations of your HTML5 projects. Other applications and services are also available to ease the pain of browser testing, some of which will be used and covered in this book.