HTML5 assault on Adobe Flash heats up with ClickToFlash

[User Name]

As Adobe works to port its full Flash Player to mobile platforms and highlights its upcoming support in CS5 for building iPhone apps using Flash tools, an open source group is leading a drive to kill Flash on the desktop using a WebKit plugin named ClickToFlash.

El asalto de HTML5 a Adobe Flash se calienta con ClickToFlash

ClickToFlash allows Safari users to isolate Flash content on the web so that it only plays when they choose to allow it. Flash content is replaced with a bounding box that enables the user to ignore the item (such as with ads) or to click the placeholder to activate Flash playback as desired.

Additionally, the plugin can convert requests for YouTube Flash videos into requests for higher quality H.264 videos, allowing desktop users to bypass Flash the same way the iPhone does, and simply play any YouTube videos using the browser's own built-in HTML5 support for direct H.264 playback.

The examples below compare the same HD clip served by YouTube, first rendered using Flash with the standard grey YouTube playback controls, and then presented in H.264 using ClickToFlash to request the non-Flash version from Google. The native HTML5 version results in Safari using its own native QuickTime X playback controls rather than those created by Google using Flash. During playback, Safari's native black playback bar disappears; using the ClickToFlash plugin, the user can also present H.264 videos using full screen playback.

YouTube via Flash

YouTube via HTML5


In addition to offering better quality video and more functional and accurate playback controls for smoothly navigating through the video clip, ClickToFlash's direct playback using HTML5 prevents the Flash plugin from ever engaging and consuming CPU cycles and notebook battery life. Outside of YouTube, this means that loading web pages won't max out your processor just to animate Flash ads in the background. Any essential Flash elements, such as navigation components, can be activated by clicking on the placeholder created by ClickToFlash as desired.

In the example below, Safari with ClickToFlash does not load Flash content on the New York Times site by default, but will load individual items at the user's request. On the iPhone, no Flash content is ever loaded nor can be. Most ad networks using Flash now sense the iPhone's user agent and supply alternative, non-Flash ad banners. As more users opt out of Flash, the ad market will follow, just as it has accommodated the iPhone. Videos will also move to H.264 in order to support modern browsers that don't need Flash just to present video clips.

NYT ClickToFlash


"One of ClickToFlash's primary goals is to eliminate as much Flash from the web as possible, allowing users to choose only the Flash they want to see," the plugin's development website says. The group asks for help in adding direct video support for other sites that currently use Flash to facilitate video playback.

As support for H.264 video delivered by simple HTML5 video tags erodes the primary demand for Flash on the web, and as web developers become familiar with using HTML5's new Canvas feature to perform sophisticated drawing effects within web pages without using a plugin such as Flash or Silverlight, many observers report that Adobe will face an uphill battle to continue to push closed Flash development as an alternative to using open web standards, particularly as new initiatives such as WebGL hardware accelerated 3D begin to gain traction.
Adobe's mobile strategy for Flash

While ClickToFlash works to kill Flash on the desktop, the existing battle between Adobe's Flash and HTML5 has been waged squarely in the mobile realm. Apple introduced the iPhone without support for either the desktop version of Flash or Flash Lite, a subset of Flash aimed at smartphone devices. As Apple became increasingly adamant in opposing Flash on the iPhone, Adobe reported that it had a Flash Player for the iPhone under wraps and nearing completion, and suggested that Apple was even involved in working on the project.

That changed with the announcement this week that Adobe would be releasing a new version of Flash Player 10 for other mobile platforms over the next year, with an initial public beta for Windows Mobile and Palm's WebOS by the end of the year, followed by betas for Android, Symbian, and RIM's BlackBerry OS sometime in 2010. Missing from those announcements was the hottest mobile device on the market: the iPhone/iPod touch.

(Updated since original publication to note that RIM is working with the Open Screen Project; Adobe says "The collaboration is expected to bring the full Flash Player browser runtime to BlackBerry smartphones.")

Adobe addressed iPhone development with the announcement that its upcoming CS5 Flash development tools would enable the production of native iPhone apps. The resulting applications are not Flash, and this does nothing to enable Flash playback on the iPhone, either within standalone apps or embedded in web pages.

Creating iPhone apps using Flash CS5

Flash "applications" replace open and standard web content created using HTML, CSS, and JavaScript with Adobe's proprietary .swf, a closed binary file that wraps up web content files (such as graphics and movies) with the company's own variant of ECMAScript (JavaScript), called ActionScript. In CS5, the Flash development tools will allow new Flash projects to be exported as standard iPhone apps rather than .swf files.

Adobe is doing this using LLVM (Low Level Virtual Machine), an open source compiler technology supported by Apple and used in its Xcode Mac and iPhone development tools. The next version of Adobe's Flash development app will simply compile Flash ActionScript into native iPhone code, much as existing tools already allow iPhone developers to write their code using Java, Scheme, or other languages, and then compile the code into C or Objective-C as a native iPhone app.

The iPhone is designed not to support any alternative languages via any sort of virtual machine, which prevents it from running "raw" Java, Flash, .Net, Silverlight, or anything else apart from its native C/Objective-C compiled to the ARM processor. This is enforced in the terms of Apple's SDK agreement. There is however no restriction against compiling any existing code into native C/Objective-C and creating an iPhone app from it.

http://www.appleinsider.com/articles...sh.html&page=1