All posts tagged ‘HTML5’

File Under: HTML, HTML5, Web Standards

Two HTML Standards Diverge in a Wood

The two standards bodies that are jointly responsible for developing the HTML specification have cut the final tie that was binding them together.

The World Wide Web Consortium (W3C) and the Web Hypertext Application Technology Working Group (WHATWG) began to move apart last year when the WHATWG announced it would drop the version number and work on a “living standard” sans version numbers. The W3C continued to focus on HTML “snapshots” like HTML5.

However, despite that split the two shared an editor, Ian Hickson, who oversees both specs. Or did. In an e-mail to the WHATWG mailing list, Hickson announced that he is no longer the editor of the W3C HTML WG spec. The change isn’t unexpected; in fact Hickson announced it would happen over a year ago, but it does emphasize the growing distance between the two standards.

“The WHATWG effort is focused on developing the canonical description of HTML,” writes Hickson on the mailing list. “The W3C effort, meanwhile, is now focused on creating a snapshot developed according to the venerable W3C process.”

With different goals for each version of the spec Hickson says that “the chairs of the W3C HTML working group and myself decid[ed] to split the work into two, with a different person responsible for editing the W3C HTML5, canvas, and microdata specifications than is editing the WHATWG specification.”

Now, more than ever before there seems to be two versions of HTML. The question for developers is, what does this mean for the future of HTML? In the short term, very little.

The W3C will continue to develop its fixed-in-time snapshot of HTML5 and the WHATWG will keep going with the “living standard” approach. What some developers fear is that down the road the two specs will diverge in significant ways and HTML will become a messy set of forked standards and varying browser support that lands us back in the bad old days of IE 6.

Anything is possible, but we remain hopeful that that won’t happen, at least in part because the W3C standard is more of a branch than a fork.

If all goes well the process will remain essentially as it has been for the last few years: a browser adds some shiny new feature, the WHATWG documents it and other browsers implement their own versions. There’s an awkward, sometimes frustrating period for web developers while browsers tweak and refine their support, but eventually the dust settles and a new standard is added to the W3C’s version. It may not be a completely ideal process, but it is what’s managed to bring us this far.

File Under: HTML5, JavaScript, Multimedia

JavaScript Decoder Brings High-Quality Audio to the Web

Image: Webmonkey

HTML5′s native audio and video tools promise to eventually make it possible to create sophisticated audio and video editing apps that run in the browser. Unfortunately much of that promise has thus far been marred by a battle over audio and video codecs. Right now what works in one browser on one operating system will not necessarily work on another.

Until the codec battle plays itself out, developers looking to build native HTML audio apps are in a bit of a bind. One way around the problem is to bypass the browser and provide your own decoder.

That’s exactly what the developers at Official.fm Labs have been hard at work doing. The latest impressive release is FLAC.js, a FLAC audio decoder written in pure JavaScript. FLAC.js joins the group’s earlier efforts, which include decoders for MP3, AAC and ALAC.

Used in conjunction with the nascent Web Audio API, the new FLAC decoder means you could serve up high-quality, lossless audio to browsers that support HTML5 audio. But beyond just playback the Web Audio API opens the door to a whole new range of audio applications in the browser — think GarageBand on the web or DJ applications.

To that end Official.fm Labs has been working a framework it calls Aurora.js (CoffeeScript) to help make it easier to build audio applications for the web.

If you’d like to experiment with Aurora.js or check out the new FLAC decoder, head on over to Official.fm’s GitHub account where you’ll find all the code available under an MIT license.

I’m Feeling Moogy: Google Taps Native Web Audio for Awesome Moog Tribute

The Web Audio API in action. Image: Screenshot/Webmonkey

Google is celebrating electronic music pioneer Robert Moog’s 78th birthday with a Google doodle of the iconic Moog synthesizer. Like many past doodles today’s doodle doesn’t just look cool, thanks to the Web Audio API, it’s also a working synthesizer complete with a reel-to-reel tape machine for recording.

The Moog Google Doodle uses the nascent Web Audio API to create a mini Moog and power a mock reel-to-reel recorder. At the moment browser support for the Web Audio API is limited, but the doodle will work in most browsers since it falls back to Flash where the Audio API isn’t supported (the doodle does not work in Internet Explorer).

To play the Moog, just click any of the keys so that it gains focus and then you can play using your keyboard. All the nobs are fully functional as well, just click and drag to change the settings. Hit the record button and you can save your songs and share them with others.

Behind the scenes the Moog doodle also uses Closure libraries and some CSS 3 for the design and custom fonts. Developers interested in how the Moog doodle works can check out the archived doodle page and peruse the Moog.js JavaScript file for full details (as with all Google scripts, this one has been optimized for file size; you’ll want to run it through JSBeautifier or similar before you try to read it).

Mozilla Builds Video Chat App Using Nothing but Web Standards

Mozilla recently showed off a demo of a video chat app built entirely from web standards. Most of the demo runs on top of the proposed Web Real Time Communication (WebRTC) standard, the W3C’s answer to the audio and video streaming capabilities once found only in proprietary plugins like Flash.

Mozilla’s demo movie shows two users signed in with BrowserID (recently renamed Persona) start a video chat right in the browser. The Persona features, combined with the SocialAPI add-on for Firefox, make the demo browser look a bit like Facebook or other social sites with a “buddy list” of currently signed in users available in the sidebar. Select a user from that list and just click the video chat link to start a call.

Currently Mozilla’s video chat demo requires an experimental build of Firefox and actually uses “a custom API intended to simulate the getUserMedia and PeerConnection APIs currently being standardized.” In other words, video chat in Firefox is still a long way from replacing Skype, but Mozilla does plan to bring at least preliminary support to Firefox later this year.

The short-term goal, according to Mozilla hacker Anant Narayanan, who narrates the video above, is to add WebRTC support to Firefox’s Nightly channel “by the end of this quarter.” Narayanan cautions that in the beginning support may be “limited to just getUserMedia and not the full PeerConnection.”

While the demo video focuses on making video calls work in the desktop browser, with help from some other elements in Mozilla’s larger WebAPI project — which is developing a set of APIs that will allow web apps to better compete with platform-native applications — web-based video chat could work on any device. We recently looked at Mozilla’s Camera API, which gives developers access to your device’s camera, and, in conjunction with these video chat tools, could theoretically bring video chat to mobile browsers as well.

For more info on the video chat experiment, including the source code for the demo, head over to the Mozilla Hacks blog.

BrowserQuest Is Pure HTML5 Gaming Goodness

NyanCat is one of several Easter eggs in BrowserQuest

Mozilla has partnered with developers at Little Workshop to launch BrowserQuest, a Zelda-inspired multiplayer roleplaying game built entirely on the open web stack — HTML5, JavaScript and CSS.

While BrowserQuest is a fun game to play, it was written as much to prove a point as to be a game — namely, that web developers no longer need to rely on Flash to create sophisticated online games. Using today’s web standards, game developers can build impressively complex games that work across devices.

To give BrowserQuest a try, just head on over to the site and pick a username. BrowserQuest will work in most modern web browsers including Firefox, Chrome, Safari, Opera (provided you enable WebSockets), Mobile Safari and Firefox for Android.

In an effort to help game developers looking to build more serious HTML5-based games, the code behind BrowserQuest has been released on GitHub.

BrowserQuest’s backend, which handles the real-time multiplayer aspect of the game, is written in JavaScript and runs on Node.js. As you would expect BrowserQuest uses the HTML5 Canvas element to actually render its 16-bit-style world and hooks into the HTML5 audio APIs for sound effects.

BrowserQuest is responsive as well, using @media queries to adapt to the size of your screen.

WebSockets — which are back, after being rewritten to fix some early flaws — handle the chat feature, which allows players to communicate within BrowserQuest. The final element in BrowserQuest’s HTML5 puzzle is localStorage, which saves your progress as you move through the game.

Although designed as much to showcase the power of WebSockets as to be an actual videogame, BrowserQuest is addictive and can easily suck you into its world for an entire morning if you’re not careful. (Not that we’d know.) There are also quite a few Easter eggs hidden away in its depths.

For more info on BrowserQuest either dive into the game, dig through the code or watch the screencast from developer Guillaume Lecollinet: