Webmonkey » HTML5

Netflix Plans to Ditch Silverlight for HTML5

Scott Gilbertson — Tue, 16 Apr 2013 17:00:10 +0000

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.”

W3C Drops ‘hgroup’ Tag From HTML5 Spec

Scott Gilbertson — Thu, 11 Apr 2013 12:45:21 +0000

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.

Dropzone.js Adds Drag-and-Drop File Uploads to Any Site

Scott Gilbertson — Tue, 26 Feb 2013 20:50:41 +0000

New web technologies tend to travel a trajectory that moves from “amazing demo with fiendishly complex code”, to “very cool product feature” and finally to open source library that takes 10 seconds to add to your page. Today’s cutting edge demo is tomorrow’s jQuery plugin.

Take drag-and-drop file uploads for instance. The HTML5 File API ostensibly solves one of the most common complaints from web app users — why can’t I just drag and drop files like I do everywhere else? Well, then you could, but it wasn’t easy to build.

Then drag-and-drop file uploads became part of Gmail, which meant it was only a matter of time before a jQuery plugin appeared. In fact there are several jQuery plugins that cover this ground, but one particularly nice newcomer is Dropzone.js.

Dropzone.js makes it dead simple to add a drag-and-drop file uploader to any website, complete with previews of uploaded files. Dropzone also supports the traditional file-picker uploading as well; you don’t have to drag and drop.

Dropzone supports most modern web browsers, including Chrome 7+, Firefox 4+, IE 10+ and Safari 5.

If you’re interested, head on over to GitHub and grab the source code (obviously the plugin requires jQuery, but there is a version that will work with RequireJS as well). Also be sure to read through this Hacker News thread for some similar projects and possible alternatives for those who’d like to avoid the jQuery overhead.

Video: How ARIA’s Landmark Roles Work

Scott Gilbertson — Mon, 18 Feb 2013 17:00:53 +0000

We’ve written a lot about how you can make your website more accessible with WAI ARIA roles, particularly ARIA’s Landmark roles. As a bonus you can also use the roles to style elements.

Hopefully you’re using ARIA roles given that they’re such a simple, easy win with pretty much no downside, but have you ever wondered exactly how ARIA roles help people using assistive devices? In the video above accessibility consultant Leonie Watson gives a quick demo of exactly how screen readers benefit from landmark roles.

If you’re sold be sure to read up on our earlier coverage, including this post on how to add landmark roles to your site. The site Watson mentions in the video is also a great ARIA resource. Also have a look at accessibility guru Steve Faulkner’s recent post over on the The Paciello Group blog.

And note that, as Faulkner writes, “over time the necessity of explicitly assigning landmarks will lessen as browsers build in ARIA landmark roles to newer HTML element semantics.” For now though, even if you’re already using the new elements, it doesn’t hurt to add the roles as well.

Improve Your Website’s Accessibility With the W3C’s ‘Guide to Using ARIA’

Scott Gilbertson — Thu, 14 Feb 2013 21:40:40 +0000

WAI-ARIA, the W3C’s specification for Accessible Rich Internet Applications, 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 looked at how you can use ARIA roles to not just improve your site’s accessibility, but style elements as well, but now you can get the official word from the W3C. The W3C has published the First Public Working Draft of Using WAI-ARIA in HTML.

The W3C’s guide goes beyond the ARIA Landmark Roles that we’ve covered in the past, offering suggestions on how ARIA can help with HTML5 apps that load dynamic content or build entire interfaces with JavaScript. In fact, this is where the true power of ARIA comes into play since there is often no other way for assistive devices to get at your application’s data.

Unfortunately not everything in the ARIA spec works in every screen reader. Support for the landmark roles is pretty solid, but much of the rest remains a work in progress. As always there’s no substitute for real world testing.

DRM for the Web? Say It Ain’t So

Scott Gilbertson — Tue, 12 Feb 2013 16:20:13 +0000

So far it ain’t so, but some form of DRM in HTML is becoming a more likely possibility every day.

The W3C’s HTML Working Group recently decided that a proposal to add DRM to HTML media elements — formally known as the Encrypted Media Extensions proposal — is indeed within its purview and the group will be working on it.

That doesn’t mean that the Encrypted Media Extensions proposal will become a standard as is, but it does up the chances that some sort of DRM system will make its way into HTML.

The Encrypted Media Extensions proposal — which is backed by the likes of Google, Microsoft, Netflix and dozens of other media giants — technically does not add DRM to HTML. Instead it defines a framework for bringing a DRM system, or “protected media content” as the current draft puts it, to the web.

If you think the idea of DRM seems antithetical to the inherently open nature of HTML, you’re not alone. Ian Hickson, former editor of the W3C’s HTML spec, has called the Encrypted Media Extensions proposal “unethical.” Hickson is no longer in charge of the W3C’s HTML spec, but HTML WG member Manu Sporny, has already asked the WG not to publish the first working draft because the “specification does not solve the problem the authors are attempting to solve.”

There are numerous problems with the Encrypted Media Extensions proposal, including the basic fact that, historically, DRM doesn’t work.

Other problems specific to the current draft of the proposal include the fact that it might well be impossible for open source web browsers to implement without relying on closed source components. Then there are the gaping security flaws that would make it trivially easy to defeat the currently defined system.

But Sporny raises a far more ominous objection — that the proposal in its current form does not actually define a DRM system. Instead it proposes a common API, which would most likely lead to a proliferation of DRM plugins. Here’s Sporny’s take:

The EME specification does not specify a DRM scheme in the specification, rather it explains the architecture for a DRM plug-in mechanism. This will lead to plug-in proliferation on the Web. Plugins are something that are detrimental to inter-operability because it is inevitable that the DRM plugin vendors will not be able to support all platforms at all times. So, some people will be able to view content, others will not.

That sounds a lot like the bad old days when you needed Flash, Real Player, Windows Media Player and dozens of other little plugins installed just to watch a video.

That’s a web no user wants to return to.

At the same time there continue to be companies which believe DRM is essential to their bottom line and the web offers no solution. That’s why Flash, Silverlight and other DRM-friendly plugins remain the media players of choice for many content providers.

So the question of DRM on the web boils down to this: should the W3C continue to work on a spec that defines some kind of DRM system or should the interested companies go off and do their own work? For its part the W3C clearly wants to be part of the process, though it remains unclear what, if any, value a standards-based DRM system might have for web users.

Turn Your Browser into a Notepad With a Single Line of HTML5

Scott Gilbertson — Fri, 01 Feb 2013 21:38:16 +0000

Finally, an editor so simple even Snoopy won’t get distracted. Image: Webmonkey

If you ever need a quick scratchpad to just write, not save what you write, but just write, you can quickly turn your web browser into an ultra-basic notepad with a single line of HTML.

This clever trick comes from developer Jose Jesus Perez Aguinaga who says that “sometimes I just need to type garbage. Just to clear out my mind. Since I live in the browser, I just open a new tab and type”:

data:text/html,

Thanks to the HTML5 contenteditable attribute and the modern browser’s ability to handle data URIs, your browser is now a notepad — just click to type.

Of course there’s no easy way to save your work, so while this is probably the most minimal editor you could hope for, it isn’t the most practical for actual work. Still a great trick though. Check out the comments on Aguinaga’s post and on this Hacker News thread for some enhancements to the basic idea (like what I used for the screenshot above) and a Chrome extension.

Microsoft Simplifies Internet Explorer Testing With ‘Modern.IE’

Scott Gilbertson — Thu, 31 Jan 2013 16:50:55 +0000

Image: Screenshot/Webmonkey.

Microsoft has launched a new site, Modern.IE, aimed at simplifying the sometimes arduous process of getting websites to work in older versions of the company’s Internet Explorer web browser. The new site also serves to promote web standards and help developers avoid mistakes like only supporting WebKit browsers, roughly the modern equivalent of the regrettable “works best in IE6″ websites of 2001.

Modern.IE consists of three main tools — a site scanner that will look at your code and detect potential problems for older versions of IE, a cross-browser testing tool (part of a partnership with BrowserStack) and a set of guidelines for building sites with web standards.

The most useful of the bunch is the first, the site scanner. Plug your URL into the scanner and it will come back with a list of possible compatibility problems, some unique to older versions of IE, some more general, like outdated JavaScript libraries. Like other tools of this sort — think Yahoo’s YSlow, but here the emphasis is cross-browser compatibility rather than speed — Modern.IE then offers suggestions for fixing the problem.

Or at least usually it does. In some cases it will apparently tell you to get in touch with Microsoft engineers instead for what Microsoft’s Ryan Gavin calls “security and privacy reasons.” It’s also worth noting that Modern.IE still suggests running your site through Compat Inspector, and of course, while Modern.IE is handy for catching larger issues it’s no substitute for actual cross-browser testing.

Microsoft has also included two suggestions that may irritate some developers — adding two snippets of Microsoft-specific code. The first is pretty innocuous, it’s just a bit of code to set an image so users can add your site to the new Windows 8 home screen with a “tile.” Yes, it’s Microsoft-specific code, but the Win 8 home screen images are no different than the Apple-specific apple-touch-icon code that’s probably on your site right now. The second suggestion is to add a bit of CSS to support Microsoft’s proposed MSPointers API. The MSPointers API actually looks quite useful, but suggesting developers use it now smacks of hypocrisy given that elsewhere on the site Microsoft suggests that developers stick to “stable standards.” The MSPointers API isn’t a standard at all, let alone stable.

The second major part of Modern.IE is Microsoft’s partnership with BrowserStack, a service that offers live, web-based browser testing through virtual machines. As part of the partnership you can use BrowserStack free for three months. After that BrowserStack’s regular pricing starts at $20/month for individuals.

Microsoft has also put together “back level versions of Windows and Internet Explorer” as virtual machine images so you can do your more thorough testing locally if you prefer. That means Windows XP, Windows Vista and Windows 7 operating systems with their companion browser versions IE6, 7, 8 and 9. At the moment there are only images available for Windows Server, but a Microsoft representative tells Webmonkey that VMs for Mac And Linux will be available later today.

The last part of Modern.IE is the “code with standards” section which offers an article on “20 tips for building modern sites while supporting old versions of IE.” Most of the advice is sound, though it does advocate for a conservative approach to web standards that’s not necessarily in keeping with the pace of the web.

That last aspect may put some developers off, though it’s worth noting that the Modern.IE site does not adhere to its own conservative approach. Instead the site does exactly what most savvy developers are already doing — using HTML5 and CSS 3, but including Modernizer to help make the site work in older versions of IE.

While the site is obviously geared specifically to toward developers that need to get their sites working in older versions of IE, most of the advice — particularly the emphasis on progressive enhancement — is sound advice for anyone building websites today.

Skip the Lists for a More Accessible Web

Scott Gilbertson — Wed, 30 Jan 2013 19:45:36 +0000

Soupe du jour: tags. Image: clogozm/Flickr

Somewhere far in the web’s primordial past it was decided that the best way to mark up a menu in HTML was to use the unordered list element:

tags. Menu plugins for WordPress and other popular publishing systems use lists for menus as well. Even the HTML5 spec uses an unordered list in its
element examples.

There is, as CSS-Tricks’ Chris Coyier writes, “no debate” about how menus should be marked up. But HTML5 adds the
element and there’s also a navigation role in WAI-ARIA so should we still be using lists to mark up menus?

Coyier says no. He’s dropped lists from his
elements and instead uses just links and span tags. Coyier cites a talk by Reinhard Stebner, who is blind, and suggests that with most screen readers the far better solution for menus is to use divs and spans for menus.

Be sure to read through Coyier’s post for some more data on why ditching the list might be a good idea and check out Jim Doran’s write up on Stebner’s original talk, which makes a distinction between accessible and usable. That is, a technically “accessible” site might still be a usability nightmare for some users.

However, as Mozilla’s Chris Heilmann points out in the comments of Coyier’s post, the problems lists cause in some screen readers are really a result of the sorry state of screen readers. “Screen readers are damn slow to update and vary immensely between different versions… I gave up a long time ago calling something accessible or not when it works in Jaws.”

Lists for menus have advantages over the div and span route, like some extra elements for styling and the fact that they render as, well, lists even in the absence of CSS.

What do you think? Are lists for menus a legacy workaround we no longer need in the day and age of
and role="navigation"? Or do they still offer enough advantages to keep using for menus?

For his part Coyier says he’s going to keep building list-free menus. “Until I see some solid research that suggests that’s dumb, I’m sticking to it,” he writes. “As always, the best would be to get more information from real screen reader users like Reinhard.”

Mozilla Brings Native H.264 Video to Desktop Firefox [Updated]

Scott Gilbertson — Wed, 23 Jan 2013 16:37:19 +0000

Look Ma, H.264 video in Firefox, no Flash necessary. Image: Screenshot/Webmonkey.

The latest nightly builds of desktop Firefox now support the ubiquitous H.264 video and MP3 codecs. When the current Firefox Nightly arrives in final form later this year, Firefox users will no longer need the Flash plugin to play H.264 web video in Firefox.

Firefox for Android and Firefox OS already support H.264 and MP3, but on the desktop the new H.264 support is, thus far, only available in the Windows 7 Nightly release.

You can grab the latest version of Firefox Nightly from the Nightly downloads page. Once installed head to about:config and turn on the preference media.windows-media-foundation.enabled.

Mozilla long opposed supporting the H.264 codec because it’s patent-encumbered and requires licensing fees. For better or worse it’s also the most popular codec for HTML5 video on the web, which drove Mozilla to take the pragmatic approach and add support to Firefox. Instead of including the codec directly in Firefox, the browser will rely on OS-level tools to play H.264 video.

Eventually all platforms except Windows XP will get OS-native codec support for H.264 video. Windows XP, which lacks OS-level tools for H.264, will continue to use the Flash plugin to play H.264 movies.

Even if you’re not a Windows 7 user there are still a few new tricks in Firefox Nightly, including a revamped downloads panel that’s no longer a separate window (and which bears more than a passing resemblance to what you’ll find in Safari 6) and support for the new CSS scoped style attribute.

[Update: As BWRic points out in the comments below the new downloads window/panel design was actually a Firefox innovation that the Safari team got around to implementing first. You can check out former Firefox UX Lead Alex Limi's original sketches of the overlay window on his blog as well as a follow up post when Safari revealed its take on the design. It's worth noting that Limi's sketches have a nice progress bar in the icon (which Safari adopted as well), which is missing from the current Firefox implementation.]

Firefox’s coming Safari-style downloads window. Image: Screenshot/Webmonkey.

For more on what else is coming in future versions of Firefox, check out the Mozilla blog’s Bleeding Edge and Firefox Development Highlights series.