Category Archives: HTML

Mozilla Hacks Blog Offers HTML5 Geolocation Primer

The Mozilla Hacks blog has posted a nice screencast overview of the HTML5 Geolocation API. The video is designed to help anyone competing in Mozilla’s September developer derby (which involves building something with the Geolocation API), but it also makes a great overview for anyone wanting to get started with Geolocation.

The HTML5 Geolocation API enables web developers to discover a user’s location via the browser (with the user’s permission of course). There’s no need to install any apps or do anything else at all, provided your user has a modern web browser. Despite pretty good browser support for the HTML5 Geolocation API, geolocation tools have become associated with native mobile apps, not web apps. Mozilla’s September developer derby is hoping to inspire web developers to change that.

For those that don’t have a browser capable of using the Geolocation API there are a number of JavaScript based polyfills developers can use to fill in the gaps in browser support. Check out the Mozilla Hacks blogfor some links to the Geolocation polyfills, as well as the sample code shown in the movie below.

What the Death of Mobile Flash Means for the Web

Adobe Software has let slip that it plans to abandon its Flash Player for mobile web browsers. Instead, the company willrefocus its mobile efforts on web standards like HTML5, along with tools like Adobe AIR, which allows developers to convert Flash content into native mobile applications.

The move comes as something of a surprise given how vigorously Adobe has defended mobile Flash in the past. Lately, however, Adobe has been proposing new web standardsand even bought the non-Flash mobile development toolPhoneGap, both of which indicate that Adobe is looking toward a future without Flash.

Indeed, while Adobe’s plans affect only mobile Flash at the moment, the sudden about-face does not bode well for Flash on the desktop. Mobile devices are the fastest growing means of connecting to the web; what doesn’t work on mobile devices will soon not be a relevant part of the web at all.

In abandoning mobile, Adobe is effectively admitting that Flash has no future on the web.

That doesn’t mean Flash will disappear overnight. Nor does it mean that Flash will ever disappear for developers interested in using it. It just means that when it comes to deploying Flash applications, the web won’t be a realistic option. Instead, Flash developers of the future will convert their Flash code into Android, Windows Mobile or iOS apps using Adobe AIR’s conversion tools.

Web developers, on the other hand, will likely abandon Flash if they haven’t already. Without a reliable way to serve Flash content to mobile devices, its web presence will likely continue to decline. Of course the demise of Flash has been inevitable for some time — after all, much of HTML5 was specifically designed to give developers a means of replacing Flash dependencies with native tools — but Adobe’s decision to abandon mobile devices should send a clear message to any developers who haven’t yet read the writing on the wall: Mobile is the future of the web and Flash isn’t part of it.

In the short term, Adobe is merely admitting what most developers already know; there are only two ways to develop for mobile devices: using the web and HTML5 or building platform native apps.

To choose web-based Flash apps over either of these options would mean consciously limiting your app’s audience. Given that neither Apple’s iOS nor Microsoft’s Windows Phone 7 supports Flash (nor for that matter will Microsoft’s Windows 8 Metro), developing web apps that relied on Mobile Flash meant targeting only Android and Blackberry users. Adobe’s decision to abandon Flash for Mobile browsers is simply a pragmatic acceptance of the existing development landscape.

Similarly, while we don’t expect it to happen overnight, eventually Adobe will probably abandon Flash Player for the desktop as well — why continue developing a product when very few are using it? The AIR platform and its Flash-based tools for building native mobile apps will still be around to sell the Flash development tools (which is, after all, how Adobe makes money). Adobe simply won’t have any great need to continue pushing Flash on the web.

While some web standards advocates might see the eventual demise of Flash Player as a good thing for the web, we’re not so sure. Web standards were created to ensure that sites and apps work no matter what browser or device you’re using. Web standards were not created for — and have not historically been very good at — driving innovation on the web.

Innovation on the web has more often come from individual vendors — browsers, device makers and, yes, Flash. Flash laid many of the so-called cowpaths that HTML5 is paving in open standards. The audio and video tags for embedding media, the canvas element for animation, and the websockets protocol for communications are just a few of the things Flash helped to popularize on the web. That’s not to suggest that a web without Flash will want for innovation, but it certainly won’t be richer for Flash’s absence when that day arrives.

Metro-style Internet Explorer 10 Ditches Flash, Plugins

Windows 8 will have two versions of Internet Explorer 10: a conventional browser that lives on the legacy desktop, and a new Metro-style, touch-friendly browser that lives in the Metro world. The second of these, the Metro browser, will not support any plugins. Whether Flash, Silverlight, or some custom business app, sites that need plugins will only be accessible in the non-touch, desktop-based browser.

Should one ever come across a page that needs a plugin, the Metro browser has a button to go to that page within the desktop browser. This yanks you out of the Metro experience and places you on the traditional desktop.

The rationale is a familiar one: plugin-based content shortens battery life, and comes with security, reliability, and privacy problems. Sites that currently depend on the capabilities provided by Flash or Silverlight should switch to HTML5.

Microsoft has been vigorously promoting HTML5 for the last year and a half as the best way of providing rich interactivity on the Web. HTML5 potentially has reach far beyond that of Flash, since it can target both conventional browsers and closed ecosystems (such as iOS) alike. However, until now, Microsoft’s messaging has been tempered somewhat: use HTML5 when you can, but if you can’t—if you need support for DRM-protected media streaming, for example—then it’s reasonable to switch to an alternative, plugin-based technology.

With Windows 8, however, those reasonable decisions to use Flash or Silverlight will now be heavily penalized. Technically, there’s nothing wrong with the desktop browser, of course; the rendering engine and performance will be identical between both Metro and desktop. But the experience will be substantially inferior. The desktop browser isn’t designed for touch inputs, meaning that users will either have to switch to a mouse and keyboard, or fumble around with an interface that wasn’t built for fingers. The switch to the desktop browser also appears to discard things like back button history and current page state.

This puts the Metro browser in a peculiar position. Microsoft has positioned tablets as merely a different kind of PC. That, the company argues, affords capabilities and features not possible on iPad-style devices. But PCs have browser plugins—more generally, they have the ability to use the right technology for the job. If Metro doesn’t include that flexibility, that could be seen as diminishing the “PCness” of the platform.

HTML5 still isn’t a total replacement for plugin technologies, either. The gap is certainly narrowing: Web Sockets, Web Workers, built-in support for webcams and microphones, and more, are all coming to HTML5 browsers (or are available already), and these features will obviate the need for plugins for many applications. But certain corners are likely to remain; DRM-protected video, for example, might forever be impossible in HTML5, and while many people find DRM distasteful, many broadcasters feel they have little choice but to use it.

The solution to this conundrum on the iOS platform has been the app: companies like Netflix and the BBC have applications to watch video on these devices. The result is that in the desire to push an open, plugin-free Web, companies are being forced to migrate away from the Web entirely. Silverlight developers, at least, will have an easy migration path available to them: the new Metro development environment, used for producing native Metro applications, borrows heavily from Silverlight, and making the switch from an in-browser plugin-based application to a standalone Metro application should be relatively easier. Flash developers will have to wait to see what tools Adobe delivers.

HTML5 design and developer tools also remain weak, though this situation is improving with the creation of products like Adobe Edge.

With Microsoft’s promotion of HTML5, and the precedent set by iOS, the decision to get rid of plugins in the Metro browser is perhaps unsurprising. But it’s not clear that this will truly help Windows 8; the awkward user experience penalizes users who, for no fault of their own, need to use plugins, and detracts from Windows 8′s PC claims. A switch to a more HTML5-powered Web will happen regardless—does Microsoft really need to force the issue like this?

Adobe Hopes Impressive 3-D Graphics Can Save Flash 11

Adobe has announced Flash Player 11, a significant update for the company’s beleaguered browser plugin. Flash Player 11 will give Flash developers access to an impressive set of hardware-accelerated 3-D graphics tools.

Alongside Flash 11 Adobe has also announced version 3 of the Flash-based runtime, Adobe Air.

Flash Player 11 and Air 3 are scheduled for release in early October. Adobe hasn’t set an exact date, but the company’s annual Max conference, which runs October 1-5, seems a safe bet.

Adobe’s Flash browser plugin has taken a beating in the last few years, losing many of its traditional web roles like video or animations to the new features in HTML5. Additionally, the mobile world has not been kind to Flash. You won’t find the plugin on any Apple products, nor will it be part of the upcoming Windows 8 Metro platform.

While there are no doubt many Webmonkey readers who would like to see Flash disappear forever, Adobe continues to push Flash in directions which, so far, HTML5 can’t compete.

For this release that means the world of online 3-D graphics rendering. Flash 11 isn’t trying to compete with HTML5 or even reclaim its former strongholds like video (though for streaming DRM video it remains the only real choice). Instead Adobe is going after the burgeoning online gaming market with an impressive new 3-D rendering API.

The new Stage 3D rendering in Flash 11, nicknamed Molehill, is a very low level API for fully hardware accelerated 2-D and 3-D graphics. Adobe claims that Molehill can “efficiently animate millions of objects on screen, smoothly rendered at 60 frames per second.” The end result, according to Adobe, is “console-quality games” in the browser.

Indeed the videos Adobe has released showing off the new Molehill-based graphics are impressive.

Of course one day WebGL may well mean that Flash 11′s 3-D performance is possible without the Flash plugin. Unfortunately Internet Explorer still lacks WebGL support and WebGL’s performance varies considerably from browser to browser. For now Flash 11 looks to have the edge in 3-D graphics, whether or not that will last remains to be seen.

3-D Graphics aren’t the only thing new in this release, Flash 11 is now a 64-bit application on Windows, OS X and Linux. Adobe has also announced the release of Air 3.0 with improved tools for installing Air and converting Air apps to native iOS and Android applications.

If you hate Flash the latest release probably isn’t going to change your mind. Nor is it likely to convince Apple or Microsoft that Flash should be apart of their OSes. But if you’re a game developer who’d like to build console-quality games on the web, Flash 11 is your friend.

Gate One Puts a Terminal Emulator in Your Web Browser

If you’ve ever needed to connect to a remote server without installing any desktop software or doing anything other than opening a new browser window, then you need to check out Gate One. Gate One is a web-based terminal emulator and SSH client that will work in any modern web browser.

The brainchild of developer Dan McDougall, Gate One is the result of nine months of coding. While Gate One may not be the first project to put a terminal emulator in your browser — existing options include Shell in a Box and Ajaxterm among others — it has quite a few features that go well beyond the basics found in other emulators. For example, Gate One uses WebSockets rather than traditional polling so it’s able to keep SSH connections open without spiking your CPU and grinding the browser to a standstill. Gate One also has the ability to resume sessions after being disconnected.

Throw in multiple simultaneous terminal sessions, a way to save SSH bookmarks, a plugin architecture and the ability to play back, save and share terminal sessions and you’ve got a pretty respectable replacement for Putty and its ilk. Not that Gate One is intended to replace a desktop SSH client, but for situations where you can’t run a desktop app Gate One just might be the emulator you’ve been looking for.

The front end of Gate One is written entirely in HTML5 and JavaScript, which means it will work in any modern browser. Behind the scenes Gate One uses HTML5 WebSockets to connect to a Python-based SSH server.