All posts tagged ‘HTML5’

File Under: HTML5, Multimedia

Netflix Plans to Ditch Silverlight for HTML5

Image: Screenshot/Webmonkey.

Netflix is looking to ditch its Silverlight-based video player for an HTML5 version that would work pretty much anywhere, but HTML5 isn’t quite up to the task just yet, according to the company.

Microsoft has already put Silverlight — once Microsoft’s much-hyped alternative to Adobe’s Flash Player — out to pasture. While Microsoft will continue to support Silverlight for some time, it will be retired come 2021.

That gives Netflix and others eight years to come up with an alternative. For its part Netflix wants to use HTML5, but HTML thus far lacks some key components Netflix needs, namely a way to generate media streams for playback, a cryptography protocol and, most controversially, DRM for streaming media.

All three components are, however, already draft proposals at the W3C and will likely be an official part of HTML before Silverlight disappears. The three things Netflix needs to bring its video player to HTML5 are the Media Source Extensions specification, the Web Cryptography API and the Encrypted Media Extensions specification, better known as DRM for the web.

Netflix has been working with Google to add support for all three — which the company refers to as “HTML5 Premium Video Extensions” — to Chrome and Chrome OS. For now the new Netflix player for Samsung’s Chromebook “uses the Media Source Extensions and Encrypted Media Extensions to adaptively stream protected content.”

Chrome still lacks support for the Web Cryptography API, so Netflix has developed a Pepper Flash plugin to handle that part of the equation for now. Eventually the company plans to remove the Flash element as soon as Chrome lands support for the Cryptography API.

At that point, says the Netflix blog, “we can begin testing our new HTML5 video player on Windows and OS X.”

File Under: HTML5, Web Standards

W3C Drops ‘hgroup’ Tag From HTML5 Spec

Image: Screenshot/Webmonkey.

If you’ve been using the HTML5 hgroup tag, now would be a good time to stop. The hgroup tag is in the process of being removed from the W3C’s HTML5 specification.

While the official reason for hgroup‘s demise is the lack of support for hgroup semantics — the W3C requires two “reasonably complete implementations” — hgroup is fraught with accessibility problems and lacks many compelling use cases.

The hgroup tag was intended to be a way to group h1-h6 tags, for example a header and a subheading, but the semantics behind the tag mean that only the first header in an hgroup is visible to any accessibility API. As Steve Faulkner, co-editor of the HTML5 spec, writes on the W3C mailing list, this “effectively removes any notion of a subheading semantic for users and any way for it to be conveyed via an accessibility API.”

In other words hgroup ends up being semantically no different than a div tag, which is why Faulkner called for hgroup to be removed from the spec in the first place. As of this writing it’s still there, but Faulkner says he’s “working on the edits” (which will include some advice on how to handle groups of header tags).

So what should you do if you’ve used hgroup in your code? Well, if you can, consider removing it. But the browser support — which is limited to parsing and CSS — won’t likely change. And it’s also possible that some compelling use case will come up that motivates the W3C to add it to the HTML 5.1 spec (one hopes with better semantic rules) and browser to support it. In the mean time though, slowly step away from the hgroup and no webpages get hurt.

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.