All posts tagged ‘HTML5’

File Under: HTML5, JavaScript

Emulator Brings the Bygone Era of Amiga to the Web

Amiga pinball wizard.

Miss your Amiga? Now you can play Prince of Persia, Pinball Dreams and other Amiga hits right in your web browser thanks to the Scripted Amiga Emulator, an Amiga emulator written entirely in JavaScript and HTML5.

To view the emulator, which was written by developer Rupert Hausberger, you’ll need a browser with support for WebGL and WebAudio, as well as a few other HTML5 APIs. I tested the emulator in the latest version of both Chrome and Firefox and it worked just fine.

If you’d like to see the code behind the Scripted Amiga Emulator, head on over to GitHub.

Happy Friday afternoon time wasting.

File Under: HTML5, Web Standards

HTML5 Inches Closer to the Finish Line

Image: Screenshot/Webmonkey.

The W3C has an early Christmas present for web developers: The standards body that oversees the lingua franca of the web has published the complete definition of the HTML5 specification.

HTML5 isn’t an official standard yet, but the move to what the W3C calls “Candidate Recommendation” (CR) status means that the spec is largely stable, features are frozen, and testing can begin. In other words, the W3C is on track to publish the final version of HTML5 by 2014.

While developers targeting modern web browsers are already using HTML5 and many of its accompanying APIs, the move to CR status is nevertheless important because it marks the beginning of the interoperability and testing phase. Testing helps ensure that HTML5 can be implemented compatibly across browsers, servers, authoring tools and the dozens, if not hundreds, of other potential HTML5 clients — think your television, your car, your refrigerator and beyond.

HTML5 will likely be the language of the fabled Internet of Things and the lengthy testing period — the W3C plans for testing to last through 2014 — is designed to make sure that everything in the web of the future plays nicely together.

To go along with HTML5′s progress, the W3C has also published the First Public Working Draft of HTML5′s successor — HTML5.1. Although the W3C has “modularized” much of HTML5 over the years, spinning off sections like Web Workers, WebSockets, Microdata and half a dozen others, which are all now separate specifications at the W3C, the group plans to continue with versioned releases as well.

At the moment there isn’t much to see in the HTML5.1 spec, but look for the HTML5.1 draft to grow as new ideas are proposed.

It’s worth noting that, while the CR publication is generally a good thing, there are still over 100 known bugs and not everyone is happy with the decision to move HTML5 forward. But moving forward it is. After the CR stage is finished, the next step for HTML5 will be “proposed recommendation” status. From there HTML5 will become a final standard — if all goes according to plan — in 2014.

File Under: HTML, Web Standards

Proposed ‘Main’ Element Would Help Your HTML Get to the Point

Photo: Horia Varlan/Flickr

HTML5 has several new tags designed to make HTML more semantic — there’s <nav> for navigation elements, <header> for headers, <footer> for footers and now there just might be <main> to wrap around, well, the main content on a page.

The W3C’s HTML Working Group, which is charged with creating HTML, has accepted a proposal to add a draft specification for the <main> tag to HTML. The actual HTML spec hasn’t been updated yet, but you can read through the earlier, unofficial <main> docs.

The proposal has been around for some time, but former W3C HTML editor Ian Hickson opposed it on the grounds that its use case was too close to <article>. Since then the mailing list discussion has turned up enough supporters and use cases for a <main> element — including for a “reader” mode like that offered by Apple’s Safari, or to exclude non-main content from a search — that it looks like it will make the cut (Update: check out this W3C wiki page for more use cases).

It’s unlikely that <main> will make it into HTML5, which is about to reach the stable stage after which no new elements can be added, but it could make it to HTML 5.1, due to be finalized by 2016.

As Mozilla WHAT WG member Henri Sivonen writes on that group’s mailing list, “I think it was unfortunate that didn’t make it to the same round of added elements as <header>, <footer>, <nav> and <aside>… but it’s not too late to add it — browsers update faster than they used to.”

The purpose behind <main> is to give web authors a more semantic way to indicate a page’s main content. In many ways it mirrors what WAI-ARIA does with the “main” role.

In fact, because a <main> element would more or less bring the semantic power of ARIA’s role=main to HTML proper, you can get most of the benefits of the proposed <main> tag today, by just adding the “main” role to your primary content wrapper, something like:

<div role="main">
    <article>
        <h1>Top 10 Linkbait Headlines for Hacker News</h1>
        <time datetime="2012-12-11T03:21:22">December 11th, 2012</time>
        <p>... etc </p>
    </article>
    <div id="comments">
        <article>
            <h5>Comment Title</h5>
            <p>Comment body</p>
        </article>
    </div>
</div>

In this bit of pseudocode the main role tells the user agent — a web browser, search engine spider, etc. — that the primary content of the page is the article and the ensuing discussion in the comments.

So if you can do it already with ARIA why add <main>? The simple truth is that hardly any sites use ARIA roles. Because <main> is simple to use, web developers are more likely to use it and use it correctly (try searching for tutorials on how and when to use <article> and <section> to see the opposite effect), which in turn makes it a more reliable indicator for search engine spiders.

File Under: APIs, HTML5, Web Standards

BBC Taps the Past to Showcase the Future of Web Audio

Mixing old school tape loops with the BBC’s Web Audio API demo. Image: Screenshot/Webmonkey

HTML5 offers developers new ways to display and work with both audio and video on the web. The HTML5 <video> element tends to get more attention, but the HTML5 audio element is equally revolutionary, perhaps even more so thanks to the work-in-progress Web Audio API (currently in the draft stages).

Developers at the BBC recently set out to push the limits of what you can do with HTML5 <audio> and the Web Audio API. The result is a new audio playground site that recreates the sounds of the BBC Radiophonic Workshop using the Web Audio API. Note that right now only WebKit browsers support the Web Audio API. (Firefox supports the older, deprecated, Audio Data API, but plans to ship support for Web Audio in 2013.)

The BBC’s Radiophonic Workshop project is one part cool demo, one part tutorial. It’s fun to play around with, sure, but another reason behind the experiment is to document how to use <audio> and the Web Audio API. The developers also wanted to put the API through some real-world use cases, to see if there are any limitations that could be addressed before the Web Audio API becomes an official standard.

Each of the four demos has a thorough code walk-through showing exactly how it works and which elements of the Web Audio API are being used. There are a couple of dependencies, namely JQuery and Backbone.js, but most of the code is working directly with the Web Audio API.

If you’ve ever wanted to explore the Web Audio API, these demos make a great introduction to how everything works. For more background on the project, see the BBC’s Research and Development blog.

So far the code doesn’t seem to be available through the BBC’s R&D GitHub account. You can always copy and paste from the demo site, but it would be nice if it was available for easy forking and experimentation.

File Under: HTML5, Web Standards

Mozilla Busts HTML5 Myths

Image: Christian Heilmann/Flickr

Mozilla has jumped into the shark-infested debate about whether or not HTML5 can compete with platform native apps. Chris Heilmann, Mozilla’s Principal Evangelist for HTML5, has a new post on the Mozilla Hacks blog that challenges many “false assumptions” about HTML5.

Heilmann’s post is not so much about which you ought to use for your next app — right now that depends on what you’re building — rather it attempts to clear the air about just what HTML5 actually can and cannot do.

Among the things Heilmann covers are the myths that HTML5 has performance problems, that it can’t work offline and that developers can’t make money building HTML5 apps.

Along the way Heilmann also acknowledges where platform-native apps have the lead, namely, access to device APIs. It’s not a shortcoming of HTML5 that iOS and Android both prevent web apps from accessing many APIs native apps can use, but it is a practical reality that keeps many developers building native apps for the time being. As Heilmann writes, “in essence HTML5 is a Formula 1 car that has to drive on a dirt road whilst dragging a lot of extra payload given to it by the operating system without a chance to work around that — for now.”

The qualifier, “for now,” is the key part of that analogy. Not only are platforms slowly adding more HTML5 support to their native browsers, we’ve also seen increased support for accessing device capabilities — like GPS or the camera — through web apps. And of course Mozilla is building its own mobile OS which will consist exclusively of HTML5 apps.

It may be some time before app developers start favoring the web over platform-specific apps, but as Heilmann points out this is hardly the first time the web has taken over from a closed system: “historically, closed platforms came and went and the web is still going strong.”