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.
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.
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.
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.
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.
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.
So far it ain’t so, but some form of DRM in HTML is becoming a more likely possibility every day. 
Browse Our Tutorials
Cheat Sheets
Color Charts
Cut & Paste Code