Archive for the ‘HTML5’ Category

DRM for the Web? Say It Ain’t So

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.

File Under: Browsers, HTML5

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

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, <html contenteditable>

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.

File Under: Browsers, HTML5, Web Standards

Microsoft Simplifies Internet Explorer Testing With ‘Modern.IE’

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.

File Under: HTML, HTML5, Web Basics

Skip the Lists for a More Accessible Web

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: <ul>. The vast majority of tutorials – if not all – you’ll ever see for creating navigation menus use the familiar list element structure, nesting links inside <li> 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 <nav> element examples.

There is, as CSS-Tricks’ Chris Coyier writes, “no debate” about how menus should be marked up. But HTML5 adds the <nav> 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 <nav> 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 <nav> 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.”

File Under: Browsers, HTML5, Multimedia

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

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

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.