Archive for the ‘Web Standards’ Category

File Under: Browsers, Web Standards

Think One Fewer Browser Means Less Work? Think Again

WebKit: not actually one ring, but many, many rings. Image: Screenshot/Webmonkey

Opera software is abandoning its homegrown rendering engine in favor of the open source WebKit rendering engine. Many developers seem to think this means one fewer browser to test in, but unfortunately, that’s not the case.

The problem with the dream of less testing because there’s more WebKit is that “WebKit” can mean many things. The WebKit in Safari does not have all the features you’ll find in the WebKit that powers Google Chrome. The situation gets even more complicated with mobile where there are about as many different versions of WebKit as there are browsers.

As Mozilla’s Rob Hawkes and Robert Nyman point out in the post WebKit: An Objective View, that means “each browser will still have its own quirks, performance differences, design, and functionality. These should all be tested for.”

Worse, individual WebKit browsers can pick and choose which APIs to include in their final builds, which means just because something is available in WebKit, does not mean it’s available in, for example, both Chrome and Safari. Couple this with Safari’s relatively slow release schedule and just the two major desktop WebKit variants are going to require testing to make sure everything works.

Throwing a WebKit-based Opera in the mix just means another WebKit browser that needs to be part of your testing.

There’s nothing wrong with this state of affairs, nor will it change all that much when Opera is on WebKit as well, but it won’t mean less testing, nor is it going to make web developers’ lives any easier (especially since most of them weren’t testing in Opera anyway).

Testing will always be a necessary part of web development, but the danger that Hawkes and Nyman foresee is that developers will test less because they assume that if something works in one version of WebKit it will work in all of them. While that hasn’t happened yet, the CSS prefix debacle certainly doesn’t bode well for the WebKit-heavy future.

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: HTML, Web Standards

‘Main’ Element Lands a Starring Role in HTML

Original Image by Christian Haugen/Flickr

HTML5 introduces several new tags that give HTML more semantic meaning. There’s <nav> for navigation elements, <header> for headers, <footer> for footers and now a new element has been added to the HTML draft spec<main>, to wrap around, well, the main content on a page.

As we reported back when the W3C’s HTML Working Group first considered adding it to the list of HTML elements, the primary purpose of the main element is to map the WAI-ARIA landmark role “main” to an HTML element.

Thanks to the hard work of developer Steve Faulkner, who wrote up the proposal for <main> and did much of the hard work convincing the Working Group that it was worth adding to the spec, you can start using the main element today. In fact <main> is already natively supported in nightly builds of Firefox and Chrome.

There’s an ongoing debate as to whether more than one <main> element should be allowed on the page. Currently the W3C’s draft of the spec explicitly prohibits more than one <main> per page, but the WHATWG’s version of the spec is less specific.

It might sound counter-intuitive to have more than one <main> per page, but the argument is that the rest of the new block level tags have no such restrictions. In other words, there can be more than one <header>, more than one <footer> and more than one <nav> so why not more than one <main>? Developer Jeremy Keith has a post on why more than one <main> could be a good idea. [Update: There’s also been some discussion on the HTML WG mailing list and a call for supporting data. As Steven Falkner notes in the comments below “the discussion continues, but at this stage there is no evidence that such a change will bring a benefit to users and may well complicate the usage of the feature and dilute its meaning and benefit for users.”]

For now we suggest sticking to just one main element per page, which simplifies using <main>. Chances are you have something like <div id="main"> in your code right now. To use the new main element, just rewrite that to be <main role="main">.

The role="main" may seem redundant, and someday it will be, but right now it acts as a polyfill for older web browsers, ensuring that they map the element to accessibility APIs. Older browsers will also need to be told about the element’s block level status with main {display:block;}. HTML5 shiv, a popular way to add support for the new elements to older browsers, has already been updated to support <main>.

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: Web Basics, Web Standards

New Community Project Brings Web Accessibility to the Masses

Tim Berners-Lee, W3C Director and inventor of the World Wide Web, once said that “the power of the Web is in its universality…. Access by everyone regardless of disability is an essential aspect.”

Sadly the universal accessibility of the web remains more of a goal than a reality — not because it can’t be done, the tools exist, but because developers often neglect it.

The Accessibility Project is a new effort to help “make web accessibility easier for front end developers to implement.”

The Accessibility Project is relatively new, but already has a ton of great resources — everything from tutorials on how to hide content but still make it accessible to screen readers, to a handy checklist you can use to make sure you’ve covered the accessibility basics before you launch.

There’s also a great collection of links to accessibility resources, tools and tutorials around the web.

The Accessibility Project is very much a community effort, with all of the source code and posts on the site hosted on GitHub. If you’d like to contribute, head on over and read through the contribution guidelines before you fork the project.