Archive for the ‘HTML5’ Category

File Under: HTML5, Web Standards
Jan
27
2012

HTML5 Video on the Web Today

By

The hype surrounding HTML5 video has thankfully receded from the high water mark of 2011. But the absence of hype doesn’t mean HTML5 video is a thing of the past. In fact, while it’s true that HTML5 video still can’t completely match all of the features available in Flash, the state of HTML5 video on the web continues to improve with every new browser release.

For a very thorough rundown of exactly where and how well HTML5 video works on the web right now, check out the excellent report on the state of HTML5 video from Long Tail Video. Put together by the makers of JW Player, an HTML5 video player toolkit, the state of HTML5 video report is mercifully free of any evangelism for any particular technology. Instead it offers a level-headed look at reality, answering the basic questions — where can you use HTML5 video? How well will it work for users? And when will you need Flash fallbacks?.

HTML5 video enthusiasts will be happy to know that the state of native video on the web is looking better these days. Two-thirds of all the browsers on the web now support the HTML5 video tag. Support for the various video tag attributes has improved as well, with both Safari and Chrome offering full support.

Still, for all the bright points in the report, there is clearly still a need for Flash fallbacks if you want your video to reach the widest possible audience. With older versions of Internet Explorer still lingering (IE 9 and up support the HTML5 video tag) and the lack of support for closed captions and audio descriptions in any browser, Flash will likely remain the only option for at least some portion of the web for some time.

The good news is that, in some cases, the state of HTML5 video will be improving very soon, for example Firefox 10, which will be released in final form very soon, will support native fullscreen playback.

For more details on which parts of HTML5 video work and which don’t in today’s browsers, be sure to read through the full report.

Tags:
File Under: CSS, HTML, HTML5
Jan
25
2012

‘HTML5 Please’ Helps You Decide Which Parts of HTML5 and CSS 3 to Use

By

Keeping track of the ever-evolving HTML5 and CSS 3 support in today’s web browsers can be an overwhelming task. Sure you can use CSS animations to create some whiz-bang effects, but should you? Which browsers support it? What should you do about older browsers?

The first question can be answered by When Can I Use, which tracks browser support for HTML5 and CSS 3. You can then add tools like Modernizer to detect whether or not a feature is supported, so that you can gracefully degrade or provide an alternate solution for browsers that don’t support the features you’re using. But just what are those alternate solutions and polyfills? That’s what the new (somewhat poorly named) HTML5 Please site is designed to help with.

HTML5 Please offers a list of HTML5 elements and CSS 3 rules with an overview of browser support and any polyfills for each element listed (CSS 3 is the much more heavily documented of the two, which is why the HTML5 emphasis in the name is perhaps not the best choice). The creators of the site then go a step further and offer recommendations, “so you can decide if and how to put each of these features to use.”

The goal is to help you “use the new and shiny responsibly.”

HTML5 Please was created by Paul Irish, head of Google Chrome developer relations, Divya Manian, Web Opener for Opera Software, (along with many others) who point out that the recommendations offered on the site “represent the collective knowledge of developers who have been deep in the HTML5 trenches.”

The recommendations for HTML5 and CSS 3 features are divided into three groups — “use”, “use with caution” and “avoid”. The result is a site that makes it easy to figure out which new elements are safe to use (with polyfills) and which are still probably too new for mainstream work. If the misleading name bothers you, there’s also Browser Support, which offers similar data.

If you’d like to contribute to the project, head over to the GitHub repo.

Tags: ,
File Under: Browsers, HTML5, Multimedia, Web Standards
Jan
20
2012

Mozilla Demos MediaStream Processing, Audio Mixing in Firefox

By

Mozilla is drafting a proposal for a new web standard called MediaStream Processing that introduces JavaScript APIs for manipulating audio and video streams in real time. The specification is still at an early stage of development, but Mozilla has already started working on an implementation for testing purposes.

Mozilla’s Robert O’Callahan, the author of the MediaStream Processing API proposal draft, released experimental Firefox builds that include MediaStream Processing support. He has also published a set of demos (note: you need to run the experimental build to see the demos) that illustrate some of the functionality defined by the specification.

The demos show how the APIs can be used to perform tasks like rendering a visualization of a video’s audio track in a Canvas element while the video is playing. It also shows how the APIs can be used for mixing tasks, like implementing a cross-fade between two audio streams, dynamically adjusting the volume of a video, and programmatically generating audio streams.

One of the characteristics that distinguishes the MediaStream Processing API from previous web audio API proposals is that it aims to interoperate better with existing web standards. For example, it relies on the MediaStream interface in the WebRTC specification. It also allows users to take advantage of Web Workers for threading and will work with getUserMedia to eventually support real-time manipulation of streams from microphones and webcams.

The current implementation of the specification focuses on audio capabilities. As O’Callahan explained this week in a blog post, support for video manipulation will be added in the future when the necessary graphics APIs are accessible through Web Workers. MediaStream Processing on video will be useful for doing things like QR code recognition and augmented reality in web applications, he said.

Analyzing a video's audio track and visualizing it in real time

So, when will this functionality be available in a stable Firefox release? It might take some time. According to O’Callahan, the patch needs some cleanup before the functionality can land in trunk and make it into regular nightly builds. Even then, the MediaStream Processing functionality likely won’t be generally available until the specification has solidified.

“The biggest limitation is that it’s not shipping in Firefox yet. My giant patch is messy and a lot of cleanup needs to be done. I have a plan to split the patch up, clean up the pieces and land them piecemeal. In particular I need to get some of the infrastructure landed ASAP to help the WebRTC team make progress,” he wrote. “When we ship it, much or all of the API will probably be disabled by default, behind a hidden pref, until the standards situation is resolved.”

MediaStream Processing is definitely going to be worth the wait. Some fantastic capabilities are going to be unlocked when the specification is fully implemented. It will open the door for using native web standards to perform some sophisticated real-time media processing tasks that were previously only possible with browser plugins.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Tags:
File Under: CSS, HTML5, JavaScript, Mobile, UI/UX, Visual Design, Web Basics
Jan
12
2012

Building a Responsive, Future-Friendly Web for Everyone

By

A handful of the many screens your site needs to handle. Photo: Ariel Zambelich/Wired.com

This week’s Consumer Electronics Show in Las Vegas has seen the arrival of dozens of new devices from tablets to televisions. Some of these newfangled gadgets will soon be in the hands of consumers who will use them to access your website. Will your site work? Or will it end up mangled by a subpar web browser, odd screen size or slow network connection?

No one wants to rewrite their website every time a new device or browser hits the web. That’s why approaches like responsive design, and the even broader efforts of the future-friendly group, are trying to develop tools and techniques for building adaptable websites. That way, when a dozen new tablets suddenly appear on the scene, you can relax knowing your site will look and perform as intended, no matter which devices your audience is using.

Even if you aren’t a gadget lover, CES should help drive home the fundamental truth of today’s web — devices, they are a comin’. Webmonkey has compiled helpful resources for creating responsive design in the past, but the field is new and evolving rapidly so here’s an updated list of links to help you get started responsive, future-friendly sites that serve your audience’s needs whether they’re browsing with a tiny phone, a huge television or the web-enabled toaster of tomorrow.

Basics:

  • Use @media to scale your layout for any screen, but remember that this alone isn’t really responsive design.
  • Use liquid layouts that can accommodate any screen size. Don’t simply design one look for 4-inch screens, one for 7-inch, one for 10-inch and one for desktop. Keep it liquid, otherwise what happens when the 11.4-inch screen suddenly becomes popular?
  • Roll your own grids based on the specifics of your site’s content. Canned grid systems will rarely fit the bill. The problem with canned grids is that they don’t fit your unique content. Create layouts from the content out, rather than the canvas (or grid) in.
  • Start small. Start with the smallest size screen and work your way up, adding @media rules to float elements into the larger windows of tablet and desktop browsers. Start with a narrow, single-column layout to handle mobile browsers and then scale up from there rather than the other way around. Starting with the smallest screen and working your way up means it’s the desktop browsers that need to handle @media, make sure older browsers work by using polyfills like Respond.
  • Forget Photoshop, build your comps in the browser. It’s virtually impossible to mock up liquid layouts in Photoshop, start in the browser instead.
  • Scale images using img { max-width: 100%; }. For very large images, consider using something like Responsive Images to offer the very smallest screens smaller image downloads and then use JavaScript to swap in larger images for larger screens. Similar techniques can be used to scale video.
  • Forget about perfect. If you haven’t already, abandon the notion of pixel perfect designs across devices. An iPad isn’t a laptop isn’t a television. Build the perfect site for each.

Further Reading:

  • Future Friendly — An overview of how some of the smartest people in web design are thinking about the ever-broadening reach of the web: “We can’t be all things on all devices. To manage in a world of ever-increasing device complexity, we need to focus on what matters most to our customers and businesses. Not by building lowest common-denominator solutions but by creating meaningful content and services. People are also increasingly tired of excessive noise and finding ways to simplify things for themselves. Focus your service before your customers and increasing diversity do it for you.”
  • Building a Future-Friendly Web — Brad Frost’s excellent advice: “Think of your core content as a fluid thing that gets poured into a huge number of containers.”
  • There is no mobile web — “There is no mobile web, nor desktop web. It is just the web. Start with the content and meet people halfway.”
  • Responsive by default — Andy Hume on why the web has always been responsive, but was temporarily sidetracked by the fad of fixed-width sites.
  • COPE: Create Once, Publish Everywhere — NPR’s Director of Application Development, Daniel Jacobson, walks through how NPR separates content from display and uses a single data source for all its apps, sites, APIs and feeds. A great example of what Frost talks about regarding content as a fluid thing.
  • Support Versus Optimization — It can seem daunting to support dozens of mobile browsers, but if you aren’t up to the challenge of a few mobile browsers now what are you going to do when you need to support car dashboards, refrigerators, televisions and toasters, all with dozens of varying browsers?
  • The Coming Zombie Apocalypse — Not satisfied thinking a few years ahead? Scott Jenson explores further into the future and tries to imagine what the web might look like when devices all but invisible.

Techniques:

Tags: , ,
File Under: HTML5, Web Basics
Dec
14
2011

Enough With the Apps Already

By

I never know if one of my blog posts is going to take off. Most don’t. But yesterday’s post about apps not being the future probably set some kind of record. It got a lot of links and a lot of reads.

Had I known it was going to get so much attention I would have spelled out exactly what I meant by app. The question came up e-mailing with Brent Simmons who wrote a post about my post yesterday. I didn’t understand the confusion until I did a little back and forth with him.

I said this: “I mean app as in ‘there’s an app for that.’”

I’m talking about the newspaper or magazine that, when you click on a link to go to one of their articles, puts up an interstitial telling you that you could read the article in their app instead. Initially, I installed one or two of these. The other day I installed a big comprehensive one from Google. Flipboard is the original one of these reading environments that is not the web. The New York Times has a slow, buggy, huge app for reading their news.

Now don’t get me wrong; there’s no reason they shouldn’t produce these apps. Go ahead. They have every right. But I also have every right not to use them. And if they insist, as the New York Post does (its content isn’t available for iPad users on any other terms) I can just skip their content altogether (which in the case of the Post, who gives away their paper at subway entrances in NYC and is an awful Murdoch trash rag that would be an insult to dead fish to be wrapped in it, feels just right).

If that’s all there was to it, I probably never would have written this piece. But last week I read about a speech given at LeWeb in Paris by George Colony of Forrester Research, that got a lot of coverage. He said the web is over, and apps are the future. (BTW, when you search for George Colony on Google they’re so sure you meant George Clooney they don’t even offer the choice of George Colony.)

It was that speech, plus Google’s app, plus a well-timed interstitial that got me thinking: Why is it that I find this concept of the future so repulsive?

I wrote five pieces yesterday. I guess that was the best one. Sure hit a nerve. A lot of people agree. Enough with the apps already.

I think the publishers like the idea because it offers hope of a new paywall, an electronic one. My guess is that it’s a hope in vain.

Tablets are almost ideal reading environments. I don’t think, as some developers do, that the iPad is the ultimate. I think it’s heavy and cold, and makes my arm fall asleep when I read lying down. I think the software is a glitchy. Like great movies, great computer experiences are all about suspension of disbelief. If I forget I’m reading on an iPad and get consumed by the story, then the technology is working perfectly. The iPad experience is good, but there’s still a way to go. And all this business about apps is a real spoiler for suspension of disbelief. I’m clicking a link, expecting to learn more about what I was reading (that was certainly the author’s intent) but instead I get an ad for an app. If I seriously consider it, I’ve lost my train of thought. If I actually take the detour and install it, I’ve lost big time. The best way to minimize the loss is hit the Back button and skip it. But that’s a loss too. I clicked the link for a reason. And that was thwarted.

I’d be happy with a pref that says to all websites “I’m never going to install your app, so please don’t bother with the pitch.” Sort of like a No Solicitors sign on the front door of my house (which I don’t have; it’s too rude to people who are not solicitors).

BTW, I wrote a piece a month ago about Google’s search website on the iPad and how awful it is. They made it even worse. Now if you click on the Classic link at the bottom of the page you lose your search string and have to enter it again. At least in the past when you clicked Classic, after scrolling to the bottom of the page, you got the search results you were looking at in a more compact form.

To anyone from Microsoft who may be reading this far, here’s a chance to get a bunch of iPad users. Make Bing work exactly like Google on the desktop, on the iPad. Or offer it as an option. I will use your search engine from now on on the iPad if you do that. Google is deliberately screwing their iPad users. Now you guys can be the heroes.

All of this is of course IMHO, as if that needs to be said. But when there are a bunch of new Apple zealots reading stuff here calling me “some people” or “this guy” in my own blog, well it needs to be said.

Also, I let comments run more or less rampant in the last post. It got to be too much to moderate them all. Even so, if a comment required my approval and it was idiotic or unnecessary (How many times do we need to hear that there are things called intents?) I just let it sit there unapproved. You don’t have a right to place your ideas here. If I’m not reading your book-length comment, why should I impose it on my readers?

This post first appeared on Scripting News.

Dave Winer, a visiting scholar at NYU’s Arthur L. Carter Journalism Institute, pioneered the development of weblogs, syndication (RSS), podcasting, outlining, and web content management software. A former contributing editor at Wired Magazine, Dave won the Wired Tech Renegade award in 2001.
Follow @davewiner on Twitter.
File Under: CSS, HTML5, JavaScript
Dec
7
2011

Celebrate the Holidays With Advent Calendars for Web Nerds

By

The holiday season is upon us and for web nerds that means only one thing — advent tutorials.

Sure, it might be getting colder, possibly even snowing where you are, but the real way a web developer knows that the holidays are here is that 24Ways, the annual advent calendar for web nerds, is out. That means it’s time to learn new tricks, re-learn best practices and get a leg up on some of the year’s best ideas in web development.

This year’s 24Ways has a decidedly responsive design slant to it (so far anyway). Developer Jeremy Keith weighs in with a tutorial on how to use conditional loading for responsive designs. Adaptive images creator Matt Wilcox also has a great in-depth look at how his technique can serve up the appropriate image size without changing your HTML markup.

Other highlights include a great article from Rich Thornett on the hazards of relying on third-party widgets within your pages. Thornett’s solution is to load your widget content into a hidden <div> at the bottom of the page and then use a local script to move the loaded content from the hidden <div> to its display location. That way, should your third-party widget fail to load, at least it won’t stop the rest of your page from loading.

Also be sure to check out Drew McLellan’s walk-through of CSS 3′s unicode-range. By adding the unicode-range property to a @font-face rule, you can, for example, specify a different font just for fancier ampersands. McLellan covers how to make it work and how to handle the (inevitable) browser shortcomings.

Awesome as 24Ways is — and we’re looking forward to seeing the rest of it — it’s certainly not the only advent calendar around for web nerds. The Mozilla Developer Network has an advent calendar up with some nice articles on topics like WebGL, though in this case most of the articles listed are already up elsewhere on the web.

Somewhat more interesting, especially for those of you who want to get even nerdier than usual this year, is the Performance Calendar. This advent calendar is devoted to tackling the often confusing world of website optimization. All the posts are worth a read, but be sure not to miss Guy Podjarny’s article on why “inlining everything” is not the answer to your site’s speed problems. Also worthwhile is Tim Kadlec’s detailed investigation of mobile networks, appropriately titled: Carrier Networks: Down the Rabbit Hole.

Altoids Advent Calendar photo by Kim Taylor/Flickr/CC. For instructions, visit her blog.

File Under: HTML5, Web Standards
Nov
29
2011

WAI-ARIA Gets Ready for a Starring Role in HTML5

By

masksWAI-ARIA, the W3C’s specification for Accessible Rich Internet Application, provides web developers with a means of annotating page elements with the roles, properties, and states that define exactly what those elements do. The added definitions help screen readers and other assistive devices navigate through your website.

We’ve previously looked at how WAI-ARIA can help you build more accessible websites, and showed you how the role attribute can help browsers understand what an HTML element is being used for. Nice as both of those techniques are, neither is much help if browsers and screen readers don’t support them.

In the past, support for WAI-ARIA has been spotty, but as Web Accessibility Consultant Steve Faulkner recently found, WAI-ARIA’s landmark roles are now well supported in nearly every browser and screen reader. There are a couple of exceptions to be aware of, namely role="form" is not widely supported, and the older Window Eyes 7.5 screen reader hasn’t been updated (and likely never will) to support roles.

Still, despite the lack of the support in Window Eyes 7.5, WAI-ARIA roles are largely ready for prime time. That means you can start using roles in your HTML5 today. For example, you might have something like this for the main navigation on your site:

<nav>
    <ul>
        <li>Home</li>
        <li><a href="/about/">About</a></li>
        ...etc...
    </ul>
</nav>

While it might seem that the nav tag would define the nav element’s role, not every browser will understand it. (Just because the browser can display it, does not mean it understands the tag.) Also, the purpose of a navigation element may be obvious to most users, but to a screen reader being used by somebody who can’t see, the navigation strip could be just a jumble of words. Leveraging WAI-ARIA’s syntax, we can double up to ensure screen readers will know that this chunk of code is navigation:

<nav role="navigation">
    <ul>
        <li>Home</li>
        <li><a href="/about/">About</a></li>
        ...etc...
    </ul>
</nav>

Of course there are other benefits to adding roles to your page, like the ability to style the elements with CSS. Sticking with the example above, we could target this specific nav element using code like this:

nav[role="navigation"] {
    margin: 0
    ...etc...
}

Using roles to style your CSS eliminates the need for extra IDs or classes and often makes for more readable CSS since the role definitions are easy to understand, even years later.

Of course, while browser support has improved significantly over the last year or so, WAI-ARIA roles are not without a few glitches and gotchas. Be sure to read through Webmonkey’s earlier post on building a more accessible web with WAI-ARIA, and of course, look over the W3C’s WAI-ARIA role spec, which has more examples and guidelines for when and where to use WAI-ARIA roles.

Italian Masks photo by Peter Lee/Flickr/CC

Tags:
File Under: HTML5, Web Standards
Nov
21
2011

The Trials and Tribulations of HTML Video in the Post-Flash Era

By

Adobe reversed course on its Flash strategy after a recent round of layoffs and restructuring, concluding that HTML5 is the future of rich Internet content on mobile devices. Adobe now says it doesn’t intend to develop new mobile ports of its Flash player browser plugin, though existing implementations will continue to be maintained.

Adobe’s withdrawal from the mobile browser space means that HTML5 is now the path forward for developers who want to reach everyone and deliver an experience that works across all screens. The strengths and limitations of existing standards will now have significant implications for content creators who want to deliver video content on the post-flash web.

Apple’s decision to block third-party browser plugins like Flash on its iOS devices played a major role in compelling web developers to build standards-based fallbacks for their existing Flash content. This trend will be strengthened when Microsoft launches Windows 8 with a version of Internet Explorer that doesn’t support plugins in the platform’s new standard Metro environment.

Flash still has a significant presence on the Internet, but it’s arguably a legacy technology that will decline in relevance as mobile experiences become increasingly important. The faster pace of development and shorter release cycles in the browser market will allow open standards to mature faster and gain critical mass more quickly than before. In an environment where standards-based technologies are competitive for providing rich experiences, proprietary vendor-specific plugins like Flash will be relegated to playing a niche role.

Our use of the phrase post-Flash isn’t intended to mean that Flash is dead or going to die soon. We simply mean that it’s no longer essential to experiencing the full web. The HTML5 fallback experiences on many Flash-heavy sites still don’t provide feature parity with the Flash versions, but the gap is arguably shrinking — and will continue to shrink even more rapidly in the future.

Strengths and weaknesses of HTML5 video

HTML5 has much to offer for video delivery, as the HTML5 video element seamlessly meshes with the rest of the page DOM and is easy to manipulate through JavaScript. This means that HTML5 video offers significantly better native integration with page content than it has ever been possible to achieve with Flash. The open and inclusive nature of the standards process will also make it possible for additional parties to contribute to expanding the feature set.

A single company no longer dictates what can be achieved with video, and your video content is no longer isolated to a rectangle embedded in a page. HTML5 breaks down the barriers between video content and the rest of the web, opening the door for more innovation in content presentation. Three are some really compelling demonstrations out there that showcase the use of video in conjunction with WebGL and other modern web standards. For example, the video shader demo from the 3 Dreams of Black interactive film gives you a taste of what’s possible.

Of course, transitioning video delivery in the browser from Flash to HTML5 will also pose some major challenges for content creators. The standards aren’t fully mature yet and there are still a number of features that aren’t supported or widely available across browsers.

For an illustration of how deep the problems run, you need only look at Mozilla’s Firefox Live promotional website, which touts the organization’s commitment to the open web and shows live streaming videos of Red Panda cubs from the Knoxville Zoo. The video is streamed with Flash instead of using standards-based open web technologies.

Flash is required to see the Red Panda cubs on Mozilla's website

In an FAQ attached to the site, Mozilla says that it simply couldn’t find a high-volume live-streaming solution based on open codecs and open standards. If Mozilla can’t figure out how to stream its cuddly mascot with open standards, it means there is still work to do.

Two of the major technical issues faced by HTML5 video adopters are the lack of adequate support for adaptive streaming and the lack of consensus surrounding codecs. There is currently an impasse between backers of the popular H.264 codec and Google’s royalty-free VP8 codec. There’s no question that a royalty-free video format is ideal for the web, but the matter of whether VP8 is truly unencumbered by patents — and also meets the rest of the industry’s technical requirements — is still in dispute.

There is another major issue that hasn’t been addressed yet by open web standards that could prove even more challenging: content protection. The vast majority of Flash video content on the Internet doesn’t use any kind of DRM and is trivially easy to download. Flash does, however, provide DRM capabilities and there are major video sites that rely on that technology in order to protect the content they distribute.

Can DRM be made to play nice with open standards?

DRM is almost always bad for regular end users and its desirability is highly debatable, but browser vendors will have to support it in some capacity in order to make HTML5 video a success. Many of the content creators who license video material to companies like Netflix and Hulu contractually stipulate a certain degree of content protection.

Mozilla&’s Robert O’Callahan raised the issue of HTML5 video DRM in a recent blog entry shortly after Adobe’s announcement regarding mobile Flash. He expressed some concern that browser vendors will look for a solution that is expedient rather than inclusive, to the detriment of the open web.

“The problem is that some big content providers insist on onerous DRM that necessarily violates some of our open web principles (such as web content being equally usable on any platform, based on royalty-free standards, and those standards being implementable in free software),” O’Callahan wrote. “We will probably get into a situation where web video distributors will be desperate for an in-browser strong DRM solution ASAP, and most browser vendors (who don’t care all that much about those principles) will step up to give them whatever they want, leaving Mozilla in another difficult position. I wish I could see a reasonable solution, but right now I can’t. It seems even harder than the codec problem.”

O’Callahan also pointed out in his blog entry that the upcoming release of Windows 8, which will not support browser plugins in its Metro environment, means that the lack of DRM support in standards-based web video is no longer just a theoretical concern. Microsoft may need to furnish a solution soon, or risk frustrating users who want to watch commercial video content on the web in Windows 8 without installing additional apps or leaving the Metro shell.

Netflix stands behind DASH

Flash evangelists may feel that the limitations of HTML5 video and the problems that content creators are sure to face during the transition are a vindication of the proprietary plugin model. But the advantages of a truly open, vendor-neutral, and standards-based video solution that can span every screen really dwarf the challenges. That is why major stakeholders are going to be willing to gather around the table to try find a way to make it work.

Netflix already uses HTML5 to build the user interfaces of some of its embedded applications, including the one on the PS3. The company has soundly praised the strengths of a standards-based web technology stack and has found that there are many advantages. But the DRM issue and the lack of suitably robust support for adaptive streaming have prevented Netflix from dropping its Silverlight-based player in regular web browsers.

The company has committed to participating in the effort to make HTML5 a viable choice for all video streaming. Netflix believes that the new Dynamic Adaptive Streaming over HTTP (DASH) standard being devised by the Motion Picture Experts Group (MPEG) will address many of the existing challenges and pave the way for ubiquitous adoption of HTML5 for streaming Internet video.

DASH, which is expected to be ratified as an official standard soon, has critical buy-in from many key industry players besides Netflix, including Microsoft and Apple. An early DASH playback implementations is already available as a plugin for the popular VLC video application.

The DASH standard makes video streaming practical over HTTP and addresses the many technical requirements of high-volume streaming companies like Netflix, but it doesn’t directly address the issue of DRM by itself. DASH can be implemented in a manner that is conducive to supporting DRM, however.

DASH and DRM

Ericsson Research, which is involved in the DASH standardization effort, has done some worthwhile preliminary research to evaluate the viability of DRM on DASH. Ericsson produced a proof-of-concept implementation that uses DRM based on the Marlin rights management framework. Marlin, which was originally created by a coalition of consumer electronics vendors, is relatively open compared to alternate DRM technologies and makes use of many existing open standards. But Marlin is still fundamentally DRM and suffers from many of the same drawbacks, and adopters have to obtain a license from the Marlin Trust Management Organization, which holds the keys.

The architecture of the Marlin rights management framework

Ericsson explains in its research that it chose to experiment with Marlin for their proof-of-concept implementation because it’s available and mature — other similar DRM schemes could also easily be adopted. Existing mainstream DRM schemes would all likely pose the same challenges, however, and it’s unlikely that such solutions will be viewed as acceptable by Mozilla. More significantly, an implementation of HTML5 video that relies on this kind of DRM would undermine some of the key values and advantages of openness that are intrinsic to the open web.

The ease with which solutions like Marlin can be implemented on top of HTML5 will create pressure for mainstream browser vendors to adopt them quickly. This could result in the same kind of fragmentation that exists today surrounding codecs. As O’Callahan said, it’s easy to see this issue becoming far more contentious and challenging to overcome than the codec issue.

What next?

The transition to HTML5 and standards-based technology for video delivery will bring many advantages to the web. There are some great examples that show what can be achieved when developers really capitalize on the strengths of the whole open web stack. The inclusiveness of the standards process will also give a voice to additional contributors who want to expand the scope of what can be achieved with video on the web.

There are still some major obstacles that must be overcome in order for the profound potential of standards-based web video to be fully realized in the post-Flash era. Open standards still don’t deliver all of the functionality that content creators and distributors will require in order to drop their existing dependence on proprietary plugins. Supplying acceptable content protection mechanisms will prove to be a particularly bitter challenge.

Despite the barriers ahead, major video companies like Netflix recognize the significant advantages of HTML5 and are willing to collaborate with other stakeholders to make HTML5 video a success. The big question that remains unanswered is whether that goal can be achieved without compromising the critically important values of the open web.

See Also:

File Under: Browsers, HTML5
Nov
14
2011

HTML5 Games, Video Get Boost From Full-Screen API in Firefox Nightly

By

Support for the HTML full-screen API was recently enabled in Firefox nightly builds. It allows web applications to toggle the browser into full-screen mode and stretch a single page element so that it fills the user’s display.

The feature will be especially useful for the HTML5 video element, making it easy for developers to add native full-screen playback to their custom HTML video player interfaces. It will also likely be useful for games and other kinds of content where full-screen interaction is desirable.

The discussion surrounding HTML full-screen API’s began last year on the WHATWG mailing list. The WebKit team was experimenting with full-screen support for HTML5 video and was contemplating a more general API that could be used for any kind of web content. Mozilla’s Robert O’Callahan wrote up a proposal that fleshed out what the API might look like.

WebKit introduced support for the full-screen API earlier this year, and it’s already supported in Chrome stable releases. Mozilla recently rolled out its own implementation in nightly builds and is planning to deliver the feature to regular end users in Firefox 10.

Mozilla has taken a few steps to prevent abuse of the new API. A web application can’t arbitrarily make an element full-screen without user intervention — the operation has to be initiated by a user action. The mechanism that is used to enforce that safeguard is said to work much like a popup blocker.

Embedded content in an iframe element will be barred from initiating a full-screen operation unless the iframe is defined with a specific property. Additional details regarding the security of the full-screen feature have been published on the Mozilla developer wiki.

The addition of native full-screen support will help make standards-based web technologies more competitive versus plug-ins like Flash for building rich Internet applications. If you are running Chrome, a Firefox nightly, or other compatible browser, you can try out the full-screen feature for yourself by visiting this demo.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

See Also:

Tags:
File Under: APIs, HTML5, JavaScript, Multimedia, Web Standards
Nov
10
2011

Mozilla Reinvents Web Video With Popcorn 1.0

By

Video on the web has always been a bit disappointing. After all, it’s pretty much just like television, only smaller. Unlike the rest of the web, video is just as much a passive experience in your browser as it is anywhere else.

Mozilla would like to change that. The company’s effort to bring a more interactive video experience to the web is known as Popcorn.js and it recently reached 1.0 status. If you’d like to play around with Popcorn, head on over to the Mozilla site and download a copy. Popcorn uses HTML5 video features and at the moment works best in Firefox and Chrome.

At its core, Popcorn is about making HTML5 web video into something more than just another television.

While it’s nice to have a way to embed videos without Flash, HTML5 video is capable of much more than just, well, video. It’s HTML, after all. That means it can tap into things like WebGL, or use JavaScript to augment video in real time — annotating videos with information like location, details about the people and topics in the video, subtitles, Twitter feeds, current weather information, links and much more.

Popcorn is simply a JavaScript library that aims to simplify the process of adding external data culled from around the web to your video. To give an idea of what’s possible with Popcorn, Mozilla is showcasing the movie One Millionth Tower, a documentary film about an apartment building and how residents imagine the future. One Millionth Tower premiered online last weekend at Wired.com. If you haven’t seen it yet, head over to the Underwire blog.

One Millionth Tower uses some tricks beyond Popcorn (like WebGL for some 3-D elements), but most of its coolest effects — like the way the environment in the film changes based on the real-time weather conditions and time of day at the Toronto high-rises where the documentary was filmed — are all courtesy of Popcorn.

If it happens to be snowing in Toronto when you watch the film, it will begin snowing in the virtual world of One Millionth Tower. At other points in the film Popcorn pulls outside information from Flickr, Wikipedia, Google Maps and, of course, Yahoo Weather. Pretty much any web service with an API can be plugged into an HTML5 video in real time with Popcorn.

A more mundane but potentially more widespread use for Popcorn is subtitles. Using Popcorn, a set of subtitles attached to a video could be sent on to an online translation tool and converted to whatever language you wanted on the fly. Popcorn could then pipe the translation back into the video. In other words, subtitle your movie once and anyone will be able to understand it.

So how does Popcorn work? Well, Popcorn.js takes the native HTMLMediaElement properties, methods and events — collectively known as HTML5 video — and normalizes them into an API. The API has a plug-in system so developers can contribute and reuse code for common tasks. In fact, Popcorn already has dozens of plugins for most popular web services like Twitter, various maps, Facebook, Processing.js and, of course, all the services mentioned above in conjunction with One Millionth Tower.

In addition to the Popcorn.js framework, there’s also Popcorn Maker, a web-based graphical user interface for creating Popcorn-based videos. Popcorn Maker is the newest member of the Popcorn family and is not yet a 1.0 release. Its goal is to offer the familiar timeline controls you’d expect in video editing software, but at the moment it’s an alpha release and can be a little buggy. Popcorn Maker is powered by another bit of JavaScript, dubbed butter.js, which could be used to add Popcorn editing features to any desktop video editing software, though as of this writing we aren’t away of any popular video editing apps that use it.

To get started making Popcorn movies head on over to MozillaPopcorn.org, grab the source code, read the documentation, check out the plug-ins and try Popcorn Maker. Also note that, if you prefer, Popcorn can be checked out through GitHub.

Homepage photo: jennie-o/Flickr

See Also:

« OLDER POSTS