can new web technologies html5 & css3 kill flash? dissertation by jeremie charlet, 12/2010

CAN NEW WEB TECHNOLOGIES HTML5 AND CSS3

KILL FLASH?

MSc Computer Science

Dissertation

Jérémie Charlet

[email protected]

A thesis submitted in partial fulfilment of the requirements of

Staffordshire University for the degree of Master of Science

December 2010

Supervised by Alastair Dawes

MSc Dissertation - Jérémie Charlet – CW002436 0

Abstract

This dissertation investigates the new web technologies Hypertext Mark-up Language 5 (HTML5) and Cascading Style Sheet 3 (CSS3) that are still in development and aims at establishing whether they are able to replace Adobe Flash.

The objectives are first to investigate what are the graphic capabilities of the three mentioned technologies. Then it is intended to learn and practice them to finally implement identical animations in HTML5, CSS3 and Flash and compare their performances. From that study a set of guidelines sets what technical solutions are best to be used.

The research first concentrates on the HTML5 and CSS3 technologies, then on Flash. On both of them, their availability is determined; many samples of web applications or websites are organized in a set of categories and are analysed; and their strengths are presented. A concluding chapter to this research compares HTML5, CSS3 and Flash and states, according to the literature, what are their potential future and impact.

The artefact consists of an HTML5 and CSS3 website and of two sets of animations built in HTML5, CSS3 and Flash. The website was created to learn and practice the technologies covered while the animations served the benchmarking stages.

The first set of implementation and benchmarking involved a simple animation of a solar system involving two planets; the second set involved an enhanced version of this animation with forty planets to push the rendering engines of the web browsers to their limits. The aim was to define whether those animations were quick to load, their rendering smooth and their processing low consuming to save battery life of mobile devices; hence they were benchmarked on their load time, their frame rate and their Memory and Central Processing Unit (CPU) usages.

The study shows that HTML5 and CSS3 are at the moment not mature enough to be globally used in businesses but still have the potential to replace Flash in animation, video and web applications that do not involve high interactivity in a very close future. The solution shows that animations can already be made in HTML5 and CSS3; however the testing confirms the current superiority of Flash in terms of performances.


1 INTRODUCTION CHAPTER ....................................................................................................4 1.1 AIMS AND OBJECTIVES...........................................................................................................................4 1.1.1 Aims .....................................................................................................................................................4 1.1.2 Objectives ..........................................................................................................................................4

1.2 RESEARCH APPROACH ...........................................................................................................................5 1.2.1 Planned research Approach......................................................................................................5 1.2.2 Differences with the planned schedule.................................................................................8

1.3 INTELLECTUAL CHALLENGE .................................................................................................................9 1.4 PRESENTATION OF THE FOLLOWING CHAPTERS ...............................................................................9

2 LITERATURE REVIEW CHAPTER...................................................................................... 10 2.1 PRESENTATION OF CONFERENCE VIDEOS........................................................................................10 2.1.1 “Features you want desperately but still can’t use” .................................................... 10 2.1.2 “Google’s HTML 5 Work: What’s next?”............................................................................ 10 2.1.3 “The future of HTML 5”............................................................................................................ 11

2.2 OVERVIEW OF THE NEW FEATURES..................................................................................................12 2.2.1 New elements ............................................................................................................................... 12 2.2.2 Multimedia .................................................................................................................................... 13 2.2.3 Browser Storage and others offline applications support........................................ 15 2.2.4 Features to build better web applications....................................................................... 15 2.2.5 Forms and text editing ............................................................................................................. 16 2.2.6 Other gadgets............................................................................................................................... 16

3 RESEARCH ON HTML 5 & CSS3 .......................................................................................... 17 3.1 HTML5 & CSS3 AVAILABILITY .......................................................................................................17 3.1.1 HTML5 & CSS3 are conquering the Desktop and the mobile Web........................ 17 3.1.2 Availability on computers....................................................................................................... 18 3.1.3 Availability on mobile phones............................................................................................... 21

3.2 WHAT IS HTML5 & CSS3 USED FOR (AT THE MOMENT OF THIS WRITING)?.........................25 3.2.1 Integrated Music & Video ....................................................................................................... 25 3.2.2 Cartoons ......................................................................................................................................... 27 3.2.3 Games .............................................................................................................................................. 29 3.2.4 Web applications ........................................................................................................................ 32

3.3 STRENGTHS OF HTML5 AND CSS3.................................................................................................35 3.3.1 Cross platform technology...................................................................................................... 35 3.3.2 Saved bandwidth: vital for the mobile web..................................................................... 35 3.3.3 Rich media without plug-‐ins.................................................................................................. 35 3.3.4 RIA features................................................................................................................................... 35

4 RESEARCH ON FLASH ........................................................................................................... 36 4.1 FLASH AVAILABILITY ON COMPUTERS ............................................................................................36 4.2 FLASH AVAILABILITY ON MOBILE PHONES.....................................................................................37 4.3 WHAT IS FLASH USED FOR? ...............................................................................................................38 4.3.1 Integrated Music & Video ....................................................................................................... 38 4.3.2 Cartoons ......................................................................................................................................... 40 4.3.3 Games .............................................................................................................................................. 42 4.3.4 Advertisements ............................................................................................................................ 44 4.3.5 Custom Navigation / Full Flash Website.......................................................................... 44

4.4 IMPACT OF FLASH ON THE WEB .......................................................................................................48 4.4.1 Origins of Flash and its evolution........................................................................................ 48 4.4.2 Strengths of Flash....................................................................................................................... 48 4.4.3 A big contributor to the web ................................................................................................. 49

5 HTML5, CSS3 AND FLASH. COMPARISON AND POTENTIAL IMPACT.................... 51


5.1 COMPARISON OF HTML5, CSS3 AND FLASH ................................................................................51 5.1.1 Availability .................................................................................................................................... 51 5.1.2 Integrated Music and Video................................................................................................... 52 5.1.3 2D Animation ............................................................................................................................... 52 5.1.4 Games .............................................................................................................................................. 52 5.1.5 Advertisements ............................................................................................................................ 53 5.1.6 Web Applications........................................................................................................................ 53

5.2 POTENTIAL IMPACT ............................................................................................................................53 5.2.1 Shift from the ubiquitous platform Flash to the new web standards.................. 53 5.2.2 The future of HTML5, CSS3 and Flash ............................................................................... 54 5.2.3 A debate driven by interests of giants ............................................................................... 55

6 PRELIMINARIES TO IMPLEMENTATION AND BENCHMARKS ................................. 57 6.1 EXPERIMENTS WEBSITE AND LEARNING .........................................................................................57 6.1.1 Experiments.jcharlet.com: an HTML5 and CSS3 website.......................................... 58 6.1.2 Tutorials on HTML5 Canvas .................................................................................................. 61 6.1.3 Tutorials on CSS3 ....................................................................................................................... 66 6.1.4 Tutorials on Flash ...................................................................................................................... 69 6.1.5 Creation of a common animation: solar system ........................................................... 69

6.2 INTRODUCTION TO BENCHMARKS.....................................................................................................70 6.2.1 Guidelines to ensure that benchmarking of a website are done in the best conditions ...................................................................................................................................................... 70 6.2.2 Where to do the benchmarking: on the most popular platforms.......................... 70 6.2.3 What to benchmark................................................................................................................... 71

7 IMPLEMENTATION & BENCHMARKS 1........................................................................... 72 7.1 IMPLEMENTATION: SOLAR SYSTEM .................................................................................................72 7.1.1 Profile .............................................................................................................................................. 72 7.1.2 HTML 5 Canvas’s Implementation ...................................................................................... 73 7.1.3 CSS3’s Implementation ............................................................................................................ 73 7.1.4 Flash’s Implementation ........................................................................................................... 74

7.2 BENCHMARKING ENVIRONMENT AND PROCESS ............................................................................75 7.2.1 Browsers and Tools ................................................................................................................... 75 7.2.2 Process............................................................................................................................................. 75 7.2.3 Updates and quick findings while benchmarking ........................................................ 76

7.3 BENCHMARKS AND FINDINGS............................................................................................................76 7.3.1 Loading Process and GET Requests handling ................................................................ 76 7.3.2 Randomness of results.............................................................................................................. 77 7.3.3 Tendencies observed despite the inequality of animations...................................... 78 7.3.4 These first benchmarks involved simplistic animations............................................ 79 7.3.5 Next Benchmarks........................................................................................................................ 79

8 IMPLEMENTATION AND BENCHMARKS 2 ..................................................................... 80 8.1 OBJECT: ENHANCED SOLAR SYSTEM ................................................................................................80 8.1.1 What is new in this second set of animations? .............................................................. 80 8.1.2 HTML 5 Canvas’s Implementation ...................................................................................... 81 8.1.3 CSS3’s Implementations .......................................................................................................... 82 8.1.4 FLASH’s Implementation......................................................................................................... 83

8.2 BENCHMARKING ENVIRONMENT AND PROCESS ............................................................................84 8.2.1 Process............................................................................................................................................. 84 8.2.2 Browsers and Tools ................................................................................................................... 84 8.2.3 quick findings while benchmarking ................................................................................... 86

8.3 BENCHMARKS AND FINDINGS............................................................................................................86 8.3.1 Load Time: several findings ................................................................................................... 86 8.3.2 Frame Rate: Flash largely wins but there is hope for Canvas................................. 87


8.3.3 CPU Usage: as above, Flash wins and Canvas needs to get improved ................. 88 8.3.4 Memory Usage ............................................................................................................................. 88 8.3.5 Unsuitable CSS3 design on animation............................................................................... 92

9 CONCLUSION ........................................................................................................................... 94 9.1 SUMMARY OF THE FINDINGS..............................................................................................................94 9.1.1 Research on HTML5, CSS3 and Flash................................................................................. 94 9.1.2 Implementation........................................................................................................................... 94 9.1.3 Benchmarks .................................................................................................................................. 95

9.2 GUIDELINES FOR DEVELOPERS ..........................................................................................................96 9.2.1 Start using HTML5 and CSS3 ................................................................................................ 96 9.2.2 Use HTML5 and CSS3 for simple HTML/CSS websites ............................................... 96 9.2.3 Carry on using Flash for animation, video, high interactivity and RIA .............. 96 9.2.4 Check HTML5 and CSS3 evolution ...................................................................................... 96

9.3 THE FUTURE OF HTML5, CSS3 AND FLASH IN FIVE YEARS TIME .............................................97 9.4 EVALUATION OF THIS STUDY .............................................................................................................97 9.4.1 Weaknesses of this work.......................................................................................................... 97 9.4.2 Strengths ........................................................................................................................................ 98 9.4.3 Difficulties of this dissertation subject .............................................................................. 98 9.4.4 Personal learning (answer to Introduction’s Intellectual Challenge)................. 99

10 BIBLIOGRAPHY ................................................................. ERREUR ! SIGNET NON DÉFINI. 11 THANKS ............................................................................... ERREUR ! SIGNET NON DÉFINI. 12 APPENDIXES....................................................................... ERREUR ! SIGNET NON DÉFINI. 12.1 APPENDIXES OF RESEARCH ON HTML5 AND CSS3.................ERREUR ! SIGNET NON DÉFINI. 12.1.1 HTML5 and CSS3 Availability: Complete HTML5 & CSS3 Availability tables (Deep Blue Sky, 2010) ..........................................................................Erreur ! Signet non défini. 12.1.2 Cartoons: CSS3 SPIDERMAN Code ..................................Erreur ! Signet non défini. 12.1.3 Games: 3D Samples................................................................Erreur ! Signet non défini. 12.1.4 Web Applications....................................................................Erreur ! Signet non défini.

12.2 APPENDIX OF RESEARCH ON FLASH.............................................ERREUR ! SIGNET NON DÉFINI. 12.2.1 What is Flash used for: Full-‐flash website samples .Erreur ! Signet non défini.

12.3 APPENDIX OF PRELIMINARIES TO IMPLEMENTATION AND BENCHMARKSERREUR ! SIGNET NON DÉFINI. 12.3.1 Canvas graphic API................................................................Erreur ! Signet non défini. 12.3.2 SYSTEM.......................................................................................Erreur ! Signet non défini. 12.3.3 DRAWING SHAPES.................................................................Erreur ! Signet non défini. 12.3.4 APPLYING STYLES & COLORS...........................................Erreur ! Signet non défini. 12.3.5 PATTERNS .................................................................................Erreur ! Signet non défini. 12.3.6 USING IMAGES.........................................................................Erreur ! Signet non défini. 12.3.7 TEXT.............................................................................................Erreur ! Signet non défini. 12.3.8 ANIMATION ..............................................................................Erreur ! Signet non défini.


1 Introduction chapter 1.1 Aims and Objectives

1.1.1 Aims

Figure out whether the new web technologies: Hyper Text Markup Language 5 (HTML5) and Cascading Style Sheet 3 (CSS3) may totally replace Flash, and if not define a set of guidelines to indicate in which condition why one should be picked instead of the other.

1.1.2 Objectives

1. know what could be done in 2D graphic animations with HTML 5, CSS3 and Flash

o Research on HTML 5 § get a quick overview of the new features § write literature review on HTML 5 new features

o Research on HTML 5 Canvas and CSS3 graphic capabilities § Write a table displaying the Availability of HMTL5 and CSS3

graphic features in the different main browsers (Chrome, Opera, Safari, Firefox, Internet Explorer)

§ Search for Canvas and CSS3 demos and look at the code § List existing Canvas Graphic libraries. Study their

availability in different browsers o Research on Flash

§ Search for different sorts of demonstrations § Explain how Flash became a leader on the web

o Write reports on the research on HTML 5, CSS3 and Flash and compare them

2. know when to use HTML 5 or CSS3 instead of Flash o Learn and practice HTML5 and CSS3 o Learn Adobe Flash using Adobe Learning centre (Adobe 2009)

§ Learn the basics by doing some of the “getting started” tutorials of the adobe flash developer centre (I have already done some tutorials in the module Web Multimedia)

§ Practice the tutorials on Action Script § Practice the tutorials on Animation § Practice the advanced tutorials on video, graphic effects and

components (they should be very useful for the development)

o Design a set of animations to implement in HTML 5, CSS3 and Flash and to test

§ Research and List the different kinds of animations which could designed for the web


§ Select animations from the above list and develop for each a sample in Flash and another in HTML 5

§ Test the animations in both versions and analyse their performances

o Conclude on the analysis performed and write a set of guidelines for developers to advice them on what technology to use in different cases

At first, when the proposal was written for the Personal Development and Research Methods module, only HTML5 was taken into account; however CSS3 presenting also graphic capabilities was also integrated to the research.

Finally, only one animation was created in the three technologies and tested.

1.2 Research Approach

1.2.1 Planned research Approach

Here is presented the research approach as it was stated in the proposal (at the start of the dissertation).

1.2.1.1 Research on HTML 5 Canvas First the literature review will give an overview of the features of HTML 5: since half of the implementation will be made in HTML 5, it is a must to know about this language.

(Deliverable :) Literature Review

Then begins the proper research on Canvas. The Specifications draft of HTML 5 (W3C 2009) will be a start point and is a display of all the methods available to draw graphics in JavaScript.

The Canvas API has not been implemented yet in every browser. In 6 months, when the research project will start, progress would have been made, and it could even evolve during the 24 weeks research. Hence to keep up to date the knowledge of the advancement of each feature in every browser is a must. Developers shall not be advised to start using methods which are not still implemented and available to every one.

Showcase websites (Sharp 2009) (Deutsch 2009) are emerging and display different sort of animation developed directly with the native canvas JavaScript code. To look at these animations and their codes will help to become aware of what can be done with the canvas and to start learning how to use it.

Groups of developers started to implement JavaScript libraries to allow other developers to create specific animations by writing much simpler code. Use of their work might help saving time but it needs to be checked to insure that there is no compatibility issue.

While pursuing on this research, the outcomes will be included in a report on Canvas so that this report will be the reference on HTML 5’s canvas for the rest of the project.


HTML 5 Canvas Report

1.2.1.2 Learn Flash 3 to 4 weeks

The flash section of the developer centre from adobe website is a rich portal of resources and tutorials on flash (Adobe 2009).

Since I have only been introduced to it in the Web Multimedia tutorial, I will need to spend time learning about Action Script and Animation and learn what is needed about the most advanced subjects on Video, graphic effects and components.

To conclude this learning, a complex animation in Flash will be developed as a showcase including action script, animation, video, etc.

Flash Prototype

1.2.1.3 Research and Design of the 10 animations and their analysis 3 weeks

This stage will affect the next two stages; in this stage there will be designed the process to answer the research question, and there are two possible ways which will be defined later.

Whatever path is chosen, research must be made about the different cases where animation and/or interactivity is/are used in Web: Flash is not only used to create cartoon animation but also to create interactive menus, galleries, games, animated web-designs, etc. However, the progress of implementation of HTML 5 needs to be taken into account: for instance, the handling of events is quite blurred in HTML 5, so if nothing comes out on this subject (but it SHOULD), the scope will be reduced.

After this research, 10 different and popular kinds of animation will be chosen and specifications will be written for each.

10 animations Specifications

Afterwards a choice will need to be made:

• Either I only decide at this stage what animations to implement and then, after having implemented the 10 chosen ones, design and analysis will be done

• Or I design here the implementation and the analysis so that once an animation has been developed in both technologies, performances are tested and animations’ codes are improved if needed. This would help to make sure that things are well done, right from the start. But on the other hand, time could be wasted trying to improve the code.

I will discuss on this issue in time with my supervisor.

1.2.1.4 Implementation Flash/html5 7 weeks


In this stage comes the development of the chosen 10 animations in both technologies: HTML 5’s canvas with JavaScript and Flash with action script

Website including the 10 animations and their code

1.2.1.5 Testing and Benchmarks 2 to 3 weeks

In this stage comes the analysis to evaluate each animation and their performances in both technologies.

Many criteria will be considered, such as the download time, the ratio size/quality of the files, the proper display on the different browsers, etc. The factors to study will be defined in the designing stage.

Analysis Process & Results

1.2.1.6 Evaluation and Conclusions 2 weeks

To conclude the research, a set of guidelines for developers will be written using the results of the benchmarks.

It will explain in which cases they should design their animations with HTML 5, and in which cases they should keep to Flash.

Beyond this advice, these guidelines should recommend that developers start working with HTML 5 by:

• making them aware of what they are able to create for instance with HTML 5

• Saving their time: they will not risk to start developing an animation that could end in a failure because of incompatibility, because of bad performances or even because some tools/methods are still missing and need to be implemented.

More than a set of guidelines for initiated developers, this could be well introduced by explaining some basic concepts of HTML 5 and promoting the advantages of choosing an open standard solution. It could be a way to persuade developers to join in the community working on HTML 5, use it, promote it, and help it to progress.

Guidelines Report

Remaining time spent on improving and re-improving


Figure 1 - Gantt Chart

1.2.2 Differences with the planned schedule

Finally as stated in “Aims and Objectives”, a new technology, CSS3, was taken into account and integrated to the research. The differences related to each part are described below.

1.2.2.1 Research It was planned to make a research report on HTML5 (and CSS3); a similar report was also written on Flash to identify the graphic capabilities of each technology and make a comparison afterwards.

1.2.2.2 Learning The HTML5 and CSS3 technologies required also to be learned. So a website gathering the work done on HTML5 and CSS3 was created. Since the learning on Flash was quick and only done to get back used to it, only the final animation created in Flash and used in the testing part was published.

1.2.2.3 Implementation and Testing Only one animation was in the end implemented in all three technologies and tested.

Creating ten animations was a too ambitious task for a 6-months project.

HTML5 and CSS3 offer features to draw and animate graphics on the web. However the new web technologies investigated do not include new specific APIs to manage interactivity in particular so only animation was looked at. Besides, since a unique animation had already been developed in all three technologies in the learning part and was suitable for the next parts, this animation was kept and removed the need to design the animations to test.

However the first animation was after a first set of benchmarks enhanced and re-tested to push the web browsers rendering it to their limits.


1.3 Intellectual Challenge This work is my first personal research and is similar to my previous internship in Web Developments: I will need to get some implementation skills. However I will have more responsibilities and autonomy than I used to since I must organise my own learning and manage my work.

Project planning is one of my weaknesses because I struggle to plan on mid or long term and I am also used to putting off work until the last minute. Hence I will define clearly deliverables at the end of each stage to make sure that my advance is regular.

Collecting valuable resources on a new technology is complicated. For example, I found no research paper on the HTML 5’s canvas.

As I said, I will have to organise my own learning in both HTML 5 and Flash.

HTML is an easy language and I have already developed websites but HTML 5 has a new syntax I must get used to. Besides there is no tool to draw graphics in canvas so I will have to learn coding graphics with JavaScript.

I have been introduced to Flash in the Web Multimedia Module but I am missing experience and I will practice many tutorials to create the artefact.

English is not my mother tongue. Writing is difficult because my grammar and my vocabulary are poor and I spend much time looking for words in dictionaries.

Finally, my last internship and this course semester proved me that Web Development was my vocation; the next step is to figure out whether I should go on studying in research or if I should start working right after this MSc; the way I handle this research project will answer it.

1.4 Presentation of the following chapters The literature review chapter globally introduces and presents HTML5. Two chapters of research look in depth on graphic capabilities of HTML5 and CSS3 on one hand, and of Flash on the other hand. A third chapter compares them and discusses their future. Preliminaries to implementation and Benchmarks show the practical learning and introduce the testing. Implementation and Benchmarks 1 and its continuation (2) both present the artefacts created and their analysis. Finally the conclusions summarize the findings and this work is evaluated.


2 Literature review chapter 2.1 Presentation of conference videos The overview will be made with these 3 conference videos:

• “Features you want desperately but still can’t use” was published in September 2008 and is presented by the editor of HTML 5, Ian Hickson, who is also a Google employee.

• “Google’s HTML 5 Work: What’s next?” took place at the Google I/O Developer Conference in May 2009 and was presented by Matthew Papakipos, director of HTML 5 Open Web Platform efforts at Google.

• “The future of HTML 5” took place at FOWA London in October 2009 and was presented by Bruce Lawson, an employee of Opera.

All of these have in common to present HTML 5 and its new features; but they explain different features and by different manners so that these videos supplement each other.

In this part, first, every video will be introduced by explaining what they are mainly about and how they are handled.

2.1.1 “Features you want desperately but still can’t use”

The presentation from Hickson only presents the features that were already working at this time. It looks like a prototype presentation for underground developers, his author discovered a few times that some features were not implemented in a particular browser, and he needed to debug his own samples he was coding in-live to make them work. But he goes straightly to the point, by developing html files in live, viewers see how it easy to develop with HTML 5. While the results are watched in different browsers, it can be figured out that browsers had implemented at this time only a few features and independently from the others.

The features Hickson presents in his samples are:

• video tag • local and session storage • drag and drop API • Form Controls • Canvas Some pieces of code and demos of Hickson will be displayed to give some concrete illustrations to the features presented.

2.1.2 “Google’s HTML 5 Work: What’s next?”

In the second presentation, first the speaker presents the new needs of web applications and declares than most of them are being becoming web standards: playing videos, giving access to webcam/microphone for video conferences, offering offline abilities, etc. He expresses then Google’s main goal: fill in the gap between native and web applications.


Web applications are still missing important capabilities like security and privacy but they have great advantages: no installation required and always updated.

It is actually not only Google’s goal, but the whole IT world’s goal: Google offered a web alternative to office (Google, 2009), adobe developed a web version of Photoshop (Adobe, 2009), and Microsoft joins the movement with its Microsoft Office Web Apps (Redmont, W 2009). Hence there is a war between heavyweights to get their products monopolize the World Wide Web and this a new area where Microsoft is not the certain winner in a competition which hopefully favors open standards, standardization, etc. HTML 5 offers the tools to open the competition, to provide less influent companies with means to create quickly efficient RIA.

After this introduction, Papakipos presents 9 features of HTML 5:

• Canvas • Local Storage • Workers • Application Cache • Video • Rich Text Editing • Notifications • Web Sockets • 3D APIs • A list of other future features

Some of them, like the Canvas, video and local storage, were already introduced by Hickson ; but progress was made in the 9 months between the 2 conferences so the speaker adds information without going in depth in the code like Hickson did. Actually most of the features presented answered Google’s will explained in the introduction: build more efficient web applications and therefore this conference is not intended to individual web developers but to companies, communities of professionals.

2.1.3 “The future of HTML 5”

Bruce Lawson goes further and not only presents some of the new features of HTML 5 but stressed on the importance of open web: HTML 5 is not just a new tool which allows to develop pretty websites or better RIA (Rich Internet Application), Lawson states HTML 5 as a new (free) challenger to Flash and Silverlight and he even declares: “The web is too vital a platform for business for society to be in the hands of any one vendor” and was applauded by his beholders.

Besides he states that HTML 5 does not replace HTML 4. To develop websites consisting of static WebPages embedding images, keep working with HTML 4. Most of the features that HTML 5 is bringing were already performed by using JavaScript or Flash. With HTML 5 these animations, these scripts become Web Standards.

Then Bruce Lawson presents these features:

• Canvas • Web forms • Geolocation • browser storage • video

Here the most interesting is the presentation of the canvas where Lawson is the first to speak about accessibility and Internet Explorer compatibility.


2.2 Overview of the new features To get a better understanding of what HTML 5 is bringing to the web, instead of being given as a very long list of features, features will be ranked among 5 main categories:

• New elements • Multimedia • Browser Storage and others offline features • Features to build better web applications • Forms and text editing • Other gadget features

2.2.1 New elements

HTML 5 was designed so that older browsers would be able to display it (Lawson, 2009). They would not be able to recognize the new elements but they would still display the content. Anyway, many elements have been added in this new version of HTML and here are they presented, ordered according to their function.

This part has been made using “New elements in HTML 5, Structure and semantics” (Harold 2007).This article describes exhaustively the elements of HTML 5 and gives samples of code to illustrate each of them. In this literature review will only be summed the most important new elements of HTML 5.

2.2.1.1 Structural elements In previous HTML, all developers used to assign id to their div elements to recognize their functions like header, footer, main content, sidebar, etc. <div id=”header”></div>

HTML 5 brings these new elements to replace div tags and propose a structure common to all websites:

2.2.1.1.1 <header> This corresponds to the head of the Web Page and includes usually the logo of the company, an animation displaying the services, a menu, etc.

2.2.1.1.2 <section> This is where the content of the Web Page is written, it might be a chapter in a book or a section in a book.

2.2.1.1.3 <article> The article should be included in a section and here would be written an independent article for a blog, magazine, journal, etc.

2.2.1.1.4 <nav> This is usually the sidebar, and here should be included a collection of links to other Web Pages.

2.2.1.1.5 <footer>


This represents the end of the Web Page with usually copyrights, a link to contact the owner of the Web Site, the Web Master, etc.

This is how the page should be displayed:

As well HTML 5 brings purely block semantic elements:

2.2.1.1.6 <aside> It usually represents a tip, a note, a hint, a sidebar, something out the main content.

2.2.1.1.7 <figure> This really useful element permits to add caption to a video, an image or any other multimedia content

2.2.1.2 Embedding Elements

2.2.1.2.1 Video Embedding videos in the WebPages becomes as simple as embedding images. This video tag is used in the webpage and define the source of the video to display. More is explained in the 3rd part about new features.

2.2.1.2.2 Audio It is just the same to embed audio files

2.2.2 Multimedia

2.2.2.1 Canvas The Canvas, originally introduced by Apple in Safari, allows developers to draw graphics with JavaScript code and does not require the user to download a plug-in to visualize the graphics. Precisely, the canvas is a surface on which 2D pixilated images can be drawn.

HEADER

NAV ARTICLE

ARTICLE

SECTION

FOOTER

<body>

<header></header>

<section>

<article></article>

<article></article>

</section>

<nav></nav>

<footer></footer>

</body>


To get a sample of how it works, here is a preview of Hickson’s code and it draws a line whose origins are random, in the canvas:

You need to add a canvas tag:

<canvas width="800" height="450"></canvas>

and this script in JavaScript:

<script> var context = document.getElementsByTagName('canvas')[0].getContext('2d'); context.beginPath(); context.moveTo(context.canvas.width * Math.random(), context.canvas.height * Math.random()); context.lineTo(context.canvas.width * Math.random(), context.canvas.height * Math.random()); context.stroke(); </script>

To draw more complex shapes, a bunch of functions can be created, variables and uses some of the methods created for the canvas (like the function fillRect() which will draw and fill a rectangle according to the attributes defined).

At the moment there are 3 main issues:

• There is no accessibility in Canvas for the moment. Everything is pixilated by script inside the canvas, even the text.

• This API is not implemented in IE (Internet Explorer) so an extra JavaScript library is needed to enable canvas in IE: ExplorerCanvas (Google, 2009).

• There is no DOM (Document Object Model) presence. So elements cannot be accessed and manipulated since shapes are drawn in the canvas like they would be in Microsoft Paint. However this absence of DOM allows the canvas to have huge performance and there are other ways to access some elements, by using “labels”.

There is an alternative to canvas: SVG (Scalable Vector Graphics) but its spec is six years old and its performance much lower. Like XAML for Silverlight or Action Script for Flash, it draws vector graphics. More other text remains here and is accessible. Many articles can be found on the web explaining in which case Canvas or SVG should be chosen for instance but this literature review will not go further and more information about it will be given in the dissertation. (Vukicevic, V 2006)

2.2.2.2 Video Embedding videos in the WebPages becomes as simple as embedding images. The video tag is used in the webpage and visitors can watch it without using any plug-in:

<video src="firefox.ogg" controls></video>


It has built-in playback controls and they can be added by simply including the “controls” attribute. Filters can even be added to the video (like black & white or blurry rendering).

However there is a disagreement between browser manufacturers on the video codec to use. All of them would like to use only one standard video codec but Apple and Google support H.264 while Opera and Mozilla support Ogg Vorbis. Hence there is no standard codec defined in the specifications for instance and it is up to the actors to find an agreement.

Besides there is no support for any streaming protocol and developers are looking at it.

2.2.2.3 Drag and drop It gives the ability to drag and drop photos, texts, urls, etc into a canvas.

2.2.2.4 3D APIs You can even draw 3D with JavaScript, and developers are wondering about implementing into html 5. They are providing basic fundamental APIs to allow people to use it.

2.2.3 Browser Storage and others offline applications support

2.2.3.1 Local Storage and Session Storage Their purpose is to store data client side. Developers are no more restricted by the limitations of cookies (in storage size, etc).

2 main APIs are provided:

• The database API which is made of a SQLite database. It is quite easy to use for a developer if he is familiar with server side programming

• the structure storage API (local storage) which consists in key/value pairs

2.2.3.2 Application Cache It provides a mechanism that allows web pages to ask the browser to cache locally a list, a “manifest” of files they need to work locally. It enables users to visit websites without being connected to the cloud.

2.2.4 Features to build better web applications

2.2.4.1 Workers It offers web applications a way to compete with native applications which use threads and processors. Web apps can run threads in background to do complex calculations without locking the browser’s display.

2.2.4.2 Web Sockets “Allows bi-directional communication between client and server in a cleaner, more efficient form than hanging post/get requests”

Goal is to get persistence over communication with the server much simpler.


2.2.4.3 Notifications Notifications would like to provide less intrusive event notification mechanism than the common alert() method which locks up browsers. They need to be editable, give more information, work regardless of what tab or window the user is focusing on, etc.

They are currently being prototyped.

2.2.5 Forms and text editing

2.2.5.1 Web Forms Not only coding forms is easier with HTML 5 but developers care no more about validation. By defining a type for each input, the browser will check its validity.

Some of the types supported for instance are: email, date, files, range, pattern etc.

Web Forms provides also other useful attributes.

2.2.5.2 Rich text editing How tags behave when they are included in content editable varies from a browser to another because content editable is implemented for instance in different ways.

In web services like Google Docs, users have to download JavaScript handling with compatibility between different browsers and this is a critical waste when they are using their mobile phone or accessing the web with a bad connection. Hence this must be directly implemented in every browser the same way. Companies are working on this issue.

2.2.6 Other gadgets

There are plenty of other features that need to be implemented but that are not priorities for the moment and being postponed like:

2.2.6.1 Geolocation Using Google Maps to define where the user are and propose them services.

2.2.6.2 Webcam and microphone access To allow video conferences.

2.2.6.3 Uploads To make them easier to use.


3 Research on HTML 5 & CSS3 Hyper Text Markup Language 5 (HTML5) and Cascading Style Sheet 3 (CSS3) are new web technologies that aim at building Rich Internet Applications (RIA) directly in the browser, using HTML, CSS and JavaScript. These technologies’ specifications are not finished but their implementation in web browsers has already started; hence in the first part, their availability on computers and on mobile phones will be looked at. Many developers have already developed websites to try the new features of HTML5 and CSS3; their work is presented in the second part according to their category: Music and video, Cartoons, Games and Web applications. Finally the potential impact of HTML5 and CSS3 on the web will be investigated.

3.1 HTML5 & CSS3 Availability HTML5 and CSS3 have made a real buzz in the IT world since their first drafts were officially presented. This enthusiasm can be demonstrated by the investment of web giants (Google, Apple, Mozilla) and the speed of their implementation of HTML5 and CSS3 in their own web browsers; this is presented in the first part. Then the availability of HTML5 and CSS3 are presented both on computers and mobile phones.

3.1.1 HTML5 & CSS3 are conquering the Desktop and the mobile Web.

Sundar Pichai presented at Google I/O 2010 graphs of the evolution of the adoption of HTML5 features in most popular web browsers (Pichai, 2010):

The web browsers concerned are:

• Internet Explorer (IE) (displayed in purple) • Opera (red) • Chrome (orange) • Safari (green) • Firefox (blue).

The HTML5 features covered are:

• Video (first column) • Canvas (second column) • SVG (and so on…) • WebGL • Application Cache • Geo-‐Location • Web Workers • Web Sockets • Web Storage.

Figure 2 - HTML5 Availability in may 2008

(Google, 2010)


Figure 4 - HTML5 Availibility by the end of

2010 (Google, 2010)

These graphs illustrate the rapid implementation of the HTML5 features. Such graph presenting the implementation of CSS3 features was not found, but considering that its conception started roughly at the same time that HTML5 and that its current implementation is as advanced as HTML5, the same observation could be made about it.

From these graphs, it seems that all browsers but Internet Explorer will have fully implemented all HTML5 features. This is unlikely as other more accurate sources presented below suggest it, but most of the features will be indeed available.

Besides it is clearly observable that Microsoft started to implement HTML5 features in its web browser very lately but Microsoft also did not take part early and fully in the development of their specification (Hickson, 2009). This is a curb to HTML5 because despite the continual decrease of Internet Explorer’s popularity, Microsoft still controls a big part of the Web-browsers share (nearly 30%) (refsnes Data, 2010).

3.1.2 Availability on computers

HTML5 and CSS3’s availability on a web browser depends on its level of implementation; every web vendor manages the implementation of the features on its own.

To define the availability of HTML5 and CSS3 on computers, you also need to consider the popularity of the web-browsers that implement those features. The next figure “Browser Statistics (October 2010)” shows the percentage of worldwide web users per web-browser. Firefox is leading the market with 44,10%, Chrome is second with 29,70% and Internet Explorer is third with 19,20%. Safari and Opera are behind and gather about 6% of all web users.

Figure 3 - HTML5 Availability in May 2009

(Google, 2010)


Figure 5 - Browser Statistics (refsnes, 2010)

It is also necessary to consider the trends because the availability of HTML5 in the next year will also depend of the popularity of the different web-browsers though they are expected to move. In the last year, according to the graph of browser statistics from October 2009 to October 2010 (refsnes, 2010), Chrome’s web usage increased by 11%, Internet explorer decreased by 8% and Firefox by 3%; Opera and Safari are stable. If the trends go on this way, Internet Explorer could loose more market share and get behind Chrome and Firefox.

Figure 6 - Browser Statistics (from october 2009 to October 2010) (Refsnes, 2010)

Not only the current percentages but also the trends show that Internet Explorer is no more leading the market of web-browsers as it used to (resfnes,2010), but its importance is also decreasing. Despite the fact that Internet Explorer is the least advanced web browser in HTML5 and CSS3 implementation, its inferiority in market


share could lead developers to start using the new web technologies even though they are not fully available and particularly on Internet Explorer.

On Microsoft operating system (Windows), only the web browser corresponding to the Microsoft brand is installed: Internet Explorer. Hence, Firefox and Chrome need to be installed manually by the user. This shows that users deliberately choose to use Firefox or Chrome instead of Internet Explorer and this suggest that web users may prefer web browsers that are favourable to new technologies.

This study also shows that Safari and Opera apparently play a minor role in the market share in comparison with the other ones. Hence it is necessary to look more carefully at the implementation of features in the three giants that are Firefox, Internet Explorer and Chrome.

3.1.2.1 Current availability of HTML5 & CSS3 features A few websites keep up to date the availability of HTML5 and CSS3 features in all modern browsers; the aim is to present the advance in their implementation and inform developers of what features they can use in what browsers. Alexis Deveria (2010) created one of those useful websites and the summaries for HTML5 and CSS3 are displayed below.

These two below figures present the percentage of HTML5 and CSS3 features developed for the same web browsers as presented on the Google I/O: Internet Explorer, Firefox, Safari, Chrome and Opera. The different versions of these web browsers are also taken into account and show the advance of the implementation (from the two version back to the next version planned for late 2011). With the HTML5 features is also integrated its JavaScript Application Programming Interface (API); an API consists of a set of objects and functions that developers can use to perform complicated tasks (Wannemacher, 2007).

Figure 7 - HTML5 and ITS Javascript API Availability (DEVERIA, A 2010)

Figure 8 - CSS3 API Availability (DEVERIA, A 2010)


While Internet Explorer’s advance is very poor (only 28% of all HTML5 features, 27% of all CSS3 features), all other browsers already implemented more than half of all features. The two other giants in terms of web-usage implemented 69% (Firefox) and 86% (Chrome) of HTML5 features, 74% (Firefox) and 89% (Chrome) of CSS3 features.

This current implementation on Internet Explorer 8 is a brake to HTML5 and CSS3 and is very too low for developers to dare using it to develop business websites. The current implementations on all other browsers are however enough, and considering that all browsers did not implement the same features, this means that developers can already experiment all planned features on HTML5 and CSS3. Many websites, as presented in the next part, show HTML5 and CSS3 potential, but very few used them for business driven websites.

The next version of all web-browsers (IE 9, FF 4, Chrome 8) for the upcoming year is however more promising and will put the HTML5 and CSS3 implementation to a further step: IE will have 54% of HTML5 features and 71% of CSS3 features implemented. Firefox and Chrome will have 94% of HTML5 features and 89% of CSS3 features. Considering the trends in Web Usage, the importance of IE will be even lower. Besides according to Jeffrey Zeldman, the mentality in development evolved and developers now prefer to use the new features brought by the most advanced web-browsers while they ensure that the websites are still usable in other web browsers, and among them IE (Zeldman, 2010). For all those reasons, in the next year it is very probable that more and more business websites will be developed with HTML5 and CSS3, even if they do not present the high level of interactivity of Flash.

3.1.2.2 Libraries dedicated to availability To compensate the heterogeneous implementation of HTML5 and CSS3 features among brothers, and especially the late investment of Microsoft on IE, developers created very useful libraries:

Modernizr (Ates, 2010) provides functions to evaluate the implementation of a feature on the user’s web browser and act consequently. HTML5 shiv (Sharp, not dated) renders properly the new elements in HTML5 on IE even if they are not implemented yet. ExplorerCanvas (Arvidsson, 2010) renders the HTML5 canvas on IE although it is not implemented yet. Google Chrome Frame (Russel, 2009) embeds the Chrome JavaScript engine within Internet Explorer: whatever HTML5 feature Chrome implemented, it is made accessible in IE.

If features are not developed in all web browsers, developers can define behaviours according to the web browser’s implementation. Some HTML5 features not natively implemented in IE can be turned on due to libraries; however the performances might be lower.

3.1.3 Availability on mobile phones

Jason Grigsby (2009) thinks that some features are critical for the mobile web and therefore the development of HTML5 will be driven not by computer needs but by mobile needs; the offline support, canvas & video, and the geolocation API are some of these features.


The next two figures represent the worldwide sales of smartphones by operating system in the third quarter of 2009 and 2010 (Gartner, 2010).

Figure 9 - Worldwide smartphones sales to end users by operating system in third quarter 2009

(gartner, 2010)

The four leaders in 2009 are Symbian (45%) owned by Nokia, Research in Motion (RIM) (21%) the manufacturer of Blackberry smartphones, iOS by Apple used on iphones and ipads (17%) and Microsoft Windows Mobile (8%) (Gartner, 2010).

Figure 10 - Worldwide Smartphones sales to end users by operating system in Third quarter

2010 (Gartner, 2010)

In 2010, Google conquers the market and comes second (25%), after Symbian (37%) and before iOS (17%) and RIM (15%); Microsoft decreases by 5% (Gartner, 2010).

These trends seem to demonstrate that users are favouring companies that focus on new technologies as Google (who won a big marketshare) and Apple (who owns an important market share and keeps it while its products are among the most expensive devices) do.

Currently the incorporated web browsers of the apple, nokia, palm-pre and android devices are based on the webkit engine (that is also the engine of the Chrome and


Safari web-browsers) and are implementing the HTML5 and CSS3 features (Grisby, J 2009). This statement is demonstrated by the following graph that shows the HTML5 Mobile browser support for 20 popular smartphones. The nine smartphones that support the most HTML5 are using Symbian, Android and iOS.

The two other major mobile device platforms are Windows Mobile and Rim’s Blackberry. However the Windows Mobile platform, as seen on the previous graphs lose market share, mostly because of its principal manufacturer HTC that is incorporating Android OS on its mobile phones instead. RIM has its own mobile web browser that is not based upon any major web vendor’s engine and is buggy in comparison with its competitors. However on these platforms, the Opera mobile web browser is popular and should compensate those weaknesses (Grisby, J 2009).

Figure 11 - HTML5 Mobile browser Support (Rutgers, A nd)

3.1.3.1 Current availability of HTML5 & CSS3 features There are very few statistics on the availability of HTML5 and CSS3 features on mobile devices and they are not as complete as figures that can be found for the desktop environment.


The two next figures show the percentage of HTML5 and CSS3 features implemented on iOS Safari that is used on all Apple devices (iphone, ipad) and on Opera Mobile and Mini. The expected percentages of availability of the upcoming versions of these mobile web browsers are missing but they can be compared with the forecast for the web browsers of the same companies on the desktop environment, since they use the same engines as their “older brothers”.

The iOS Safari for mobile devices has currently implemented only half of HTML5 features but the browser for computers is expected to increase by 14%, so a similar increase could happen on the mobile version.

The Opera web browser on Desktop however is not expected to implement many other features. However Opera probably owns a bigger market share on mobile devices than on computers since its web browsers have 50millions users on the mobile version and 50 millions on the desktop version (Opera, 2010), while there are nearly two billions of total Internet users on computers (Miniwatts Marketing Group, 2010), and less than one billion of total smartphone users (Middleton, 2010). However if Jason Grigsby (2009) is right about the fact that HTML5 is going to be driven by mobile phones, the implementation on mobile phones should be expected to rise dramatically.

Figure 12 - HTML5 and ITS JAvascript API Availability on mobile web browsers (deveria, a

2010)

Figure 13 - CSS3 aPI Availability on Mobile web browsers (Deveria, A 2010)

HTML5 and CSS3 features are expected to get much more accessible on mobile devices and especially on iOS and Android platforms that are leading its development with the webkit engine. However companies using the Symbian OS and RIM still need to show their investment.


3.2 What is HTML5 & CSS3 used for (at the moment of this writing)?

Many developers have already developed websites to try the new features of HTML5 and CSS3; their work is presented according to their category: Music and video, Cartoons, Games and Web applications. Even if this dissertation is focusing on the graphic capabilities of new technologies competing with Flash, and therefore on the HTML5 Canvas and CSS3 new properties dedicated to animation, its scope is a little bit widened to introduce other HTML5 features that are necessary to build Rich Internet Applications (RIA) or multimedia websites (while those new features in HTML5 are already provided by Flash). Hence Music and Video introduces the HTML5 music and video features; cartoons, Games and web Applications are mainly about the HTML5 and CSS3 graphic features but also mention offline and other HTML5 features.

Since these technologies are new and mainly experimental, most of the works done are focusing only on specific features and there are not very complete web applications using all new features. For that matter, websites are also organized according to the specific features concerned: for example, for the Games main category there is a 3D sub category.

This research on HTML5 and CSS3 was the very first part of the report written so the samples of HTML5 and CSS3 websites that were studied here are at least five months old. New animations and applications were developed ever since but the 5 next months were dedicated to the rest of the dissertation: research on Flash, learning, implementation and benchmarks. This situation is discussed in the Conclusion.

There is no “advertisement” sub chapter, contrary to the research on Flash because there are not such samples of HTML5 or CSS3 websites. These technologies are still not mature enough to be used in businesses, and this is as a matter of fact one of the purposes of this research: to find out whether HTML5 and CSS3 can now be safely used in businesses, instead of Flash.

3.2.1 Integrated Music & Video

Audio and video are fields that Flash made accessible on the web and now leads (see next chapter: research on Flash). But some HTML5 features cover those fields and offer an alternative to Flash. Hence the audio and video HTML5 features are presented below.

3.2.1.1 Audio The audio element is currently implemented on all web browsers but IE and is as simple to use as the image tag: indeed to insert an audio file on a web page you need to write this code:

<audio src="myAudioFile.ogg" controls="controls">

Your browser does not support the audio element.

</audio>


However there are still debates on the codecs to use and the below figure shows what codec can be read on every web browser. In fact the different web vendors did not agree on a unique codec to use. Most of them can read the wav format but there is a need for a compressed format otherwise embedding audio on the web with HTML5 will require to load huge files and such a solution cannot be accepted on mobile phones for example where users may not access broadband connections. Otherwise some web browsers only read the OGG format while others only read the MP3 or AAC format (Deep Blue Sky, 2010).

Figure 14 - HTML5 Audio Codecs (Deep Blue Sky, 2010)

Most samples involving sound, and which are described in this research, are only embedding a song and are not playing it as an event though this is necessary in games for example. However the audio HTML5 API provides functions as “play”, “pause” and should allow developers to use sounds how they want. No study has been made up to now to measure the performances of HTML5 audio.

3.2.1.2 Video A video can be inserted on a web page using this code:

<video src="movie.ogg" width="320" height="240" controls="controls">

Your browser does not support the video tag.

</video>

There is the same problem as for the audio element: the video element is currently available on all web browsers but IE, and web leaders are debating on the codec to use; however this situation is more critical:

• The Ogg Theora codec is not accepted by Apple for hardware issues • The H264 codec is not supported by Opera and FF for licenses issues

(Pilgrim, 2010) Recently Google apparently brought a solution: WebM is royalty free. FF, Opera, Chrome and IE announced their support for the VP8 Codec and WebM. Only Apple did not make such announcement (Mediati, 2010).


Many video players are already implemented, and even video streaming leaders are using HTML5, among them Youtube and Vimeo (templates blog, 2010). It shows that developers can use HTML5 Video.

Besides video can be embedded in a canvas and manipulated in many ways: split in slices, explosions, integrated in a sort of 3D Movie Theater, applied with filters (black and white filter for example). Nonetheless, such effects may involve high processing and require hardware acceleration. On this field, Flash uses the potential of users’ graphic cards to display efficiently its animation or video but HTML5 does not use hardware acceleration natively. The WebGL project is focusing on this matter but this is still experimental (Khronos Group, 2010).

Figure 15 - HTML5 Video CODECS (Deep Blue Sky, 2010)

Hence for both video and audio, either developers should wait for web giants to agree on a single codec to use, or they can start using html5 video but should provide two different versions of their content to ensure that all web browsers can read them.

3.2.2 Cartoons

HTML5 Canvas and new CSS3 properties bring new APIs to draw graphics on the web and animate them. These APIs provide simple functions to draw specific shapes, import images, modify the appearance of already drawn shapes or images and animate them (translate and rotate). On the other hand, Flash provides a complete authoring tool to create quickly complex shapes, integrate them on a canvas, handle their behaviour and animation, manage scenes, etc.

To draw a character is obviously easier by using a painting application than by typing lines of code. To animate it is even worse. So Flash will certainly always be easier and more efficient to use than these new web technologies until an equivalent authoring tool is provided for HTML5 or CSS3.

The purpose of this study here is to see if HTML5 and CSS3 provide sufficient APIs to create cartoons by ensuring that cartoons built with them exist. Then it investigates how difficult it is to write code to create a cartoon to ensure whether designers could afford the time to make animations with it. Finally the study aims at looking whether web-browsers could display these animations smoothly.


Two animations are presented, the first built with HTML5 and the second with CSS3.

3.2.2.1 HTML5 Tomte & Goat

Figure 16 Tomte and goat (2009)

“Tomte and Goat” is at the moment of writing the only HTML5 animation. It presents two characters walking and chatting on a static background. It is very basic: they walk, move their arms, grab an object and their speech is displayed in bubbles (tomteAndGoat, 2009).

It is developed entirely with canvas + JavaScript (JS) and consists of 2000 lines of code. The code presents scores of functions: “say”, “walkright”, “runleft”, “goto” for actions for example, and “angry”, “shock”, “horror”, “smile” for expression.

This is the only HTML5 Canvas attempt to create a cartoon and this is not thrilling because:

• The graphics are childish • The animation is basic: it only consists of objects translating and rotating • There is only one scene.

Nonetheless the basics for creating an animation are available here with HTML5 and JS:

• You can import images or draw images on a canvas. • You can rotate or translate objects

The amount of work produced is not worth the results in comparison to the next animation presented.

3.2.2.2 CSS3 Spiderman

Figure 17 CSS3 Spiderman (CALZADILLA, 2010)


This animation is developed with HTML5, CSS3 and jQuery. The animation is much more complex than on the previous one, backgrounds are moving, there are several short and different scenes (being “shot” from different angles). The animation involves also music and this is an HTML5 audio tag. The overall quality of graphics is much better. The code, inserted in the appendixes, is much easier to read (CALZADILLA, 2010).

The process for creating this animation was:

1. Character and background art (photoshop/illustrator) 2. Character rigging: assemble the parts of the body (photoshop/illustrator

then HTML5) 3. Animate the character (CSS3) 4. Assemble the different scenes: make the transitions (jQuery)

Although there is this only Goate and Tomte animation in JS + canvas, there are already many attempts in CSS3, it must be then more convenient if developers choose CSS3.

Rotation, scaling and movements are enough to create simple animations. However shape transformation is also necessary: for example, the progressive transformation of a square into a circle as it is possible in Flash. But it cannot be handled in CSS3 for the moment.

As a conclusion to this Cartoon part, it seems that CSS3 has more potential to create cartoons than HTML5. The samples in CSS3 are promising. But it is still tough to create animation only by coding and unless an efficient authoring tool is available, Flash will stay as a leader on this field.

As far as the performances are concerned, both animations could be displayed in web browsers and present a decent frame rate so that they are played smoothly.

3.2.3 Games

Cartoons involve drawing graphics and animating them. Games may involve drawing graphics, animating them, doing calculations, storing data, managing input controllers, etc. In such a complex deal of requirements, the graphic engine must be efficient enough to support the extra processing dedicated to other tasks.

The 3D feature may be about to be democratized on the web. Up to now, it was hard to embed 3D graphics in websites without plug-ins because web browsers could not access the capability of the hardware, and above all, the users’ graphic cards. Not only HTML5 and CSS3 bring APIs to render 3D graphics but also once fully implemented by web browsers, they will be able to access hardware acceleration and render very complex 3D graphics with reasonable performances. Since 3D seems nowadays mostly used in games, its part dedicated is inserted here.

Developers already started to use HTML5 to develop games. Some of these games were studied and their analysis is presented.

3.2.3.1 3D 3 dimensional elements (3D) can be used to display products and make them interactive: by moving the mouse around the object, a user can change the angle of


view. But if 3D is on the contrary almost ubiquitous in video games for desktop, this is less common in online games and even seldom on commercial websites.

The biggest constraint is because of the performances: to display dynamically an environment composed of dozens of models consisting of hundreds of polygons, the game needs to be able to access the processing power of the player’s graphic card. Up to now, this could be done in Flash but there was no native 3D API in HTML or JavaScript. Hopefully, HTML5 brought its own 3D Canvas API to create 3D models in JavaScript with the HTML5 Canvas. Other groups are working on providing a more complete API for developers and integrating the hardware acceleration: X3D or WebGL (W3D Consortium, 2010).

The following samples show the first attempts to use HTML5 to create 3D graphics. Their screenshots and the resulting analysis are presented while a deeper description is inserted in the appendixes.

Figure 18 - MOnk Head

(Toxicgonzo, not dated)

Figure 19 - Interactive

Towel (Gyulabo, not

dated)

Figure 20 - Javascript WOLFenstein

3D (Seidelin, 2008)

Figure 21 - 3D Walker (Joffe,

Canvascape - "3D Walker",

2005)

Figure 22 - Earth 3D

Canvas(Joffe, Earth 3D

Canvas, not dated)

Figure 23 - Quake 2 WEBGL

(Haustein, 2010)

The monk head is a 3D model rotating on himself. The interactive towel is a 3d model of a towel that swings when clicked. The JS Wolfenstein 3D is a port of the classic first person shooter (fps) on JavaScript and uses the canvas to be displayed. The 3d Walker is another FPS created with HTML5. The 3D earth is a model of the Earth that you can rotate and zoom. And Quake 2 WebGL is the port of the classic FPS to web-browser and using the library WebGL.


The performances of the monk head in frame rate are very disparate according to the different browsers: 40fps in Opera, 30 in Chrome and 15 in Firefox (Toxicgonzo, not dated). So it shows that they depend on the advancement of the implementation of HTML5 in each of those browsers (which are –for the moment, in 3D- at their very beginning); these performances are therefore expected to increase greatly in the future.

However with the hardware capability increasing, we might see much more complex applications taking benefit of the Central Processing Unit (CPU) and Graphic Processing Unit (GPU) usages through hardware acceleration. Anyway 3D animation by software rendering (only canvas + JS) cannot present high performances and will be used only on simple animations. Quake 2, presented below, is an example of these complex games that take benefit of the hardware acceleration.

The Wolfenstein 3D game uses “ray casting” to simulate 3D space with good performances on modest hardware: the intersections between a ray and a surface are calculated; since the camera angles of the shooter are locked, for each representation of an object (according to a defined angle) can be presented an image, therefore according to your position in the space, while looking to an object, its right representation is displayed to you (Seidelin, 2008). This technique can be used to create games that can be rendered directly in the web browser and do not need hardware acceleration. However the resulting graphics are far less appealing though nowadays players may expect good graphics.

The Earth animation is the first of this list to be done with the 3D Canvas API. However this 3D Canvas API is still experimental and requires to use special builds of web browsers.

It seems like you can create simplistic 3D apps/games with the canvas but you do not get great performances: either animations display a very limited number of simplistic 3D models, or the animation presents a poor frame rate and looks laggy. The Quake 2 port is the first ever example of a very complex video game directly embedded in a web browser and uses WebGL (Haustein, 2010). It is still complicated to manage to play it because users need to rebuild the whole game with a developer tool, download a special build of their web browser and even install special plug-ins. But this sort of game intends to be in term directly accessible in a web browser without the need of installing any other plug in or software. However no one know when such feature will be integrated in web browsers.

3.2.3.2 HTML5 Canvas games To promote HTML5 and CSS3 new technologies, some websites list all web applications or animations that are created using those technologies. CanvasDemo is one of them and organises the existing demonstrations of HTML5 Canvas into categories. Hence the games listed in the categories “Shooting”, “Puzzle”, “Platform” and “Strategy” were observed and their conclusions are presented here (Smith, not dated).

All shooting games involved very basic 3D graphics with low resolutions. The only exception is Quake 2, but as it has been stated previously, this game cannot be played natively in the browser for the moment.

The other games generally involve poor graphics, simplistic interactivity and had a very low frame rate unless they involved very few elements.


Hence at the moment, all sorts of games can be developed with HTML5 canvas, but they cannot compete with Flash games in terms of graphical aspect, interactivity and performances (frame rate and load time).

By the way, while there are about 50 HTML5 games listed on CanvasDemo, CSS3-only games are very rare and hard to find; CSS3 can style the layout, draw graphics, is starting to provide animation, but to develop a game, it requires using a programming language as JavaScript.

3.2.4 Web applications

Some libraries were developed to enhance the HTML5 API and are exhibited here. It might be useful for developers to have a look at them before they start to develop with HTML5 because these libraries can both save them time and make easier to develop complex graphics or web applications.

Many websites or web applications were developed using HTML5 and CSS3. Some of them are introduced and analysed; they are organized according to the following categories:

• User Interface • Utility, analytic and content applications • Painting and photo editing applications

3.2.4.1 JavaScript Libraries In this part are presented libraries that can save developers a lot of time and especially in game development.

Physics are an essential part of games. Either it involves gravity, collision detection, reactions, or other interaction with the environment or an object, calculations must be performed to handle the situation. So here were studied two physics libraries, one for 2D graphics: Box 2D JS (Yasushi, 2008), and another for 3D graphics: Bullet.js (pl4n3, 2010).

The third library, Processing.js (Resig, 2010), offers a complete API based on the HTML5 2D Canvas to create web applications, animations and video games.

The fourth library is RGraph (RGraph, 2010) focus on creating graphs and charts.

These four libraries are presented with more depth in the appendixes.

The existence of these libraries proves that there are already complete sets of functions for developers to quickly create web applications. It requires for developers deciding what libraries to consider and whether their use is really worthy for a project. These libraries offer also many samples and they can be used whether to learn how to use the API or to benchmark the engine and approximate whether it is performing enough for a specified type of application.

These libraries also use the HTML5 graphic APIs so their performances are expected to improve since web-browsers are implementing HTML5 features and improving their rendering.

Besides, libraries and


3.2.4.2 User Interface 3 HTML5 examples of user interface were observed and are described with more depth in the appendixes: the digital comic app Website (MadCap Studios, Inc, 2010), a User Interface (UI) dial with snaps created with processing.js (F1LT3R, not dated), Momoflow (Momolog, 2009) that is a mac coverflow created with jQuery. The fourth example, Photo transitions (Apple, not dated), is animated with 2D and 3D CSS3 transitions.

Their aim is to add animation or special interactivity to the UI but the HTML5 websites are not built only with HTML5 Canvas and its graphic JS API but also with extra libraries (jQuery, processing.js). Hence the development of the UI animation is too complicated here and requires loading extra libraries, which increase the load time of the websites. Finally the last example in CSS3 presents the most simplistic code and is both smooth and beautiful.

The CSS3 properties are a better solution to enhance the interface of a website with animation:

• It requires far less code and is easier to create the animation. • If the web-‐browser did not implement the CSS3 feature, it does not

change the website aspect, it just does not apply the animation and the website is still accessible.

• It does not require an extra JavaScript library so it does not process extra code nor download extra file.

3.2.4.3 Utility, analytic and content Applications Some web applications were created and used the HTML5 canvas for their graphic user interface (GUI). The samples used for this study are quickly presented here with their analysis. They are described with more depth in the appendixes.

• Slippy map draws a map of the world and the user can grab, slide and zoom it (Hutt, not dated).

• CloudKick displays in real time a cloud monitoring system on a 3d space with processing.js (Team Cloudkick, 2010).

• Comments show when comments were posted on a blog using a graph with processing.js (Ryall, 2008).

• ThinkApp is a tool to create personalised mind maps (Sands, not dated). • Graph.tk is a math tool that draws functions and resolves differential

equations (graph.tk, not dated). All these samples show that developers can use the HTML5 canvas to create graphical web applications. Some of them load content from other web services (twitter, blogs, data servers) and present it on graphs in real time with a very good latency. The performances with the Canvas are here very good: the applications are smooth to use and do not lag because, contrary to HTML5 games, the graphics here are simplistic and the required processing power to display them is quite low.

As stated before, libraries exist and provide complete APIs to create graphs for analytic web applications.


However care must be taken when implementing text/content based applications concerning availability. The text must be accessible, this means that it should appear in the code source of the web page for two reasons:

• It needs to be readable by impaired people that use screen readers. • For Search Engine Optimization (SEO) and this is one of Flash biggest

weaknesses: the content needs to be available and analyzed by Search engine bots so that the website is well referenced.

The group working on the HTML5 specifications is working on a canvas availability API to make content inserted inside the canvas accessible; but they are still working on its specification so the API will not be implemented soon. Hence developers must not insert the content in the Canvas. They must use the canvas as dynamic background but the text must be inserted outside the canvas.

3.2.4.4 Painting and photo editing applications The most impressive Rich Internet Applications (RIA) that take large benefit of HTML5 capabilities are painting and photo editing applications. Three great applications were looked at. They are described in more depth in the appendixes but their analysis is explained here.

• Sketchpad (Orange Honey, not dated) and ChromaBrush (Google, 2010) are two painting web applications and use Canvas 2D, Canvas 2D SVG, jQuery and JavaScript.

• Darkroom (Orange Honey, not dated) is a photo editing web application that uses canvas 2D and jQuery.

Figure 24 - Chromabrush (Google, 2010)

Figure 25 - Sketchpad (Orange Honey, not dated)

Figure 26 - Darkroom (Orange Honey, not dated)


These RIA offer a very complete experience. They offer many tools, import libraries of gradients or patterns, can manage history and layers; they can be used offline; they are able to apply filters to pictures or change their levels of contrast, brightness, etc; one of them use web workers to enhance its performances and even embeds audio, video and the notification API to enrich the user experience. Finally despite the amount of features available, the applications work smoothly.

They are built with jQuery but the use of a library for a RIA is relevant and maybe even necessary. They use the Canvas 2D and the Canvas 2D SVG to display the painting canvas, store the required images (previous paintings, different layers) and show the tools.

The source code is fully readable so developers can use and study it to understand how are built the applications and use in their own projects. This accessible code source arises a situation: developers must be able to protect their development; while Flash is not accessible at all, its code once published cannot be decompiled and stolen; however this matter is not taken into account in this research. These applications prove that the use of HTML5 graphics to create mainly graphically RIA with static but interactive graphics is relevant and works.

3.3 Strengths of HTML5 and CSS3 According to Jeffrey Zeldman (2010), HTML, CSS and JS are more likely to drive the future development of rich web applications and experiences. Some of its strengths are presented below. The potential impact of these new web technologies is discussed with the future of Flash in the final part of this HTML5 and Flash research.

3.3.1 Cross platform technology

While developers used to develop websites or web applications for only specific web-browsers because of of the inappropriate conception of previous HTML and CSS versions, now they will able to develop cross platform web applications using web standards (HTML, CSS and JS) that are accessible not only on all computer web-browsers but also on mobile phones (Zeldman, 2010).

3.3.2 Saved bandwidth: vital for the mobile web

CSS3 can create visual graphics like gradients, shadows and other effects with simple code, withdraws the need to use background images and then saves bandwidth, which is important on websites dedicated to mobile phones (Zeldman, 2010). Some HTML5 features like local and session storage, application cache not only allow storing data on the client side and making his application work offline but removes the need to download permanently those data.

3.3.3 Rich media without plug-ins

HTML5 brought audio, video and canvas APIs to enable rich media on the web without the use of plug-ins (Zeldman, 2010). So HTML5 may disrupt the proprietary technologies leading on those fields.

3.3.4 RIA features

As seen in the literature review, many HTML5 features are dedicated to building RIA.


4 Research on Flash Flash is currently the leading technology to create complex animations and Rich Internet Applications that embed high interactivity. In this chapter, first will be presented the Availability of Flash on its computers and mobile phones. The different kinds of applications (apps) that are created with Flash, and what profit they can gain of using Flash, will be explained. Then the global impact of Flash on the web will be discussed. Finally the economics at stake and the war on words between Adobe, Google and Apple about Flash will be investigated.

17/08/2010

4.1 Flash Availability on Computers To read Flash content, users need to download and install a plug-in to their web browser: Flash Player. To start it is necessary to know what percentage of web users has downloaded this plug-in and can therefore read Flash content.

Adobe (2010) claims “99% of Internet enabled desktops access Adobe Flash Player”. This figure sounds hard to believe since all new desktops do not necessarily include Flash player for example. Besides this figure involves all versions of Flash though only people who installed the last version of Flash Player can view Flash content produced with the latest Flash Editor and take benefit of the new features involved.

This figure (and the other numbers included in this web page) is said to be the answer from Adobe to the article wrote by the CEO of Apple, Steve Jobs (2010), who claimed that Flash was out-dated and should disappear with the emergence of HTML5. This article from Steve Jobs could be studied on a marketing point of view, but his claims are really suspicious on the technical side.

Besides this survey focused on “mature or emerging markets”, this means U.S., Canada, U.K., France, Germany, Japan, Australia, New Zealand though many European and emerging countries should be included in this survey.

Tom Arah from PC Pro (2009) opposes the 99% figure from Adobe. He claims that the source used by Adobe for the study was not wide enough and he suggests another website to know about the penetration rate of Flash: RiaStats.

The survey from riastats (Dreamingwell.com, 2010) studies a much broader sample, gives the penetration rates for each version of Flash, and is based on a worldwide sample. This is less relevant for this study but it also presents at the same time rival technologies, Java and Silverlight, allowing their comparison, presents the penetration rates over time, etc.


Figure 27 - Flash Penetration per player version (DreamingWell.com, 2010)

Let’s suppose that there is roughly 1% of not-detected but Flash-enabled, there is finally around 97% of overall penetration of Flash. This figure shows that Flash is ubiquitous on computers on the web. It is more accurate than Adobe’s one but whether the real percentage is 97% or 99%, it might be a waste to debate about it. Nevertheless Flash is not perfectly 100% accessible and this argument supports the need for Web Standards.

4.2 Flash Availability on Mobile phones The Adobe Website is the only place where figures about Flash penetration on mobile phones are given.

Adobe (2010) claims “19 out of the top 20 mobile handset manufacturers are collaborating with Adobe to integrate Flash technology into their devices”. This means that every manufacturer is collaborating with Adobe but Apple who then explicitly competes against Flash.

“About 40% of all new mobile devices worldwide ship with Flash technology today” (Adobe, 2010). Although Flash is ubiquitous on computers, laptops, even Macs, its presence on the mobile scene is less enormous and it then makes more room for competitors. Indeed in the development of web apps, the technology used is often chosen to be compatible with as many devices as possible. In such a situation, HTML5 might occur as a better solution because all mobiles internet-enabled include a web-browser.

Even in today’s mobile technology era, there are a few statistics to demonstrate the percentage of use of Flash Player Light for mobile phones. Not only the source used by Adobe for the 40% penetration cannot be found on the web but also the rare surveys on the technologies for mobile phones are priced. Most of the interesting surveys are made by analytic companies and are costly. This kind of resources was not taken into account in the proposal.


.Net magazine (.Net Magazine, 2010) shows a table showing the number of apps for mobile phones per market:

Name Company Number of apps

Android Market Google 30,000

App Catalog Palm 1,500

App Store Apple 150,000

App World RIM(blackberry) 6,118

Windows Marketplace for mobile Microsoft 693

Figure 28 - Table of apps for mobile phones per market

Apple definitely dominates the apps for the mobile phones market due to its iPhones - which do not support Flash. The Android Market is rapidly growing and Adobe is actively working with Google on Android to support Flash on those mobile phones. It can therefore be assumed that, with Google’s support, Flash may be able to compete against the Apple’s phone technology.

4.3 What is Flash used for? Flash is used to create interactive rich media content; not only might it involve text, images, vector graphics, video, animation, graphic effects but its content must be highly interactive and consists of click-able links and forms as characterised by more than simple static websites (Triolo, 2006).

Another figure given on the Adobe website on the Flash player is that “85% of Alexa top 100 websites involve Flash” (Adobe, 2010). Alexa provides information about top sites, traffic statistics and metrics and is the reference in its domain. This means therefore that 85 of the 100 most visited websites in the world involve Flash according to Alexa. Flash is not only ubiquitous on desktops but also on the web. Controversially this study might consider that a website embedding a flash-made advertising banner globally uses Flash and this is incorrect. Hence it is necessary to look in more details at the use of Flash in websites.

Flash Creation presents in its introduction to Flash different types of Flash-based content as samples (Triolo, 2010). From this list were organized five categories:

● Integrated Music-Video ● Cartoons ● Games ● Advertisement ● Custom Navigation / Full Flash Websites

4.3.1 Integrated Music & Video

According to an Adobe evangelist Ryan Stewart (2008), and according to an article written on TechCrunch by Jeremy Allaire founder and CEO of Brightcove (2010), around 75/80% of the video on the web is Flash video.


Most worldwide popular websites use Flash video: Youtube, Vimeo, Hulu, Google video, yahoo video, the BBC video player. Also most radio streaming or music players use it: Deezer, Soundzit and the BBC radio player.

How Flash became the leader of the Video on the web must be investigated.

In the beginning of Internet, the affordability of computers, the growth of their performances and the bigger availability to broadband connections made the public ask for richer media than static websites. (Quick.tv, 2009)

In addition a new concept was born: the participatory culture where users wanted to contribute to the Internet world by making and watching videos.

In the late 90s, restrictions for video streaming, that were due to limited processing power or not rapid enough connections, started to disappear. In 1998 the video format MPEG-4 was introduced and in 2000 it became the standard for video playback on the web and leaded its development. A problem was the client-side browser compatibility and most video players needed to be downloaded to watch some particular content (Quicktime, Windows Media Player, Real Networks).

Flash already was at that time a standard on the web for animation and its player was widely spread. When it started to offer video playback, its already superior penetration rate made it the first choice for video. (Quick.tv, 2009)

Flash Player 6 was launched in 2002 and enabled Video. On March 2004, the penetration rate of this player’s version (with video integrated) was over 92%: hence 92% of worldwide Internet users could watch videos due to Flash (ZDNet Research, 2004). Efficient video streaming was made possible by Flash and accessible everywhere because of its popularity. As a consequence, the development of video enabled Youtube to appear in February 2005.

Guba in 1998 and Metacafe in 2003 offered video portals but were not very popular (ZDNet Research, 2004). However Youtube, once released in 2005, had a universal and immediate success; this was due to its technology, Flash, which offered the best performances in Video streaming. Today Youtube is ranked as the 3rd most visited website after Google and Facebook according to Alexa (2010).

However on mobile devices, Flash is far from leading the market. Apple is leading the market of smartphones with its iPhone and boycotts Flash. On tablets, Apple is also leading with its iPad and Flash is also forbidden on this device. Although companies intend to get their content accessible on iphones and ipads though video cannot be displayed with Flash, new solutions must be adopted. On this ground, the HTML5 video appears as the solution, and should be commonly used as soon as the major browser vendors agreed on a video codec and implement it.


4.3.2 Cartoons

Some popular TV cartoons are built with Flash:

● Atomic Betty launched on Cartoon network in the US ● Happy tree friends was a very popular Flash animated cartoon in 1999 and was

published on TV in 2006 ● Salad Fingers, a horror carton created in 2004 ● Bobinogs, a TV cartoon on BBC for kids

If such Flash cartoons exist on TV, and not only on the web for what it was created, that means that this technology offers everything required to create animated drawings and cartoons.

Besides animated drawings can be found in cartoons but also in games, advertisements and to enhance the layout of websites.

Happy Tree Friends and Salad Fingers, contrary to Atomic Betty and Bobinogs, are 2 cartoons that were initially published on the Web and created such a buzz that they made their ways to the TV screen and Festivals. Their history and how Flash enabled them to get so famous is analysed below.

4.3.2.1 Happy Tree Friends

Figure 29 - Happy Tree Friends (Cold Hard Flash, 2005)

Happy Tree Friends is a flash cartoon that was released on Internet in 1999 (Cold Hard Flash, 2005). Its short episodes last a few minutes and involve animal characters playing in childish environments and always finishing the show by dying gruesomely. This extremely violent show, Flash based, was highly popular as soon as it was published on the web in 2000. Such a cartoon in a video format could not have been widely published on the web at this time but web animations could, due to Flash and its player’s already ubiquity.

The essence of the web is its parcipatory culture. Flash enabled the show to be shared by viewers and rapidly grow in popularity internationally; it could not have reached such an audience if it had been only published on a TV channel.


Thereafter in 2006 it started to be published on TV channels all over the world. Its globalisation was made possible by its nature: it is almost a non-speaking show. (Cold Hard Flash, 2005)

The extremely violent nature of this show with childish graphics that make this cartoon extremely original would have been scarcely watchable on TV at its launch. The Ofcom broadcasting code (Office of Communications, 2010) defines whether a TV program is suitable to the potential audience and can be broadcasted; concerning the under eighteen, it states that “Violence, its after-effects and descriptions of violence, whether verbal or physical, must be appropriately limited in programmes broadcast before the watershed (before 21:00) or when children are particularly likely to be listening and must also be justified by the context”. However in this cartoon, the violence is its essence and has no other justification than to entertain the viewer; hence it is opposing the laid down code and could not have been broadcasted on a public channel during the day, and it explains why HTF was only published on cable TV. Its free spreading on the web was easier to happen and allowed it to get quickly popular.

The company who produce it now makes money from all goodies (DVDs, muppets, Tshirts, etc) sold. (Cold Hard Flash, 2005)

4.3.2.2 Salad Fingers

Figure 30 - Salad Fingers (Firth, nd)

Salad Fingers (Firth, not dated) is a flash-based web cartoon created in 2004 and which progressively gained interest onto 2005. It was presented at a festival in Australia in 2007 and fell into oblivion afterwards.

It owes its success to its very original nature: a psychological horror series featuring an ugly alien-like schizophrenic character who enjoys self mutilation, speaks to its Muppet when not to himself and sometimes kill people. The ambiance is made surrealistic because of the odd sequence of scenes: unrelated visions and events follow at the border between the reality and the hero’s hallucinations (Gaudino, 2005).

Flash allowed the cartoon to be quickly created by its creator (who was not at first an Flash specialist) and spread on Internet.

We might discuss its financial aspect and the marketing objectives of the creator. In Happy Tree Friends, goodies were sold and took benefit of its viral success; besides the series was maintained ever after its launch. The creator of Salad fingers, in


comparison claims in an interview that he was absolutely not money driven and did not even care about making a profit with his cartoon.

4.3.3 Games

According to this presentation from KGC 2009 (ICO partners, 2009), the estimated market size in Europe is:

● Over 30millions of free-to-play (F2P) online games players ● Over 400 games ● Estimated revenue: 400 to 500 billions of Euros per year

On the development of these online games, 70% are browser based (26% client based, 4% unknown). This introduction shows then how the online games market is huge and mostly browser based.

Figure 31 - Top F2P games: estimated active players in Europe (ICO partners, 2009)

According to the figure above (from the presentation), 5 of the 10 most played free-to-play browser-based games are Flash based.

All other games that are not Flash-based (but Runescape) are graphically static games - this means that you cannot move an object on an image; those games are consisting of forms where you might input the number of troops you want to train for example in a war-based game.

Hence Flash is used when there is a need for dynamic graphics, and high interactivity, which are key features of the most popular online browser-based F2P games.

But Flash is a proprietary technology and costs money. How those Free-to-Play games make money must be explained.

4.3.3.1 F2P games strategies to make money F2P games use similar techniques as blogs, social networks or other free-to-access websites. They make money by

• leading the user to buy products that are related to: o the game o its audience (male people from 15 to 25 years old)


o the profile of the player who might have given his preferences and personal information during the subscription process.

• Forcing the user to pay to remove an annoying promotional bar • Offering players to subscribe to a costly premium account to access extra

features which confer the player an advantage to his opponents: new items available, extra skills, access to new areas / mini-‐games / functionalities. There even might be stores with extra special items that you can buy individually.

Hence such games can generate money to enable the funding of Flash being the most powerful technology (and most accessible), to create immersive and very interactive experiences, the development of these games requires to be continuous: to get the players addicted, new quests, new items, new features must be offered day after day.

Finally this development may leads companies to buy the whole set from Adobe even though every product can be bought individually: because its platform is being particularly complete and its products complementary to each other, if Flash is used, Photoshop and Illustrator are likely to be used to design graphics, Premiere and After Effects to work on video, Fireworks and Dreamweaver to code websites, etc.

4.3.3.2 An example of successful free-to-play producer: Zynga ● Zynga and “FarmVille” on Facebook

Figure 32 - FarmVille (Lovell, 2010)

Zynga (Lovell, 2010) produces online F2P games, mostly dedicated to social networks like Facebook. Zynga games are played by 230millions players every month and their most popular game, Farmville, is played by 30 millions of users on Facebook, which represents 10% of all Facebook users.

“Zynga (and other successful F2P games producers) have found ways to make games that appeal to a broader cross-section of society than traditional approaches have ever done. They have done more to make games mass-market than anyone other than Nintendo. They are true mass-market of gaming.” Below are the reasons to this success (Lovell, 2009):

o -‐Those online social games are changing our relation to games. Contrary to traditional games on computers and console, they reach a global audience from all generations and both genders.

o -‐the game-‐play adapts to different types of users, from a weekly usage to daily usage or more.


o -‐as well, their pricing fits to different types of users so according to their usage, they can play freely or pay to get extra content.

o -‐Users just require a web-‐browser to access those games, no great hardware is needed.

o -‐These games are social and this players are sharing it and increasing its audience on their own.

o -‐These games, contrary to traditional games (like Sims, Call of Duty, etc), are not costly to develop.

Broadly speaking, the strategies are to get people to regularly play on the game and drive them to invite friends to participate. The key thing in Farmville is that the invitation process is masked: the more users depend on their friends to advance quickly (the more a game is social), the more they are intended to invite a maximum of people; here it consists of sending free valuable gifts to friends so that they send gifts to you in return (Lovell, 2009).

Zynga lists some of the reasons for choosing the Adobe platform (Oldrin, not dated):

○ ubiquity of Flash Player ○ Flash allows to create rich and hugely interactive web apps with high quality

graphics. ○ the platform is “common, stable and simple”

4.3.4 Advertisements

In the USA 40% of online advertisements are Flash based. Flash offers the opportunity to create ads consisting of rich media (images, video, animation) with interactivity and its authoring tool allows creating these dynamic advertisements very quickly (Lipsman, 2010).

Happy Tree Friends, FarmVille are examples of viral advertising. They use the web and its share-culture to spread hugely a product free to access at first. Money is then made from the very few who buy related products, extra features, etc. The turnover realised by HTF might be similar to the turnover of the most popular TV cartoons of the last decades. FarmVille is certainly more profitable than Activision Modern Warfare 2. They are easily spreading because they are also made with Flash that is ubiquitous as previously stated.

4.3.5 Custom Navigation / Full Flash Website

Flash can be used both to create a custom menu involving in-video, graphic effects or animation, and embed it in a website. Or it can even be fully used to create highly interactive websites.

The Favourite Website Awards (FWA) is, according to its own description, the most visited award program on the web (FWA, 2010). It offers awards to the best websites, every year, month and day according to their creativity, originality, design, content and personality, whatever their technology used is (Flash, HTML, XHTML, CSS, HTML5, Unity 3D, Away 3D, etc).

From the FWA were studied the best sites of the month from February to August 2010 and the best sites of the year for the years 2009, 2008 and 2007. A table at the end of this part is summarizing their purposes, types, key features and interaction


source types and they are described with more depth in the appendixes. Each row may consist of cells with coloured background or coloured text; this style only intended to make the table more readable.

Figure 33 - Lexus Dark Ride (Stink Digital, 2010)

4.3.5.1 Platform: Flash First concerning the technology used, despite the FWA interest in all web technologies, these websites of the month and of the year are all full-‐flash, their whole interface is embedded in a Flash object. But the FWA interface is full-‐flash as well though it might not be the best technology to use for this website; so the founders of the FWA website might also be ardent supporters of Flash and their opinion about what websites are the best, may be biaised. Nevertheless this bunch of websites is a showcase of some of the best Flash websites and it is interesting to see what are their assets.

4.3.5.2 Purpose The purpose of these websites is mostly to promote a product or a brand. Some are educative but may serve a museum or association purpose. Hence all these websites are business oriented and intend to bring new customers.

4.3.5.3 Type of website Most of them mainly focus on displaying high quality (HQ) video enhanced with graphic effects: this concerns the websites stated in this research as:

• “interactive movies” or “interactive video interviews”: they offer the user to manage the movie by making decisions that result in showing particular scenes.

• “multimedia websites”: they embed different medias (audio, text, video, animation) and offer the user to choose what content to watch.

The third type is games: as stated previously, most complex and interactive games are created with Flash; here some of the interactive movies embed mini games and the applications stated as “games” embed complex 3D animation.

So Flash websites intend to provide complex graphics (3D animation or 2D


animation) or video enhanced with interactivity.

4.3.5.4 Key Features Concerning the key features, most of them integrate HQ video and sometimes these videos are applied in live special filters and are interactive. Many of them integrate games or mini games with 3D animation. They may also be integrated with other web services (social networks) and are even able to embed foreign content into the displayed video (for example, show the user’s Facebook profile picture). The last feature shows the potential of Flash to make rich internet applications (RIA); for that research RIA were not observed, and by the way RIA are done with another platform of Adobe that uses Flash: Flex; anyway, Flash websites can integrate any web service or database and that makes it a very flexible platform.

4.3.5.5 Interaction Type The interaction types used to define these websites are described below and are associated with their number of occurrences (Sharp, 2007):

• Instructing (10): the user tells the system what to do, by pressing a button or a key, choosing an option or writing a string.

• Conversing (1): the user has a dialog with the system. • Manipulating (7): the user interacts with objects by dragging and

dropping them, moving his mouse to draw movements. • Exploring (3): the user moves through a virtual space.

Here instructing is used in all websites; in fact this is the basic interaction type that is used in general in static websites: the user has to click on a link to display a page, click on other buttons to display the page in full screen or print it, etc. So this is also obviously used in these websites to go to a different scene or page, select an option.

But what is interesting here and makes these full flash websites highly interactive is that they embed also other types of interaction; in fact only one website only consists of instructing and in that case, Flash was used for the whole interface to embed interactive video in its background.

Otherwise, most of these websites use the manipulating interaction type to make the animation more entertaining and sometimes simulate the real world: the viewer uses the cursor on an interactive video as if it was representing his hand and must avoid touching the lady’s body, another involves a car pursuit and the user controls his vehicle with arrows or the cursor and one of the other games requires the user to move troops on an arena (like on a chessboard).

A few of these websites involve virtual space where the user decides for example in what rooms of a house to go. Finally one website simulates the conversing interaction type: the user asks questions to people that they answer.


Title Purpose Type Key Features Interaction Type

perrier by dita (Ogilvy, 2010)

Promote a product

Interactive movie

High Quality (HQ) video; Filtered video ; Interactive video Mini games

Exploring Instructing Manipulating

Battle of Cheetos (Goodby, 2010)

Promote a product

Game 3D Animation; Multiplayer; Ranking System; Game

Instructing Manipulating

Louis Vuitton Journey: Legends (Ogilvy, 2010)

Promote a brand

Interactive Video Interview

HQ Video; Accessible video ; Interactive video ; post comments

Instructing Conversing

Lexus Dark Ride (Stink Digital, 2010)

Promote a product

Interactive movie HQ Video; 360° video ; Interactive video ; Social network Embedded ; Mini Games

Instructing Exploring Manipulating

BMW cinétique (Chewing Com, 2010)

Promote a product

Artistic authoring tool

3D Animation; Libraries; HQ video; Animation;

Manipulating Instructing

Bank Run Game (Silk Tricky, 2010)

Promote a product

Interactive movie HQ video; Interactive video ; Mini Games

Instructing Manipulating

Blue Bell Jeans (Kokokaka, 2010)

Promote a brand

Multimedia website

HQ video; Interactive video ; Galleries


We choose the moon (The Martin Agency, 2009)

Educative Multimedia website

HQ video; Interactive video; Audio files; Text;

Instructing

Ecodazo (Enjin Inc, 2008)

Educative educational application

3D Animation Exploring Instructing

Get the glass (Goodby, 2007)

Promote a brand

Board Game 3D Animation; Mini Games


Figure 34 - Full-Flash Websites Show Case

So these websites are a showcase of highly interactive and beautiful worldwide websites, they are all Flash-‐based and they are also professional and business-‐driven websites.


4.4 Impact of Flash on the Web It is very hard to find any article discussing what impact had Flash on the web. However by looking at its history and its current usage, some points can be figured out.

4.4.1 Origins of Flash and its evolution

To put it simply, in the beginnings of the web, only HTML was available to create websites (Owen, 2010). They only consisted of text and images and their layouts were not only hard to code but their rendering was disparate according to the different available web browsers.

In 1996 appeared Cascading Style Sheets (CSS) and JavaScript (JS). This was a revolution because the combination of HTML, CSS and JS allowed the development of websites with a true Model View Controller structure: the content and its organization were developed in HTML, their visual display in CSS and the logic and interaction embedded in JS. However it was hard to build consistent interfaces displayed the same way on all web-browsers and the capabilities in interaction were limited.

The same year, in 1996, a company called FutureWave and funded by Jonathan Gay got very high-profile clients that wanted to use its product: Future Splash Animator (Gay, not dated). Microsoft created wanted to create a sort of TV like experience on the web and lauched it due to that tool: MSN; Disney Online used Future Splash to build animation and the user interface of their website. At the end of this year, Macromedia bought FuturWave, acquired its product and re-branded it as Flash.

Future Splash (and latterly Flash) purpose was to embed other medias on the web (audio, video and animation), make them interactive and it involved a complete platform (Owen, 2010): An authoring tool was available for developers to build Flash files: create graphics, animate them, import video and compile the content into an individual file to embed in a HTML website; on the other hand viewers had to download and install a plug-in to read those Flash files.

From that year, Flash quickly became a must-have tool when creating animation and games for the web. And with its evolution, when it added video to its features in 2002 (Quick.tv, 2009), it became the leader technology to use video on the web.

4.4.2 Strengths of Flash

One of the reasons of this success is that Flash allowed the delivery of high quality graphics even on dial up slow connections (David, 2003): indeed Flash consists mostly of vector-format animation and files generated can be very small even though graphics are good. Besides the Flash creators always ensured that their Flash Player file size was under 1MB (Peachpite, 2006); in the ancient times of dial up connections with very slow downloading rates, this tiny size for a player may have made the difference.

Another strength was its programming language: ActionScript, easy and quick to learn and similar to the already language commonly used on the web for client side programming, JavaScript.


Flash is part of the Adobe suite and is therefore associated with other powerful authoring tools that if not leading in their fields, play a major role: Photoshop to draw pixel graphics, Illustrator to draw vector graphics, Fireworks to design a website layout, Dreamweaver to develop a website, Premiere to work on video, After-effects to enhance video with extra effects, etc (Adobe, not dated).

4.4.3 A big contributor to the web

Figure 35 - Major Flash releases: timeline (Media College, not dated) (Computer Literacy, not

dated)

Figure 36 - Major Flash releases: timeline (Computer Literacy, not dated) (Media College, not

dated)

As the timeline reveals it Flash evolved from a drawing and animation application to a powerful authoring tool that is integrated in a complete platform (Adobe suite) and that can create not only great websites that embed video and 3D animation but also complete RIA integrating other web services, with its own efficient programming language.

In conclusion, Flash contributed for the most part to enable on the web:


• Animation: to create TV cartoons, immersive advertisement or simply enhance a website’s beauty with animated drawings.

• Video and latterly high quality video: video portals (youtube), business-‐driven publishing platforms (hulu), video embedded on a private website or for advertising.

• Great Interaction: from the mouse and the keyboard to the webcam and multi-‐touch, developers can access every input available on the user’s device.

Finally Flash publishes cross platform content: whatever web-browser, whatever OS, whatever device a customer is using, a flash website will be available if the Flash player was installed.


5 HTML5, CSS3 and Flash. Comparison and potential Impact

To conclude on the research for this dissertation, the investigated technologies HTML5, CSS3 and Flash are compared in a first part and then their potential impact is explored.

5.1 Comparison of HTML5, CSS3 and Flash The research focused on similar points on both researches on HTML5/CSS3 and Flash:

• Accessibility • Integrated Music and Video • 2D animation > Cartoons • Games • Web applications

In this concluding chapter, the proprietary technology (Flash) and the new Web Standards (HTML5 and CSS3) are compared on each of those points.

5.1.1 Availability

First concerning their availability on Computers:

Flash has a penetration rate of 97% on computers and is ubiquitous (Adobe, 2010).

HTML5 and CSS3 features are not fully implemented in web-‐browsers, and the nature of implemented features depends on every browser.

Broadly at least 69% of all HTML5 features are developed in Firefox, Chrome and Safari that are 3 of the most popular web-‐browser (Deveria, A 2010). All of them implemented the most popular features that have been presented in this research for the development of animation, video and audio. The missing features are concerning the RIA development.

On the other hand, IE has implemented only 28% of HTML5 features up to now but extra JS libraries can be used to enable some of the missing features (Deveria, A 2010).

But browser vendors are actively working and by the end of 2011, 93% will have been implemented in Firefox, Chrome and Safari, and 54% in IE (Deveria, A 2010).

The situation for CSS3 is nearly the same as for HTML5.

So on this field, Flash is already leading the market; HTML5 and CSS3 need to be more fully implemented to represent a threat.

Secondly, on Mobile devices:


According to Adobe (2010), 40% of all new mobile phones access Flash. Besides Flash is at the moment banned by Apple on its iPhones and iPads.

Incorporated web browsers of all new mobile phones from Symbian, Android and Apple are based on the webkit engine (Grisby, J 2009). These companies own 79% of the market of smart phones (Refsnes, 2010). This is the engine of the current most advanced web browsers in HTML5 and CSS3 implementation: Chrome and Safari, so these incorporated web browsers are very likely to focus on the implementation of HTML5 features. As an example, the mobile version of Safari implemented 54% of HTML5 features and 85% of CSS3 features (Deveria, A 2010).

On that field, contrary to the position on computers, Flash has not great superiority and even if this market is for the moment leaded by native applications, the mobile businesses are highly expanding and there is room for HTML5 and CSS3.

5.1.2 Integrated Music and Video

On both Audio and Video fields, Flash is leading and is used on all most popular video and audio streaming portals. Around 75% of the video on the web is made with Flash (Allaire 2010).

HTML5 has APIs to deliver audio and video to the web and is implemented in all web browsers but IE. However browser vendors have not agreed yet on common codecs to use (Deep Blue Sky, 2010).

While there is not a unique audio codec and unique video codec that can be played on all web browsers, HTML5 cannot be used in businesses on those fields.

5.1.3 2D Animation

2D Animation can be used in advertisements, games, cartoons or simply to enhance a website. Cartoons can represent the most complex deal of graphics so they were looked at in this research.

Flash enabled 2D animation on the web from the start and is the leading technology in animation (Owen, 2010). Flash has such capability that some TV cartoons used it for their development.

HTML5 Canvas and CSS3 properties both provide APIs to draw graphics and animate them. But their performances need to be investigated and CSS3 features related to animation are only available in the webkit engine at the moment so it needs to be more broadly implemented. CSS3 by the way had much more popularity than HTML5 up to now and presents stunning samples.

5.1.4 Games

According to a figure presenting the 10 most played free-‐to-‐play and browser-‐bade games (ICO Partners, 2009), Flash is used whenever games require dynamic graphics and high interactivity.

HTML5 provides APIs to do 2D and 3D animation but their current performances are too poor to compete with Flash. However according to the sample of Quake 2 in the browser (Haustein, 2010), HTML5 has an enormous potential and will greatly benefit


of hardware acceleration once implemented.

5.1.5 Advertisements

Advertisements can consist of simple animated banners. At the moment Flash is ubiquitous on that field. As long as those banners do not require complex interactivity, CSS3 already provides the tools to create such animation but as it was stated above, CSS3 features must be more broadly implemented. In the long term, the combination of HTML5 and CSS3 may be a much better solution than Flash because their content is accessible (readable by search engines and impaired people) though Flash content is not.

5.1.6 Web Applications

Flash is nearly always used when a website requires great graphics and high interactivity according to the research on Flash and the study of full-‐flash websites. Regarding web applications, Flash can access all inputs, other web services, can be used offline and present great performances. But HTML5 also presents many interesting features dedicated to RIA and the already existing painting applications show that HTML5 web applications can present a great interactivity. Businesses may switch to HTML5 once its features will be fully implemented and their performances improved in the web browsers.

5.2 Potential Impact It will not be easy for HTML5 and CSS3 to take over Flash although Flash has been leading on their common field (animation, video, RIA) for more than a decade. In the first part the matters related to this shift are investigated.

Many authors tried to answer the question “are HTML5 and CSS3 going to kill Flash?”. The quick answer is “No” but requires more details. They are pointed out in the second part.

Finally what drives this war on words between web technologies is explained in the last part.

5.2.1 Shift from the ubiquitous platform Flash to the new web standards

5.2.1.1 Designed to facilitate the shift from proprietary technologies to web standards

The W3C learned from the difficulties they had with the implementation of the previous CSS and HTML versions (Zeldman 2010). Hence they designed the specifications of HTML5 and CSS3 so that they involve a list of modules that web browsers could implement individually. In fact, some major browser vendors started the work on these new specifications and brought all other browser vendors to involve and work together.

As a consequence, not only browser vendors no more need to implement the whole spec at once before releasing it, but it gives time for developers and designers to individually learn and master the different modules. Hence the shift from the previous versions to new ones will be progressive and made easier for the web industry. Browser vendors will be able to immediately figure out what


implementations are wrong, and since they are part of the group designing the specs, they will give feedback on what features are wrongly designed and the W3C group will be more likely to correct them with the agreement of other stake holders (browser vendors).

5.2.1.2 The industry-wide shift will not be quick Due to the already deployed infrastructure around Flash enabling advertising, it will take some time for industries to shift to an alternative not matters how good it is (Valdes 2010). But on a lower level, for smaller businesses using Flash for more basic features, the shift will be easier.

5.2.1.3 HTML5 and CSS3 need an authoring tool Adobe offers a very powerful What You See Is What You Get (WYSIWYG) tool for animation, Flash. And this is necessary when dealing with animation. To design quickly an appealing animation involving great graphics, designers obviously prefer to use authoring tools like Adobe’s Flash; as long as there will not be an equivalent tool for HTML5 and CSS3, coding an animation in HTML5 or CSS3 will take much more time and consequently be more costly than designing it with the proprietary tool of Flash.

But HTML5 and CSS3 being ultimately the future of the web: the Web giants Google, Mozilla, Opera, Apple are very actively working on implementing HTML5; Apple banning Flash from its mobile web (iPhone, iTouch, Ipad) and favouring HTML5; it is only a matter of time before Adobe, who is leading the designers’ application market, offers its authoring tool for HTML5 and CSS3 and drive others to build alternative solutions.

Adobe already produced an experimental editor for HTML5 and CSS3: “CSS3 Animation Editor” (Google, 2010). Adobe should most probably integrate HTML5 and CSS3 to its tool Flash to allow designers create their animation with Flash and then publish it in the format they prefer (html5 / CSS3 or Flash).

5.2.2 The future of HTML5, CSS3 and Flash

Can HTML5 and CSS3 kill Flash? Right now, they cannot. Meanwhile, in the long term, HTML5 and CSS3 could overcome Flash on some fields.

5.2.2.1 HTML5 and CSS3 for simple interactivity The majority of websites that exploit Flash uses it to display basic interactive content or animations (banner advertisements, galleries, splash pages) can shift to HTML5 and CSS3 (Valdes 2010). Charting, image transforms, video, audio, basic animation, limited 3D graphics could also be made with web-‐standards.

5.2.2.2 RIA technologies (Flash, Silverlight or Java) for richer interactivity HTML5 and CSS3 features cannot now compete with Flash on the field of RIA (or other RIA technologies such as Silverlight and JAVA) because Flash offers many other features that HTML5 and CSS3 may not ever have (Valdes 2010). Ray Valdes quotes for example Google that is using Flash in Google Maps for its Streetview and in Gmail for the multi-‐file upload.

“Extensive offline processing, direct manipulation of graphics, real-‐time notifications


and alerts, high-‐speed binary communication protocols, tight integration with local devices” still require using RIA technologies, depending on the context of development.

On the field of gaming, it will take long time for web-‐browsers to offer similar performances in HTML5/CSS3 that in Flash.

5.2.2.3 But HTML5 has also some potential on the field of RIA As presented in the literature review, many HTML5 features cover some of the components stated above required for RIA:

• Application Cache and Local and Session Storage for offline web applications.

• Web sockets for richer communication. • Workers and hardware acceleration for richer processing. • Notifications. • Geolocation, Webcam and microphone APIs to access local devices.

These more complex features may take more time to be fully implemented but in the long term they may offer a sufficient working subset to build web applications.

5.2.2.4 Businesses do not have to choose for a unique technology but for a hybrid solution

As many websites have been developed up to now with HTML and CSS for the layout and basic content and use Flash only for modules that require richer interactivity or graphics, businesses may probably use different technologies in their web applications (Valdes 2010). HTML and CSS scope widened with HTML5 and CSS3 but may not have the capability of building complete and complex RIA on their own yet. “In the long-‐term (5 to 10 years), HTML5 may fit the bill”.

5.2.3 A debate driven by interests of giants

There is a real war on words between developers, CEOs, evangelists about HTML5, Flash and native applications.

Most of this debate is not really driven by technical considerations but by the economical interests of dominant companies and HTML5 may have a serious impact on each of them (Allaire 2010):

• Apple aims to sell its multimedia devices (laptops, smart phones, tablets, mp3 players, etc) and online content (iTunes and app store).

• Google wants massive reach on its advertising platforms (Google adSense)and products (among them, the mobile Android OS).

• Adobe needs to drive businesses to use their platform and set of authoring tools.

• Microsoft intends to sell his core OS and business applications.

This leads in many tensions and competitions (Valdes, 2010): Apple vs Google on smart phones, Apple vs Adobe on Flash and the app store and Microsoft against every other one (vs Apple on multimedia devices, Google on advertising platforms and products, Adobe on RIA development platform).


The Apple vs Adobe conflict is described with more depth below.

5.2.3.1 Apple is badly spoiling Flash reputation According to Steve Jobs, flash is unreliable, unsafe, presents bad performances, consumes mobile phones’ battery life and is finally a technology from the past (Jobs 2010).

Apple banned Flash on its iPhones and iPads. Those products that might be revolutionary products that drove the development of smart phones and tablets and are highly popular in the technology business world (Apple is leading on application stores for mobile devices) (Shankland 2010).

This behaviour is damaging Flash and on the other hand promoting for the new web-‐standards and somehow driving their development.

But this Apple’s resistance is irrational, most of its criticism about Flash untruthful, might be leaded by Steve Jobs’s personal resentment on Adobe, and is most certainly driven for business purposes: Apple wants a tight control on its app store and does not want a third proprietary technology to take part in it (Valdes 2010).


6 Preliminaries to Implementation and Benchmarks

To start the practical work, it was necessary to try and experiment HTML5, CSS3 and Flash, so tutorials were used to learn them. In order to save the learning in HTML5 and CSS3, a website called “HTML5 and CSS3 Experiments” was published, embedding the tutorials carried out (Charlet, Home, 2010). This website an its learning are presented in the first part.

To start the benchmarking, some general guidelines were initially written and are described in the second part.

6.1 Experiments website and learning

Figure 37 - HTML5 & CSS3 Experiments: Home page

This website was created to:

• Make a showcase of HTML5 and CSS3 features • Save the work done from tutorials of HTML5 and CSS3 • Host the animations to benchmark

This website should be viewed using the last versions of Firefox, Chrome, Safari or Opera that enable most of HTML5 and CSS3 features used there. Some specific


graphics in the tutorial parts can only be viewed on particular web browsers and this is specified in those cases.

The source code used for the created graphics is not fully presented here but is on the disk provided with this report that contains all the code of this developed website. The purpose of this part is not to provide an exhaustive tutorial on HTML5 and CSS3, excellent already written tutorials take care of that, but to briefly show what can be done with those technologies. Most of the graphics drawn in this experiment website are direct copies of the graphics from tutorials, some of them present nonetheless differences and were practiced to train and learn the technologies.

The screenshots illustrating this part were made on Google Chrome 7 on Mac OS X.

The implementation of this website, the resources used and the learning are detailed in the next sub chapters: first is presented how the layout of the website was developed, then are detailed the pages dedicated to the HTML5 canvas and CSS3, and finally is described what was done in Flash.

6.1.1 Experiments.jcharlet.com: an HTML5 and CSS3 website

Bruce Lawson provides many tutorials to develop a basic HTML5 website (Lawson, 2010) and states in one of those what should be written to state the webpage as a HTML5 document.

In this part is presented how was created the layout of the experiments website: first its HTML5 structure, then its CSS3 visual style and finally some comments on the use of templates.

6.1.1.1 HTML5 elements, structure Otherwise to design the website, a comprehensive tutorial was used since it was presenting how to use the new HTML5 elements (that are also presented in the literature review) to prepare the layout and how to style it with CSS3(Kjaer, 2009).

The structure of the experiments website is:

<body>

<header></header>

<nav></nav>

<section id=”maincontent”><section>

<aside></aside>

<footer></footer>

</body>

The use of header, nav, aside and footer makes the code more comprehensive. header tags include the title of the website; the nav tags the navigation bar; the aside tags the sidebar, and the footer the end of page. These new tags force developers to code their websites in a sort of a universal structure. Hence this enhances accessibility: a screen reader for impaired people knows what is the purpose of the content within the nav or header tags.


6.1.1.2 Styled with CSS3 properties Some effects were created with CSS3 to enhance the visual aspect of the web site although they usually require loading a background image or adding some JavaScript code; so while users nowadays expect to see beautiful websites, these CSS3 features enable developers to create graphic effects directly in the browser and this saves bandwidth and processing.

6.1.1.2.1 Rounded corner Most apparent boxes have rounded corners: the buttons of the top navigation bar, the sections of the right sidebar and the titles of articles.

Figure 38 - Rounded corner on the title of articles

-webkit-border-radius: 15px;

-moz-border-radius: 15px;

6.1.1.2.2 Box shadow and glow effect The sections of the right sidebar have a bottom-left shadow and the buttons have a green glow effect applied on them.

Figure 39 - Glow effect on the button of the current page (2nd) and on mouse over (3rd)

Figure 40 - Shadow on the sidebar box

-moz-box-shadow:3px 3px 5px gray;

-webkit-box-shadow:3px 3px 5px gray;

box-shadow:3px 3px 5px gray;

6.1.1.2.3 Text shadow The title of the website included in the header “HTML5 & CSS3 Experiments” has a bottom-left shadow.

Figure 41 - Shadow on the header title

text-shadow: 5px 5px 2px #000000;

6.1.1.2.4 Gradients In the ToDoList web page, every feature presented is embedded in a rectangle box with a gradient background.

Figure 42 - Gradient background

background-image: -moz-linear-gradient(top, #000000, #222222);

background-image: -webkit-gradient(linear, left top, left bottom, color-stop(0.0, #000000), color-stop(1.0, #222222));

6.1.1.3 Templates with Adobe Dreamweaver This website was developed with Adobe Dreamweaver and embeds special comments that are readable in the source code but only used by the authoring tool:







The first line states that the document is using a template web page and defines its source; the two next lines start and end an editable part.

Using templates is very useful, almost imperative, because it prevents developers from not repeating code when they create new pages using a common layout; this way whenever the layout needs an update (change a link of the navigation bar for example), every webpage using the layout does not require to be updated but the template; this saves time and prevent from making mistakes in the update.

Hence in Dreamweaver, a template was created, based on the first web page developed and styled so that every time a new page was created, only its related content could be updated: the title of the webpage and its content.

The advantage of creating templates for HTML webpages using Integrated Development Environment (IDE) is that the IDE handles automatically the template and its related web pages. Hence whenever the template is updated and saved, the IDE


updates the webpages related to this template and asks the user whether he agrees to update them. So with this technique, once the webpages are loaded on a user web browser, the pages are already compiled and do not need some extra processing.

6.1.2 Tutorials on HTML5 Canvas

The canvas tutorial from the developer center of Mozilla is complete and is recommended to developers that want an exhaustive presentation of the HTML5 Canvas API (Mozilla, not dated). This tutorial was used and the following part dedicated to HTML5 graphics nearly presents the same structure as Mozilla tutorial. The first sub part “Basic Usage” used the code from the Mozilla dev center that is easy to read to briefly explain how a Canvas Graphic can be created in a web page. The following parts present screen shots from the experiments website and globally describe the functions that are available.

Others browser vendors developer centers also present interesting tutorials that are worth reading (Sucan, 2009).

Another tutorial was used to create a brick breaker game and have a look at the handling of inputs (keyboard, mouse) (Mill, not dated). In fact the interaction is handled by a JavaScript library (jQuery) and is not natively handled by HTML5 and its JavaScript API.

Finally while doing those tutorials, an exhaustive list of all JS functions dedicated of HTML5 was written to provide a help sheet for the development of the animations. This list is inserted in the appendixes.

6.1.2.1 Basic usage To start a drawing in a web page, the canvas tag must be embedded in the HTML5 web page (Mozilla, not dated):

<canvas id="tutorial" width="150" height="150"></canvas> A JavaScript file containing the drawing code must be linked in the web page or can be embedded in the HTML page within “<script>” tags. (nearly as it would be for a CSS style sheet file). The JavaScript file must at least contain the following code to ensure that the support for Canvas is checked in the web browser before trying to render it (Mozilla, not dated).

1. function draw() { 2. var canvas = document.getElementById('tutorial'); 3. if (canvas.getContext){ 4. var ctx = canvas.getContext('2d'); 5. // drawing code here 6. } else { 7. // canvas-‐unsupported code here 8. } 9. }

Finally, the drawing function must be called at the launch of the webpage, hence in the body tag of the HTML page (Mozilla, not dated):

1. <body onload="draw();">


The following code is a sample of canvas drawings (Mozilla, not dated).

Figure 43 - Basic Rectangles

2. <html> 3. <head> 4. <script type="application/javascript"> 5. function draw() { 6. var canvas = document.getElementById("canvas"); 7. if (canvas.getContext) { 8. var ctx = canvas.getContext("2d"); 9. 10. ctx.fillStyle = "rgb(200,0,0)"; 11. ctx.fillRect (10, 10, 55, 50); 12. 13. ctx.fillStyle = "rgba(0, 0, 200, 0.5)"; 14. ctx.fillRect (30, 30, 55, 50); 15. } 16. } 17. </script> 18. </head> 19. <body onload="draw();"> 20. <canvas id="canvas" width="150" height="150"></canvas> 21. </body> 22. </html>

On the 20th line, the canvas element is embedded in the HTML5 page.

From the 4th to the 17th line stands the JavaScript script and the drawing function “draw”.

On the 19th line, once the HTML page is loaded, the function stated by “onload” in the body tag is called. Hence the drawing function is called.

The “draw” function first accesses the Canvas element on the 6th line. Then it checks that the current web browser processing the web page supports the HTML5 Canvas on the 7th line.

On the 8th line, a variable called “ctx” is created and instances the context of the canvas, that manages the drawings: every time a specific drawing function of the Canvas JavaScript API has to be used, it must work on behalf of the context variable as it is shown right after.

On the 10th line the style is set: here it is the red colour. On the next line, a rectangle is created, using the previous stated colour and positioned at 30pixels from the left and from the right, with a width of 55pixels and a height of 50pixels.

6.1.2.2 Drawing shapes and Applying styles and colors The Canvas JavaScript API provides basic functions to draw all sorts of graphics.


Simple shapes as rectangles and disks can be drawn. But the most complicated drawings require creating paths consisting of lines, arcs, quadratic and Bezier curves. Once a path or a shape was prepared, it is drawn on the canvas by calling a function that either fill it or paint its strokes.

Before filling or stroking the shape or path, to apply a particular style (different from the default black colour), the designer must state the colour, gradient or transparency of the painting. If strokes are painted, he may define the line style and its width.

Figure 44 - Drawing shapes and applying styles and colours - first row

Figure 45 - Drawing shapes and applying styles and colours - second row

Figure 46 - Drawing shapes and applying styles and colours - last row

6.1.2.3 Using images Images can be imported in the Canvas to be manipulated, either by defining their link on the server or by picking an image already embedded in the web page.

Once imported, they can be positioned, scaled, drawn many different times, etc.


Figure 47 – Using images

6.1.2.4 Transformations Imported images or content created within the canvas can be transformed in many ways: by being translated, rotated, scaled or transformed using a transformation matrix.

Figure 48 - Transformations

6.1.2.5 Compositing Compositing consists in defining where to place or how to use new graphics or images within a canvas in comparison to already existing content. For example new graphics can be drawn above or below others, they can be used to get already existing light or darker, or they also can be used to crop other content.

Figure 49 - Compositing

6.1.2.6 Basic animations One pure animation was created using the Mozilla tutorial (not dated): a solar system, 2 planets rotate around the sun and one of them has a satellite. Contrary to the tutorial, the graphics were created using the Canvas API instead of importing images.

It involves many features: drawing gradients (the background, the planets, moon and sun), shapes with a varying opacity (shadow), basic shapes (planets, moon and sun), complex shapes made of paths (shadow).


The animation using a JavaScript function “setInterval” that allows to call repeatedly a function at a defined frame rate. Here the function called is handling the drawing; it also involves a timer that increments at every call so that the planets rotate around the sun every 0.1 seconds.

The second animation created is a little more advanced and is a traditional computer game: the brick breaker (Mill, not dated); the user moves with the keyboard or his mouse a paddle to prevent a moving ball to go below it; the ball bounces against bricks that disappear once touched.

As the solar system, it involves a timer and a setInterval function that manages the drawing and calculates at every frame where the ball is and whether it is touching anything to manage its reaction.

Its graphic rendering uses the canvas but most of the interactivity simply consists of JavaScript; however to manage the inputs, the JavaScript library jQuery was used.

This second animation was created to look at how to make a game with the canvas and how to manage the inputs but it was out the boundaries of the practical work required for this research. Finally the new HTML5 API does not handle any inputs at the moment so interactivity requires using already existing solutions (JavaScript or libraries for example).

Figure 50 - Solar System and Brick Breaker with HTML5 Canvas

6.1.2.7 Comments The Graphic Canvas API provides a set of JavaScript functions to draw graphics. Since the client-side language JavaScript handles the canvas, it means that the canvas can be made animated and interactive.

However the HTML5 Canvas was not meant to create animations so it presents limitations concerning animation: the biggest weakness is that there is not a Document Object Model (DOM) as in HTML where elements in a web page are organized into a hierarchy and individually accessible; all graphics are drawn on top of each other on the Canvas and unless the shapes are drawn in different canvas or somehow stored somewhere, the developer cannot access individually elements.

This presents two consequences if everything is drawn in a single canvas:


• For interactivity, graphics cannot be accessed individually and be made interactive.

• For animation, the canvas (and all its graphics) must be re-‐drawn at every frame.

The second point leads to a performance issue: if a canvas must be re-drawn to create animation, every shape must be re-drawn. So extra processing is used to re-draw the static shapes (that can be part of the background for example).

6.1.3 Tutorials on CSS3

Contrary to the HTML5 canvas, the CSS3 features consist of a set of individual modules. Hence each of these CSS3 properties are available or not on different web browsers. These CSS3 features are CSS3 properties that developers apply to elements in a HTML web page.

Rather to look at a tutorial, here it is more interesting to look separately at each of these properties to master them before combining them to draw graphics.

Some websites list for developers CSS3 properties with tutorials for each of them and were used to learn them (Webflux, not dated) (Mitchell, 2010).

The screenshots are usually from Chrome but some specific features are still not available on that browser, so some screenshots were done on Firefox instead.

The CSS3 properties are organized through those categories:

• CSS3 Borders • CSS3 Colouring • HTML5 Canvas vs CSS3: drawing graphics • CSS3 Text effects • CSS3 Backgrounds • CSS3 Transformations • CSS3 Transitions • CSS3 Animations

6.1.3.1 CSS3 Borders: Border Color, Border Image, Border Radius, Box Shadow, Outline

Several properties consist on visually enhancing boxes and their borders. The Border Radius and Box Shadow properties are the most important because rounded corners and shadows are very popular effects used by web designer and these CSS3 properties will prevent users from downloading background images to render them.


Figure 51 - CSS3 Borders

6.1.3.2 CSS3 Coloring: RGB/RGBA, HSL/HSLA, Gradients, Opacity Gradients and opacity are other effects very popular in Web Design that can now be created using only code due to CSS3 and prevent from using images. The repeating gradients are only available in Firefox.

Figure 52 - CSS3 Colouring - Firefox ScreenShot

6.1.3.3 HTML5 Canvas vs CSS3 The CSS3 tutorials were done after the HTML5 ones. So to compare both technologies, the most advanced graphic created in HTML5 was re-drawn with CSS3 and below are the two samples.

Figure 53 - Smiley face: HTML5 Canvas on the left - CSS3 on the right

HTML5 is on the left, pixel-based, CSS3 on the right, vector based. When the images are zoomed in, the CSS3 version looks the same but the HTML5 is pixelated so that the viewer can see the individual pixels that form the image.

It is easier to draw with CSS3 because of its nature and of the developer tools available (Firefox Firebug and Google Developer tools). There is no processing before the rendering of the page, as in JavaScript with the HTML5 Canvas. So CSS properties can be modified in the browser, in live with the developer tools. This way it


is far easier to place the elements of the smiley (eyes, head, mouth) and modify their style (change size, stroke size, color, opacity).

However to draw complex shapes consisting of polygons for example it is far more complicated in CSS3. In JavaScript with the Canvas API, paths can be created to form shapes. In CSS3, it requires gathering multiple boxes, defining their individual size and rotating them to simulate polygons. CSS3 purpose is to enhance visuals on a website, broadly to create text effects, add rounded corners and shadows to boxes of text, but not to create graphics.

6.1.3.4 CSS3 Text effects: @Font-face, Text Shadow, Text overflow, Text wrap, multiple Columns

Features allow adding shadow to a text and a special font. However here, the handwritten font is not displayed on the screenshot below. In fact the website should offer the user to download the special font but it does not; the font not being installed on the computer where the screenshot was made, another font is displayed by default. But this technique should work, the implementation here must be wrong.

Other features control how text is handled, according to the size of the box, and whether it is split in columns.

Figure 54 - CSS3 Text effects

6.1.3.5 CSS3 Backgrounds: Background Size, Multiple Backgrounds CSS3 adds controls to the management of background. Developers can now specify the size of a background image and its position.

Figure 55 - CSS3 Backgrounds

6.1.3.6 CSS3 Transformations Boxes can be transformed as it is presented below. This sort of effects is often used on mouse over: make the button bigger, move it or rotate it slightly.


Figure 56 - CSS3 Transformations: boxes by defaults

Figure 57 - CSS3 Transformations: transformed boxes

6.1.3.7 CSS3 Transitions CSS3 Transitions aim at creating animated transitions with only CSS3. Combined with CSS3 transformations (or other properties), these transitions make transformations more fluid. They allow for example to translate dynamically a box or dynamically change the color background of a box.

6.1.4 Tutorials on Flash

The tutorials on Flash are not described here because contrary to HTML5 and CSS3, I already learned Flash in one of my previous modules. Besides tutorials were quickly done and the work was not saved because these tutorials only helped to re-learn and get used to Flash basics and its authoring tool.

However the resources used are worth to be presented because they consist of very clear video tutorials from the Adobe team:

As for every new Adobe suite, Flash CS5 has around twenty videos dedicated to its learning from scratch (Perkins, 2010). This set of videos presents the Flash authoring tool, and teaches how to draw graphics, animation, use the available libraries and publish the Flash projects.

ActionScript, the scripting language of Flash, needs to be learned on its own because it is only vaguely presented in the general tutorials on Flash; a very complete set of videos present and teach ActionScript to beginners (Winnie, 2010).

6.1.5 Creation of a common animation: solar system

Finally the solar System animation created in the HTML5 Canvas tutorials was re-designed at the ends of the CSS3 and Flash tutorials in both technologies to have samples of a same object in the three different technologies to compare them. These three animations were used as the artefacts to analyze to answer the question “Can HTML5 and CSS3 kill Flash?”.


Figure 58 - Solar System: HTML5 Canvas + JavaScript - CSS3 + jQuery - Flash

6.2 Introduction to benchmarks The results to be obtained while measuring the performances of the animations cannot be absolutely accurate because computers run dozens of processes that can interfere with the measures. Hence the benchmarks are done in a not sealed environment and to compensate it, procedures must be taken to ensure the environment is the most consistent possible. For that reason guidelines were written to make it sure and are presented below.

The environment to look at is then explained.

Finally the elements to measure are described.

6.2.1 Guidelines to ensure that benchmarking of a website are done in the best conditions

• Make sure your computer is using as little CPU/Memory as possible while idling: use Memory Cleaner to clean regularly the system cache and trim processes working set; run antivirus and anti-‐spyware tools to make sure that no extra process is running.

• Quit all applications not necessary. • Once the benchmarking is started, empty history & cache of the browser

(CTL – MAJ – Suppr in Chrome and FF). • Only browse the webpage tested. • Every time the page must be refreshed, use CTL+F5 not to use the cache.

6.2.2 Where to do the benchmarking: on the most popular platforms

• On multiple hardware configurations: Computer, Netbook, Iphone/smartphone, Ipad/tablet

• On multiple OS: Windows (Win) 7, Win XP, MAC • On multiple browsers: Firefox, IE8, Chrome, IE7, Safari, Opera, (IE6)

Since the resources for this research was limited, benchmarks were only done on the available work environment. Hence for the biggest part of the research, an ASUS


laptop running Windows 7 was used; at the very end, a MacBook Pro running Mac OS X.

The web-browsers to look at are also limited at the moment of writing. The next generation of browsers to comes: IE 9, FF 4, Chrome 7 is expected to display more features and above all, their JS engines are expected to be enhanced. In other words, the web browsers that were tested for that dissertation are at an experimental level concerning HTML5 and CSS3 though the versions of theses browsers to be released in the up coming year are much more mature.

6.2.3 What to benchmark

• Load Time: how long the user waits to see an animation/website? • Frame rate (frames per second): how smooth is the animation? • CPU & Memory Usage: how much battery might the animation consume

on a mobile phone?

As stated above, results cannot be exact so only trends will be considered.

As an assumption, Flash already leading in animation should be at the moment the best technology to use. It should be rendered perfectly whatever web browser is used and present the best performances in terms of frame rate, loading time and memory usage.


7 Implementation & Benchmarks 1 The purpose of this first implementation and benchmark is to use the animation of the solar system created in HTML5, CSS3 and Flash in the previous chapter and define the load time of an animation of the solar system according to the technology used and according to the browser in which it is tested (Chrome, Firefox).

The three animations were isolated from the main website and inserted on individual web pages(Charlet, 2010) to be benchmarked. The tests were performed on Windows 7 Professional on an Asus G2S.

These Implementation and Benchmark chapters both consist of three sub chapters: first the implementation of the animation in the 3 different technologies is introduced, then the process and environment of the benchmarks is described and finally are presented the conclusions.

7.1 Implementation: Solar System

Figure 59 - Solar System Animation

7.1.1 Profile

DESCRIPTION: 2 planets are rotating around a Sun and on themselves. One of the planets has a satellite rotating around it. The canvas size is 100pixels * 100px

GRAPHICS: consists of simple shapes: circles and triangle shapes. Elements are filled with radial gradients. It does not embed images and does not consist of complex graphics therefore.

ANIMATION: infinite rotation of elements on themselves or around a referential.

INTERACTIVITY: none.


7.1.2 HTML 5 Canvas’s Implementation

Html file: 1.06 kb

JS file: 4.4 kb

This animation was developed using a tutorial for HTML5 Canvas and its graphics were enhanced with gradients. It seemed a little bit complicated at first because to create a rotation within another (moon rotating around the earth which is rotating around the sun), functions must be embedded into others and surrounded with save() and restore() functions.

Its API does not present DOM nor animation features, it is intended only to draw graphics. Hence using extra JavaScript code, a drawing function is called every 100ms to display the animation. But that also means that every graphic must be re-drawn, even those staying on the background, while drawing on a single canvas.

One solution to this DOM and unnecessary drawing would be to use multiple canvases, each of them representing one element.

Canvases are transparent so if a shape, that does not fully fill the canvas, is drawn, this canvas (A) can be placed on top of another canvas (B) (used as a background for example) and it will not display the borders of this canvas (A) but only its shape.

In that case it would require handling the animation between the canvas elements on the webpage; each element would be then represented by a single canvas, allowing the user to interact with them due to JavaScript (or libraries like jQuery).

7.1.3 CSS3’s Implementation

Html file: 1.5 kb

CSS3 file: 4.1kb

JS file: 1.2 kb

Extra JS file (jQuery library): 70.5 kb

It appears much simpler to work on because of its model: the elements or entities (HTML) are separated from their graphic style (CSS3 Style sheet) and from their animation (JavaScript file).

CSS3 intends to provide an API for styling elements on a webpage but it does not allow drawing shapes. Shapes are faked by using CSS3 attributes: here the circles are created by adding rounded corners to boxes. On this animation here, the triangle shapes of the shadow could not been created. But according to other CSS3 experiments, it seems possible to build complex shapes (Gallagher, not dated). A method could be:

• Create a main box • Add on top of this box as many required boxes (consisting of rotated

rectangle box with or without rounded corners) with filled background to “cut” shape on it.


Or

• Create as many boxes required to developing the shape and positioning them in absolute position

The first method would create a non-transparent shape. Both of them would lead to wasting time to create complex shapes.

The rendering of the rotating planets on Firefox 3.6 is inaccurate: they look squares with rendered corners while rotating though they look like perfect circles when being static. This bug is also present on Firefox 4 beta.

To create the rotation of the planets, every 100ms, the CSS attributes (rotate) are updated with the system’s time. To get it easier to code, jQuery JavaScript library was integrated and this library will get necessary once these animations will require interaction and get more complicated. However this library misleads the results of the benchmarks: although only one feature of this library is used (update css stylesheet), its file represents 91% of the total size of the animation, so at least 85% of the total size download to load the web page is not used. It obviously increases dramatically the load time of this web page.

Hence to get fairer results, either the required JavaScript functions should be extracted from the library or the animation created should be on a much bigger scale so that the size of the library becomes insignificant.

7.1.4 Flash’s Implementation

Html file: 1.2 kb

Flash SWF file: 16.2 kb (before update: 31.6kb, details explained below)

The learning curve for the authoring tool of Adobe, Flash, is much bigger than for the other technologies because developers need to adapt to a complete designer and animator tool which presents loads of features.

But as seen in the research on Flash, the potential to create RIA is massive.

Flash being the primary tool to create animation, and being the leader of the market on animation since animation exists on the web, it presents great performances and is fully integrated to our environment (present on all platforms and all browsers). CSS3 and HTML5 being in their implementation process, browsers do not still enhance their rendering at their best and are still working at improving it (as stated above, most browser vendors plan to release new versions of their browsers with better support of HTML5 and CSS3 features and improved JavaScript engines). So we can suppose that the rendering of the same animation with 50 planets for example will just render the same in Flash but will be laggy in new technologies. What is interesting to look at is:

• What are the current performances in HTML5 and CSS3 in comparison with Flash? Are they good enough to reasonably start developing complex animations?


• How the browsers will be improving it in the next generation of browsers?

7.2 Benchmarking Environment and Process

7.2.1 Browsers and Tools

The 3 animations of the solar system in HTML5 Canvas, CSS3 and Flash were tested on

• Chrome 6 (webkit engine) • Firefox 3.6 (Mozilla engine).

The load time of every GET request (and the total load time) was recorded using developer tools of both web browsers:

• Chrome Dev Tools for Chrome • Firebug extension for Firefox.

Chrome Dev Tools states the load time for each GET request and the total page load time.

Firebug states the load time for each GET request, the total page load time and the “onload” time; it also presents the DOMContentLoaded and onload events by blue and red lines on the timeline.

A website gives some explanation (Odvarko, 2009):

• The total page load time is the time from the beginning of the first request to the end of the last request. Sometimes this time is higher than the sum of all GET requests; this means that there were lag between the end of some request and the start of the next one.

• The “onload” time is the time required to trigger the “onload” event. 7.2.2 Process

The steps to benchmark the animations are:

• Open Web browser and empty History and Cache of the web browser • Load webpage containing the animation to test • Launch Developer Tool, activate and open Timeline Tab (Timeline on

Chrome – Network on Firebug) o Do this 20 times:

• Refresh the webpage (CTL + F5 on Windows) • Note the load time of each request + total load time.

Two batteries of tests were run:

1. The first ran this process on every animation on both browsers + 1 extra test on the Canvas animation on Firefox and 1 other on the Flash animation on Chrome with updates. o CANVAS Chrome 6 o CANVAS Firefox 3.6 o CANVAS Firefox 3.6 n2 o CSS3 Chrome 6


o CSS3 Firefox 3.6 o FLASH Chrome 6 o FLASH Chrome 6 n2 o FLASH Firefox 3.6

2. This process was run a second time on every animation on both browsers. • CANVAS Chrome 6 V2 • CANVAS Firefox 3.5 V2 • CSS3 Chrome 6 V2 • CSS3 Firefox 3.6 V2 • FLASH Chrome 6 V2 • FLASH Firefox 3.6 V2

7.2.3 Updates and quick findings while benchmarking

• CANVAS Firefox 3.6 & CANVAS Firefox 3.6 n2

On the first test, the process presented above was strictly followed.

On the second test, the history and cache was emptied at each test.

The average load time of the second test is bigger but considering the randomness of results and the results obtained on the same animation in the second battery of tests, it is hard to state whether the longer load time on the test n2 was affected by this change in the process or by the Internet. Hence this update was not maintained in the second battery of tests.

• FLASH Chrome 6 & FLASH Chrome 6 n2

On the first test, stars were drawn on the background of the Flash animation.

On the second test, these stars were removed and lead the Flash file to drop by half its size.

However it had no impact on the load time. This update was maintained in the second battery of tests.

7.3 Benchmarks and Findings

7.3.1 Loading Process and GET Requests handling

The first finding was to see how GET requests are handled, i.e. how the files are downloaded to display a webpage:

1. First the HTML file is downloaded 2. Then the files present in the header are downloaded in parallel (sometimes with

some lag between them): JavaScript files and CSS style sheets.


3. Once those files were downloaded, the “onload” function associated to the body tag (if exists) is called.

4. Finally the files within the body tags are downloaded: images, Flash files, etc

7.3.2 Randomness of results

The results are absolutely not static and vary considerably:

On the second (n°2) canvas test on Firefox, the difference between the shortest load time (78ms) and the longest (1860ms) is huge: from 13% to 310% of the average load time.

Considering the 3 canvas tests run on Firefox, the average load time goes from 253ms to 588ms: from 64.5% to 150% of their total average (392ms).

Figure 60 - Google Chrome Developer Tools - Load time


Figure 61 - Graph - Canvas Load Time

7.3.3 Tendencies observed despite the inequality of animations

The canvas animation is quicker than the Flash animation which is quicker than the Firefox animation.

However the results are biased by the profile of the CSS3 animation: as explained above, it includes a huge library though it only uses a tiny proportion of it.

Figure 62 - Graph - Total load time for all animations


7.3.4 These first benchmarks involved simplistic animations

This animation consists of only a few basic shapes (4circles and polygon with radial gradients) and basic animation: only one movement per element (infinite rotation) on 3 elements, only one scene and no interaction. But to judge on the capability of these technologies to create animation we must test them on much more complicated and power consuming animations.

7.3.5 Next Benchmarks

Hence to see how the browsers are rendering them and what are their performances, the next benchmarks will be run on an enhanced version of this animation involving 10, 20, 50 planets.

New parameters could be looked at as well:

The frame rate

In this set, every animation frame rate is fixed to 10fps: the drawing function is called every 100ms. It may be interesting to investigate whether the browser are indeed rendering them at that fixed speed or they actually present a lower frame rate. The frame rate could be also tested (render the animation at 10, 20, 50, 100fps) to see what its limits are.

The CPU & memory consuming

Measuring the CPU and memory usage arises some questions:

• how to measure it: look into the task manager, use dev tools or system tools?

• how to ensure that we are measuring the memory consumed only by the animation? How to compare the results obtained in both browsers? What if at idle state, their power consuming is not the same? Shall we compare the difference of data or their ratios (against what)?


8 Implementation and Benchmarks 2 The original animation was enhanced for this benchmark:

Its purpose is to define for each animation of the solar system in both Chrome and Firefox on Windows 7:

• The load time (as it was done previously). • The maximum frame rate. • The CPU and Memory Usage: how much power do these animations consume?

8.1 Object: enhanced Solar System

Figure 63 - Enhanced Solar System animation

8.1.1 What is new in this second set of animations?

• There are forty planets animated on a 1000pixels*1000px canvas. The purpose of this enhanced animation was to push the 3 different technologies to their boundaries by making them process a much bigger number of planets on a bigger canvas.

• A frame rate setter and tracker were added to each animation. • The frame rate is directly related to the rotation speed of planets. By the

way, as seen in the previous animation, the frame rate of 10 frames per second is not quick enough to get the rotation smooth so it needed to be easily increased.

• The frame tracker was developed to display the real frame rate of the animation and aimed to identify its limits.

The new aspects specific to each animation are detailed below.


8.1.2 HTML 5 Canvas’s Implementation

Html file: 2.37 kb (1.06 kb for the original 1st animation)

JS file: 10.72 kb (4.4 kb for the original 1st animation)

8.1.2.1 From hard to proper coding To create dynamically 40 planets and rotate them though every thing is created with Java Script, it was necessary to organize perfectly the code into functions immediately accessible.

Hence to create a planet and add it to the canvas, here is the code:

createPlanet(context, rotationAngle, distanceFromOrigin, radius, hue, satteliteBoolean)

Similar functions (that the createPlanet function includes) were created to create a satellite, a shadow, the background and a grid.

8.1.2.2 Frame Rate Setter & Tracker New functions were added to set and track the frame rate. The setter was straightforward; it only required stopping the animation and starting it once again using the new frame rate stated.

The second was made using a simple algorithm found on forums: the aim was to measure the time spent between two calls of the drawing function and convert this time delay into a frame rate. This frame rate was displayed on the page but hard to read when unstable; so an average frame rate was also displayed, using the first 100 real frame rates calculated.

8.1.2.3 Mistakes The original JS file was improved by writing directly on it, adding to it the functions specific to the new animation (of the second set); this was a mistake for three reasons:

• The code of the first animation was modified and its original version lost. • Both animations (original and enhanced) involve unnecessary code:

functions specific to each animation like the drawing function. • I wasted time ensuring that both animations were not disturbing one

another (global variables, functions related to buttons).

However the repercussions on the benchmarks on this 2nd set were negligible: the extra lines of code specific to the original animation represent a minor part of the total code (25 lines out of around 350 lines of code).

If benchmarks were to be made on the original animation though, it would need to clean the code specific to the enhanced animation that is much larger. The results would still be roughly similar that on the 1st benchmarks since the code of all animations was enhanced.

The original code could have been saved by versioning the websites (with a tool like Subversion). Above all this 2nd set of animations should have been written from scratch on new files.


8.1.3 CSS3’s Implementations

Html file: 13,05 kb (1.5 kb for the original 1st animation)

CSS3 file: 17,06 kb (4.1kb for the original 1st animation)

JS file: 7,75 kb (1.2 kb for the original 1st animation)

Extra JS file (jQuery library): 70.5 kb

8.1.3.1 Extra CSS3 animation without jQuery For the CSS3 technology, two animations were created: a version with jQuery (as the original) and another without jQuery.

Finding how to natively modify the CSS properties of HTML elements was not easy:

• The first and second versions of the animation without jQuery involved snippets of code adding CSS to the page and removing it. These solutions would have been acceptable if the CSS had to be occasionally updated; but here the CSS is updated at least 10 times per second to simulate animation and therefore these solutions presented very poor performances: the animation was lagging.

• The third solution consists of using the DOM and modifying attributes of elements on the page. This solution does not require emptying or cleaning the already existing CSS properties, it replaces the previous one. This solution presented better performances and was finally used for the benchmarks.

8.1.3.2 Frame Rate setter & tracker The frame rate setters and trackers in JS were used in both Canvas & CSS3 animations. See above for more details.

8.1.3.3 Big HTML5 & CSS3 files: planets not dynamically created The coding of the HTML and CSS files is similar to the coding of the original CSS3 animation:

The HTML file embeds as many containers of planets as there are planets. It results in a big file size.

The style sheet (in the CSS file) was optimized as much as possible: the background, the look of planets and satellites, the position of satellites in relation to their home planets was centralized in classes. But the exact position of each planet compared with the position of the sun and their tint had to be detailed for each planet.

The planets were not created dynamically with JavaScript for those below reasons:

• It seemed more logical from a developer’s perspective to keep the HTML/CSS/JS model right: elements listed in HTML, styled in CSS and processed (animated) in JS. This way, the code is easier to read and therefore easier to update.


• It would have improved the load time of the animation but it might also have affected the frame rate and CPU usage by adding more processing for the animation.

• It would have required time to understand how to code it though it was not worth the time and effort.

8.1.3.4 One single JS file for 3 animations (original CSS3, CSS3 enhanced, CSS3 enhanced without jQuery)

The same mistake was done with the CSS3 file: instead of creating individual JS files for every animation, one single JS file was used for the 3 CSS animations. However its size is relatively small compared to other files (20% of total size in the animation without jQuery, 7% of total size with jQuery). But this is more serious than for the canvas, the JS file size could have been reduced by more than half for the new animations tested and it would have reduced the time load. Nevertheless it should not have had any impact on the frame rate and CPU usage.

8.1.4 FLASH’s Implementation

Html file: 1.68 kb (1.2 kb before)

Flash SWF file: 7.3 kb (16.2 kb before)

As already stated Flash is a very powerful tool but it has a huge learning curve. Unless Flash is mastered, it is hard to create quickly with it what is wanted; there are so many features and so many options to create an animation that is also hard to know what is the best solution to choose in a particular case.

After several attempts to create the animation as previously, using only the GUI, and failing to do it – the aim was to create one symbol of a planet rotating around the sun, and then create many instances of it by changing its tint and distance in relation with the sun-, it was decided to use action script with the GUI for those reasons:

• With the GUI were created symbols of the satellite, the shadow and of a black and white planet sample.

• From this clips were created for every planet, adding color to its shape, the shadow and a moon if required.

• Every clip was inserted and animated with Action Script.

Both the GUI and Action Script were used, instead of only Action Script, for those below reasons:

• The GUI is one of the main strengths of Flash and allows creating complex shapes very easily; it was then appropriate to use it.

• Most of the clips have already been created for the first animation and it would have been a waste not to use them.

• It is stated on a forum that the drawing API of Flash was weak… But the reference of this statement was not found back at the moment of writing this part. Hence I based my opinion on this though I just figured out that


most of the drawing functions (lineTo, moveTo, fillStyle, etc) were similar (if not identical) to the Canvas Graphic API.

Hence the flash animation could have been improved. But the results anyway already show the great superiority of Flash on other technologies.

8.2 Benchmarking Environment and Process

8.2.1 Process

(see I. Preliminaries above for more details)

The same process was followed to measure the load time of pages though an extra animation was tested (CSS3 without Jquery). The animations were tested two times on each browser.

To define the maximum frame rate, the animations were enhanced with frame rate trackers (to display the actual frame rate) and frame rate selectors. Here is the process followed to define the maximum frame rate:

• Run the animation in normal size and place it in the middle of the screen so that most of the animation is displayed on the screen -‐ around 50 pixels above and below the animation were off the screen; but since the planets were still always displayed on the screen, it could not seriously affect the results.

• Set the frame rate to 100fps. • Identify the average maximum frame rate. • Set the frame rate to this identified average and ensure that the frame

rate is stable. Otherwise decrease it. • Redo it three times.

To define the CPU Usage and Memory Usage, here is the process followed:

• Quit all applications. • Trim processes and Memory. • Open web-‐browser and go to www.Google.com -‐ being a static webpage, it

does not consume any CPU or Memory. • Find its process in Process Explorer and look at its details (to start

recording it). • Launch Animation to record and wait for 60seconds to get the output

stable. • Increase the frame rate by 5 and wait 30/60seconds. Do it until the

maximum frame rate is reached.

8.2.2 Browsers and Tools

The same browsers were tested and the same tools were used to measure the load time.

The frame rate trackers and setters were built in the animations.


An extra tool was used to measure the CPU and Memory Usage: Process Explorer.

It displays all processes running and allows to look after a particular process. It is an enhanced version of the classic Tasks Manager from Windows. Its only drawback is that it cannot record the data on a text file to import it afterwards on Excel for example; although it could have been useful to get accurate average numbers. Hence for this benchmark, the graphs were watched while the animations were running, the resulting CPU and Memory usages written down on a notepad and summary graphs done on Excel from these written data.

Figure 65 - Process Explorer - Details of a process

The figure above presents the sort of graph that Process Explorer outputs. Here the Chrome process of the window where animations were displayed is represented.

Figure 64 - Process Explorer - Main Window


• The first line represents the CPU Usage from 0 to 100% of total CPU usage.

• The second line represents the Memory Usage. Its scale changes in function of the maximum memory usage recorded on one session.

• The third line represents the output recorded. Every time the user presses a keyboard or mouse key, an event is fired and is recorded on this line.

The orange column represents the output of the animation in HTML5 Canvas, the second green column CSS3 and the third purple one: CSS3 with jQuery.

Flash requires another process to be launched and could not appear then in the same window. Anyway this is just a sample to give a quick overview of the software and the behaving of those animations.

8.2.3 quick findings while benchmarking

Does FF reset the Cache?

• First the load times on Firefox equaled half the load times on Chrome. • While looking carefully on the load times for every request, it sometimes

appeared that there were no download time for the CSS3 file (but a awaiting response time) while there was such download time for the HTML file. However the HTML file being smaller than the CSS3 file such findings are suspicious.

Hence an extra set of benchmarks was done on Firefox (between the 1st and the 2nd set) following the below precautions:

• Disable auto cache in Firefox: type in the address bar about:config and disable autoCache.

• Clear the cache every time by closing and opening Firefox

But the same load times were obtained and the results are similar to those obtained on Chrome. Here can be simply stated that Firefox is much quicker than Chrome, considering load times!

8.3 Benchmarks and Findings

8.3.1 Load Time: several findings

• It is clearly a waste to use jQuery here. • Load times of Canvas, pure CSS3 & JS and Flash are roughly the same, it

depends on the web browser used: Flash is slower than others in Chrome but faster in Firefox.

• Although the CSS3 total size is bigger to Flash and Canvas sizes (at least 3 times more), its load time is just equivalent. Hence the load time of a webpage does not only consist of downloading files but also of processing


its code. From this point of view it is therefore not a weakness to have big HTML & CSS files as long as the JavaScript processing is low.

• The load time of Flash on Chrome is slightly bigger than the load times of Canvas and CSS3 and this is surprising. It may be due to the Action Script processing.

Figure 66 - Total Size of animations

from Benchmark 1 & Benchmark 2

Figure 67 - Average Load Time for animations

from Benchmark 1 & Benchmark 2

8.3.2 Frame Rate: Flash largely wins but there is hope for Canvas

In both web browsers Flash reaches the 50/60 frames per second though all other animations are limited by around 11 frames per second which is not enough to get a smooth animation.

Still the canvas on Google Chrome reaches 25frames per second (and after new attempts 24fps on Safari with Mac OS X). Although the web browsers used here are of the experimenting generation: they were the first to implement HTML5 & CSS3. The next generation to come might then present much better results.

CSS3 presents slightly better performances on Chrome but its performances are still poor.


Figure 68 - Maximum framerate for all animations

8.3.3 CPU Usage: as above, Flash wins and Canvas needs to get improved

The canvas CPU Usage doubles Flash CPU usage and this is critical for mobile applications. Although Steeve Jobs stated that Flash was highly consuming and HTML5 was the new solution for mobile web, it is clearly not the case yet (Jobs, 2010).

The CSS3 CPU Usage is far too high. While the frame rate is poor and sticks to 10fps, its CPU Usage (for both CSS3 animations) is the highest of all even if its JS file is very small in size. This might mean that accessing the DOM is highly consuming.

Figure 69 - CPU Usage for all animations

8.3.4 Memory Usage

Two benchmarks were performed to measure the memory usage:


The first benchmark was measuring at the same time the CPU and Memory Usage (MU). The results were sufficient to analyse the CPU Usage but not the MU.

A second benchmark focused only on the MU and was performed in the same conditions, using the same tools and processes, on another laptop: a Macbook Pro with Win7. Every animation’s MU was recorded with a frame rate equal to 10fps, and for 300 seconds.

8.3.4.1 Graphs

Figure 70 - Chrome Canvas Memory Usage

Figure 71 - Chrome Memory Usage


Figure 72 - Firefox Memory Usage

8.3.4.2 First Comments

8.3.4.2.1 On Chrome: The Canvas Memory Usage (MU) is huge, far above the MU of other animations on both web browsers. It presents a sawtooth (ramps upwards then sharply drops) wave ever increasing in period and amplitude.

The CSS3 + jQuery takes time to get stable and then presents a sawtooth wave.

The CSS3 wave is not periodic and keeps increasing. Its shape however looks very similar to the beginning of CSS3 + jQuery’ wave, before it gets stable. It may be the same kind of wave but with a timeline five times bigger and amplitude 1.4 bigger.

The Flash wave is perfectly regular and stable in amplitude and period. It looks like a sawtooth wave.

8.3.4.3 On Firefox All MU records look like sawtooth waves with regular period and amplitude. They also present bigger Memory Usages (but on Canvas).

The CSS3 and CSS3 + jQuery waves increase ramp upwards after a certain amount of time (200 and 225 seconds) and then get stable.

The CSS3 wave has a first peak at 50MB then a second peak at 35MB then starts again.

The Flash wave is perfectly similar to to the Flash wave for the animation on Chrome.


When Stable ( Period (s)

Time to get Stable (s)

Amplitude (MB)

Maximum (MB)

Chrome CSS3 + jQuery

40 100 3 38

Chrome Flash 84 20 1.5 18

Firefox Canvas 19 15 10 60

Firefox CSS3 58 20 25 50

Firefox CSS3 + jQuery

13.2 10 36 74

FF CSS + jQ 2nd part 15.8 45 90

Firefox Flash 77 30 1 17

Figure 73 - Period and Amplitude of stable waves

8.3.4.4 Analysis

8.3.4.4.1 Explanation of the apparently bigger memory usage on Firefox This is due to the process architecture of Chrome and Firefox:

• Single process model on Firefox: one process for the whole application; every tab, the Firefox engine, the extension manager, all features of Firefox are being contained in one single process but the plug-‐in. When Flash is used a “plug-‐in container” process is created.

• Multi process model on Chrome: to enhance the security and stability of its web browser, Google allocates one process per task so that if a task crashes, it does not make the whole application fail since it is being isolated; therefore every tab has its own process.(Google, 2008)

Therefore when the MU of the animations are recorded on the Chrome process, only its rendering is recording although in Firefox, the MU of all other tasks of the web-browser is observed. This explains why on Firefox the MU waves of the non-plug-in-based animations start at the same amount: MU=26MB and this may be the idle Memory Usage of FIrefox. This explains also why the Flash MU wave is not: it is isolated in an extra plug-in container process. If we compare the maximum MU of the only non-plug-in based animation that has a stable period and amplitude (CSS3 + jQuery), we find out that:

Firefox CSS3+jQ maximum MU (74MB) - Firefox idle MU (26MB) =

Chrome CSS3+jQ maximum MU (38MB)

And this confirms the assumption.


8.3.4.4.2 Stable waves in Firefox versus unexpected results on Chrome While all waves are mostly stable and regular on Firefox, on Chrome, one wave presents a memory leak (explained below), another takes much time to get stable and the third one never gets stable. All the animations concerned involve JavaScript so the Google Chrome Javascript engine is responsible for it.

The handling of the update of the position of planets (setTimeOut) and the frame rate tracker function are the same on Canvas and CSS3 animations altough it does not prevent the CSS3+jQ animation to present stable results. So the drawing function using the graphic Canvas API (on the Canvas), and the JavaScript function to access the DOM (in CSS3) are responsible for those results.

On the Chrome Canvas MU and on the Chrome CSS3 MU can be observed the symptoms of a memory leak: a memory leak occurs when some memory is allocated to an application but never freed; it causes the application (or its process) to use more and more memory (Microsoft, 2006). Here the wave representing the Chrome Canvas MU is a sawtooth wave ever increasing in period and amplitude and the one representing the CSS3 MU is simply always ramping up.

Memory leaks in JavaScript are a common known issue and many patterns of JavaScript Code can be responsible(Abhijeet Bhattacharya, 2007). However in that case, it is hard to know whether there is actually a memory leak or the animation takes much more time to get stable; as previously stated, its wave looks very like the same as CSS3+jQ beginning wave.

A simple hypothesis for the Canvas could be that every time the canvas is drawn, the process keeps it in its memory; so when the canvas is drawn an extra time, the process allocates new memory for it instead of replacing the previous memory used.

8.3.5 Unsuitable CSS3 design on animation

A choice was made while creating the CSS3 version of the solar system on how to manage its animation: either to use JavaScript or (jQuery), as for the HTML5 Canvas sample, or to animate it only with CSS3.

There are two ways of handling animation with pure CSS3 properties:

• CSS3 transitions • CSS3 animations

CSS3 transitions were already presented and allow property changes occur smoothly and according to a specified duration. So they can animate objects, if a proper property is used, but not on an infinite process and it is complicated to manage an animation through a list of steps. This feature is already implemented in Chrome, Safari, Opera and in the beta version of Firefox 4.

CSS3 animations on the other hand really intends to fully manage animation but this feature is only available in webkit-based browsers Chrome and Safari and is apparently not intended to be implemented in the next versions of the competing web-browsers.

However to get this research consistent, the animations had to be tested on several highly popular web browsers, not on a single web browser or web engine, and on


stable versions (not in development). For that reason Chrome 7 and Firefox 3.6 were chosen, and animations had to work on these web browsers. Since CSS3 transitions and animations were not available on these two browsers, the other last solution was chosen to animate the CSS3 sample: JavaScript.

But CSS3 animation, once implemented, will certainly be made of CSS3 transition and animation properties and will not require using JavaScript. Hence the results of the CSS3 animation are biased because the animation should be handled only with CSS3. Anyway all results are intended to be outdated in the upcoming months or year with the next versions of web browsers.


9 Conclusion To conclude, the findings of this study are first summarized. Then guidelines are offered to developers to guide them in their use of HTML5 and CSS3. After that, suppositions are made on the future of HTML5, CSS3 and Flash in five years. Finally as an evaluation of this work, its strengths, weaknesses, challenges and the personal learning are presented.

9.1 Summary of the findings Here are summarized the findings of the investigation, implementation and testing chapters.

9.1.1 Research on HTML5, CSS3 and Flash

Flash is already ubiquitous on computers, and HTML5 and CSS3 are only partially available. However on mobile devices Flash lacks support and HTML5 and CSS3 may represent a bigger threat.

Until web browser vendors agree on a common and unique video codec, HTML5 video will not replace Flash.

HTML5 Canvas and CSS3 present a great potential for animation but their rendering must be optimized, their features more broadly available and hardware accelerating must be enabled. They will make their way in advertisement only when the industry will have globally integrated these technologies.

Concerning RIA and games, not enough features are available and the JavaScript engines are not optimized enough on web browsers.

Finally it is a little bit too soon for businesses to invest in HTML5 and CSS3 but to create simple HTML/CSS websites. Flash still stands for instance as the leader to use in animation, video and for highly interactive web applications.

9.1.2 Implementation

The HTML5 Canvas is meant to draw graphics but not to animate them; besides there is no hierarchy or DOM in the elements created, they are simply drawn onto the canvas and this presents some drawbacks:

• It is difficult to access a specific element within the canvas and makes the management of interaction and animation complicated.

• There is no accessibility. • To create an animation, it requires continuously re-‐drawing the canvas,

even the static objects, so its rendering requires extra unnecessary processing.

CSS3 on the other hand is not intending to draw graphics but simply to style layout elements. However for that animation involving disks and gradients and no complex


shape, it was easy to develop. The CSS3 properties are applied to elements of the HTML5 document so it is easy to structure the graphics and to access specific elements for interaction or animation.

At first, animation was handled with jQuery but this was not necessary and could be done with simple JavaScript; however this design involving JavaScript is incorrect since CSS3 has properties dedicated to animation. However these properties are not yet implemented in Firefox and this is why JavaScript was used instead.

Finally the creation of this animation on Flash was actually the hardest. Flash is a very powerful tool that involves plenty of features, presents a graphic user interface to draw graphics and animate them and also involves its own programming language; but on the other hand it is still complex for beginners and it presents a big learning curve while HTML5 and CSS3, that involve only a list of properties and functions, do not. However once mastered, highly interactive animations and web applications can be created with Flash.

9.1.3 Benchmarks

The first benchmarks helped to understand how the load time of pages was counted (it involves the downloading of the files and their rendering), demonstrated the randomness of results and identified some weaknesses to correct for the second benchmarks: get rid of jQuery on the CSS3 animation, use Action Script in Flash, make the animation more complex with many more planets to scale up differences and measure other interesting parameters: frame rate and CPU and Memory usage.

The conclusions to consider come then from the second benchmarks where all three animations had to be optimized.

The animations approximately take the same time to load.

Flash largely presents bigger frame rates than HTML5 and CSS3. Still the HTML5 animation can have a very decent frame rate. The CSS3 animation on the other hand presents a poor frame rate and lags.

Flash is the least consuming in CPU usage; CPU usage for HTML5 animation dramatically increases when frame rate grows; lastly the CSS3 animation presents a very high CPU usage even at its low frame rate.

The memory usage is harder to analyse. Still it shows that web browsers have unequally implemented HTML5 and CSS3 features: while all results on Firefox are slightly stable, on Chrome there are serious memory leaks while processing HTML5 and the handling of CSS3 is weird. Otherwise Flash consumes less memory than CSS3 that consume less than HTML5.

Finally Flash clearly surpasses HTML5 and CSS3 in frame rate and CPU usage that are the two most important criteria. But the web-browsers tested have only implemented HTML5 and CSS3 on an experimental level and the performances for these two new technologies will surely evolve in the next year(s).


9.2 Guidelines for developers These guidelines are intended to all developers that already use HTML 4 and CSS 2 in their works.

They are mainly advised to use the new versions HTML5 and CSS3 for two reasons:

• To adapt progressively to HTML5 and CSS3 while new features are made available.

• To lead the industry to shift from the previous versions to these new ones, even though they are still in development, to take benefit of their revolutionary features that are for most of them already available.

9.2.1 Start using HTML5 and CSS3

Stop trying to get websites look exactly the same on every web browser, start using HTML5 and CSS3 now and ensure they degrade de-gracefully in web browsers.

Use others’ work to simplify your development: follow good practices, use HTML5 and CSS3 templates, download and print CSS3 properties sheets, install plug-ins to enable HTML5 and CSS3 in your IDE if available.

If necessary, use libraries to make them work in IE despite reduced performances.

9.2.2 Use HTML5 and CSS3 for simple HTML/CSS websites

Use HTML5 documents and its elements or at least, use the structure of HTML5 documents and name your elements accordingly (“header”, “footer”, “nav”, “section”, “article”, etc) to make the later update easier.

Style websites with CSS3 and start saving bandwidth (instead of using images), get rid of JavaScript for simple effects. Concerning experimental properties, developers should ensure they implement all available specific browser vendor properties (-webkit-, -moz-, -opera-).

9.2.3 Carry on using Flash for animation, video, high interactivity and RIA

It is right now too soon to use HTML5 or CSS3 in those fields. So businesses should go on using Flash to create animations, advertising banners, video.

Concerning highly interactive applications and RIA, Flash is very probably going to stand as a leader on those fields for the upcoming years.

9.2.4 Check HTML5 and CSS3 evolution

Check their evolution because the following points or events could happen in the next year(s) and may upset the balance.

Adobe could deliver an authoring tool to create CSS3 Animation.

Browser vendors could agree on a unique video codec.


The next generation of web browsers could present remarkable performances in HTML5 and enable valuable HTML5 features for RIA and CSS3 features for animation.

9.3 The future of HTML5, CSS3 and Flash in five years time Most important HTML5 and CSS3 features should be globally available on the web and hardware acceleration should be enabled.

Authoring tools should be available to produce animation with CSS3 or HTML5 Canvas; Adobe will have certainly delivered a new authoring tool or allowed Flash authoring tool to publish content in HTML5 or CSS3. CSS3 Animation may replace Flash on the web for basic animation: slideshows and photo galleries, advertisement banners, websites enhancement. This is very likely because HTML5 content styled with CSS3 is perfectly accessible (for search engines among others).

If web giants agreed on a unique codec to use, video should be globally displayed with HTML5.

The future of games, highly interactive animations and videos is however blurred. It depends whether the JavaScript engines will be optimized enough to equal Flash performances and if similar level of interactivity can be obtained.

For the moment, people mostly use native applications on their smart phones. Are HTML5 and CSS3, that drive web giants to work together on offering a similar experience on all web browsers, and offer therefore a cross-platform technology, going to gain some market share in the development of applications for mobile phones? If websites offer better experience due to HTML5 and CSS3, users may shift from native applications to browsed websites.

Concerning the development of RIAs, business should choose hybrid solutions involving HTML5, Flash, Java, Silverlight, and other technologies.

9.4 Evaluation of this study

9.4.1 Weaknesses of this work

Most of the missing parts or points detailed below were intended to be included in this report.

CSS3 was omitted in the literature review and in the research, in fact in the beginning only HTML5 was taken into account until CSS3 revealed to be essential at the end of the research on HTML5. So from that point CSS3 was considered, but since time was short and it was important to move on the next stages of the dissertation (research on Flash, learning and implementation), there never was any exhaustive presentation of CSS3 even though this should have been done.

While the research on HTML5 studied many samples of RIA, the research on Flash looked at only very few similar web applications.

In the implementation parts, the solutions should have been presented with far more depth: show main functions and explain the code.


Although it was planned in the research approach of the introduction, there was no real design of the artefacts (animations to test) nor of the benchmarking process. In fact animations created while learning the technologies revealed to be suitable so were straight away used in the first implementation and benchmarking. Since the aim was also to test the limits of these technologies in the web browsers, this first artefact was enhanced to be much more complex and was benchmarked a second time.

Investigation on the Economics and politics side may have been more detailed. Actually a sub part in the research on Flash, HTML5 and CSS3 was intending to comprehensively look at the interests of the web giants Apple, Google and Adobe around HTML5, CSS3 and Flash.

9.4.2 Strengths

Weaknesses previously stated need to be balanced and here are stated what elements seemed right in this study.

The research exhaustively looked at many experiments involving the HTML5 canvas and covered a big part of already existing works in HTML5. The depth of research leads to believable findings.

Although it is very hard to find statistics on the use of Flash on the web, the investigation on the research on Flash still resulted in bringing analysable figures.

The artefacts thoroughly cover the basic drawings in HTML5 canvas and CSS3.

The results of the benchmarking, even if they will be quickly outdated by new versions of web browsers, are already clear and promising for HTML5 and CSS3: on one hand HTML5 presents already acceptable performances; on the other hand, despite the CSS3 animation was not designed properly, it still works.

9.4.3 Difficulties of this dissertation subject

The scope was massive, maybe too big: the research was never looking only at graphic capabilities of HTML5, CSS3, Flash but at their overall potential and features. So this research also took into consideration the development of RIA or complex web applications while never really digging into the subject and might give the impression of lack of inquiry. About RIAs, Flash for example is not the only technology that needs to be considered. Even for animation, Silverlight may have been looked at.

The subject is in rapid evolution and it is hard to keep up to date. In five months there were many new experiments, conferences and articles that would have been highly relevant in the literature review and in the research part. However the dissertation does not only consist of doing research and there were short deadlines for the project.

HTML 5 and CSS 3 are still in development, not extensively used in industry. The consequences are that the resources, as far as the experiments and technical samples are considered, come mainly from independent and unknown developers that, not only may be not considered as academical references, but are also sometimes not presenting their actual name (but a nick name) nor defining the date of publishing or creation. Besides when investigating on the subject, not a single book had been written; books started to be released in the last weeks months but at that moment the research was already done and the dissertation was on the next stage.


The debate should be mostly technical; it is in fact surrounded by political & economical interests and conflicts. This is the hardest point of that subject because it easily deviates from the reality and what is essential.

9.4.4 Personal learning (answer to Introduction’s Intellectual Challenge)

I have matured since the day I read for the very first time Steve Jobs’ thoughts on Flash; at that moment I undoubtedly believed everything Apple’s CEO wrote and started to actively defend and promote the holy new web standards against the evil proprietary Flash. This research required to read plenty of opinion articles on this debate and considerably enhanced my critical thinking and my comprehension of that field: it took me some time to understand it was not by essence a technical debate, but actually a political struggle where every actor has strong economical interests.

This research improved greatly my comprehension of English: I had to read English articles and watch conferences and tutorials without subtitles. I know daily read English magazines, blogs and websites on that field without any difficulty: for example .Net magazine, Smashing Magazine, TechCrunch, HTML5 Doctor, CSS3 Watch, etc. I understand much easier videos in English. Likewise, having to write this report at an academic level was really beneficial.

It confirmed once more that I found my vocation. I found this topic highly interesting, I learned valuable new skills and I would love to get a job where I can pursue this work.

can new web technologies html5 & css3 kill flash? dissertation by jeremie charlet, 12/2010

Education