Archive for the ‘Web Standards’ Category

File Under: CSS, Web Standards
Feb
10
2012

Web Developers Sound Off on WebKit Prefixes

By

Photo: Ariel Zambelich/Wired.com

Yesterday we told you about a disturbance in the web standards force, a supposed rash of websites that work in one and only one web browser. Instead of writing code that will work in any browser many developers are coding exclusively for WebKit, the engine that powers Safari, Chrome, iOS and Android web browsers.

The problem is bad enough that on Monday at the CSS Working Group meeting, Microsoft, Mozilla and Opera announced that each are planning to add support for some -webkit prefixed CSS properties. In other words, because web developers are using only the -webkit prefix, other browsers must either add support for -webkit or risk being seen as less capable browsers even when they aren’t.

We aren’t the only ones who think that spells disaster not just for web standards but for the long-term viability of the open web. In fact the response from the web community has all but drowned out everything else in our RSS and Twitter feeds.

Here’s our round-up of what’s being proposed, what it might mean for the web and how we might go about solving the problem:

First and foremost read the minutes from the CSS Work Group meeting, which is where all of this started. The legend for the names is at the top of the page, though you’ll need to scroll about half way down to get to the actual meat of the discussion.

The second must-read post on vendor prefixes comes from CSS Working Group Co-Chair Daniel Glazman who calls on other browser makers to not implement the -webkit prefix and asks developers to make the extra effort to build cross-browser apps. Glazman has since followed up that piece with two more, one clarifying the original post and one defending the CSS Working Group against those who argue that the reason prefixes exist is because the standards process is too slow. If you believe that the CSS spec moves to slowly, this post is well worth a read (spoiler alert: it’s typically browser makers arguing, not the standards process, that creates the hold up on new features).

Remy Sharp of HTML5Doctor fame, weighs in with a series of rough ideas, neatly summarizing the issue and looking at it from both sides. In the end Sharp seems to conclude that just about everyone is to blame, from the browsers to the working group to developers.

Rachel Andrew of the web standards project generally agrees with Glazman writing, “once again we run the risk of having sites built only for one platform, and [will] find it very hard to get that platform to go away if things move on.”

The ever-humorous Bruce Lawson, who works as a web standards evangelist at Opera Software, writes: “Personally — PERSONALLY — I’m pretty depressed about all this. I’ve spent 10 years — pretty much since IE6 came out — evangelizing cross-browser, accessible, standards-based sites. As a development community we chased the Shiny and we caused IE6 to linger around like a vindaloo fart in a windowless loo. And now we’re doing the same again.”

Over at Quirksblog mobile expert Peter-Paul Koch argues that vendor prefixes are just plain wrong: “Vendor prefixes are the most developer-hostile solution imaginable. The vendor prefix idea was flawed from the start by putting the full brunt of namespace management on web developers.” He goes on to propose an interesting idea of vendor-neutral prefixes like -alpha and -beta for experimental features.

Aaron Gustafson, a member of the Web Standards Project, has started a petition to ask Mozilla, Microsoft and Opera to not implement -webkit. Gustafson also has a one-line bash script you can use to search your code for any instances of the -webkit prefix so you can double check to make sure you’re supporting other browsers as well.

Mozilla developer Christian Heilman believes that “this mess has partly been created by developers, the least we can do is help fix it.” To that end Heilmann’s Pre-fix the web project is looking for developers willing to seek out projects on Github that only work in Webkit and then fork the project, adding the missing prefixes to the CSS, extending JS code to do proper feature detection and then sending a pull request. In other words, literally fixing the web.

JavaScript developer Peter van der Zee has some other possible solutions: “Either we strongly limit the life span or availability of the prefix by making them only available in beta versions of a browser. Or we force other vendors to pick up on the slack by giving them a certain time to come up with their own implementation of a certain feature, or forfeit that possibility after a certain amount of time.”

Finally, if you read through the CSS WG notes you’ll notice that Tantek Çelik cites developer Lea Verou as an example of web developers who use just the -webkit prefix. In fact that’s completely untrue and Çelik has since corrected his statement. Verou has long advocated using all prefixes and even created prefixfree to help automate the process.

Tags: , ,
File Under: CSS, Web Standards
Feb
9
2012

WebKit Isn’t Breaking the Web. You Are

By

WebKit may seem like the only game in town, but it's not. Photo: Ariel Zambelich/Wired.com

It sounds like something from a galaxy far, far away, but in truth it was not that long ago that the web was littered with sites that proudly proclaimed “works best in Internet Explorer.” Thankfully those days are over. IE6 no longer dominates the web.

But, while IE6 may be a thing of the past, the root problem — websites that work in one and only one web browser — sadly, remains.

This time the culprit is WebKit, the rendering engine that powers the browsers on the iPhone, iPad and Android phones. But what’s different about this round of monoculture is that, unlike IE 6, the WebKit developers haven’t done anything wrong. It’s web developers that have created the WebKit-only web.

Instead of writing code that will work in any browser, which might mean adding an extra three lines of code to their CSS rules, some of even the largest sites on the web are coding exclusively for WebKit.

The problem is bad enough that on Monday at the CSS Working Group meeting, Microsoft, Mozilla and Opera announced that each are planning to add support for some -webkit prefixed CSS properties. In other words, because web developers are using only the -webkit prefix, other browsers must either add support for -webkit or risk being seen as less capable browsers even when they aren’t.

The danger is that if other browsers implement -webkit prefixes then the entire CSS standards effort will be broken. Instead of coding against a single CSS specification developers will need to code against changing vendor prefixes. As CSS Working Group co-chair, Daniel Glazman, says, “I don’t think this is the right way. And this is the first time in this WG that we are proposing to do things that are not the right way.”

Vendor prefixes like -webkit and -moz were designed to help web developers by allowing browser makers to implement CSS features before the official standard was published. Prefixes were intended to help speed up the process of adding new features to the web and, used properly, they have worked. Unfortunately they’ve also been widely abused.

WebKit is currently the dominant mobile browser in the mind of most web developers (that Opera is actually the single most widely used mobile browser). But even the perceived dominance of WebKit is not the real problem. The problem is — just as it was last time — that web developers are developing exclusively for WebKit.

To be clear, Firefox, IE and Opera also support these features. In most cases, the -webkit properties being used have -moz, -ms and -o prefix equivalents for use in the respective browsers. Popular CSS 3 features like border-radius, transforms, gradients and animations work in all modern browsers. Developers simply need to add those three additional lines of code to make their websites compatible with Firefox, IE and Opera. But they aren’t doing that.

That the problem lies with web developers, not the browsers, led Glazman, to put out a call for action, asking web developers to “stop designing web sites for WebKit only, in particular when adding support for other browsers is only a matter of adding a few extra prefixed CSS properties.”

Neither Glazman, nor anyone else is suggesting that Apple and Google should stop innovating or stop implementing new features as fast as they can. As Tantek Çelik, a Mozilla representative in the CSS WG, says in the minutes of Monday’s meeting, “I think it’s great that Apple wants to innovate as fast as they can…. I don’t want Apple to slow down in innovation and implementing new things. That helps the Web grow and innovate.”

At the same time both Apple and Google have set some bad examples by building a number of WebKit-only demos that might be part of what lead some developers to conclude that only WebKit supports such features. That has also spilled over into the world of tutorials where even sometimes even standards advocates showcase -webkit in their sample code while ignoring -moz-, -ms- and -o-*.

What makes the current -webkit-only epidemic all the more depressing is how easy it is to solve — just use prefixes they way they were intended. Thanks to modern toolkits you don’t even need to write any extra code. Preprocessors like SASS and LESS make it easy to output five lines of prefixed code with a single mixin. Not a fan or SASS or LESS? No problem, just use cssprefixer, which parses your CSS and adds any prefixes you need before you publish it to the web (there’s also a client-side auto-prefixing solution if you prefer).

That’s fine for your website, but what about all the rest of those top 30,000 sites you don’t control? Well, you could email the developers, let them know that their site isn’t working in the most popular mobile web browser; let them know that you can’t use their service. If you’re a programmer or web developer you can help out with Mozilla developer Christian Hellman’s effort to Pre-fix the web. Pre-fix the web is looking for developers willing to seek out projects on Github that only work in Webkit and then fork the project, adding the missing prefixes to the CSS, extending JS code to do proper feature detection and then sending a pull request. In other words, literally fixing the web.

We at Webmonkey hope it’s obvious that building WebKit-only sites is a waste of time. If you’re only interested in iOS users then take a tip from Instagram and build a native app. As Peter Linss, Hewlett-Packard’s CSS WG representative says the CSS WG minutes, “there’s no advantage to the Web to have someone write a platform-specific website.” There’s also no real advantage for the developer, especially when an automated prefixer can do all the work for you. If you want your site to embrace the web, take the time to learn the craft and embrace all of the web. Be good at what you do and do it right.

Tags: , ,
File Under: CSS, Visual Design, Web Standards
Feb
8
2012

Responsive Design Tricks: Fluid Typography With CSS 3

By

Photo: Ariel Zambelich/Wired.com

Building responsive websites means that your design has to adapt to different screen sizes. That there is no such thing as “pixel perfect” has long been a maxim of good web design, but nowhere is this more true than when you start working with percentage widths, em-based type and other flexible techniques of responsive design. While fluid grids, adaptive images and other tools help, sometimes even basic things like the flow of type can look wrong without a little extra help.

One common problem when designing for multiple devices is handling the changes that happen when the user rotates the screen. It’s frustrating to see your elegant portrait-oriented designs fall apart as the device moves to landscape mode (or vice versa). Frequently the problem is that images, videos and other embedded content in your page is sized in relation to the pixel width of the viewport, but the type is not. That means that the type fails to adapt to layout changes, leaving ugly gaps, whitespace or hard-to-read, overly long lines.

There are a number of ways to solve this problem, but one of the simplest and easiest is to use fluid typography in addition to your fluid grid. BBC developer Mark Hurrell wrote up an excellent tutorial some time ago that shows how, by specifying font sizes in rems, you can “adjust every font-size on the page by using media-queries to change the font-size set on the BODY or HTML element according to viewport width.”

To find the right size type for various screen widths, Hurrell calculates a resolution-independent font scale based on target widths. That is then applied using a series of media queries and the new CSS 3 unit rem. The rem unit means ems relative to the root (the HTML) element. That means your type gets proportionally larger overall, rather than in relation to its parent element as would happen with a simple em. As Hurrell notes, support is pretty much universal on tablets and phones (browsers that don’t support it will fall back to px sizing, so all is not lost).

In the end what you get using rems and media queries is fluid typography that scales just like a fluid grid. That means that when the device rotates the type resizes to fit the new screen dimensions. For more details on how to make it work on your site be sure to check out the Responsive News blog post, which also has a few links to websites already using this trick.

Tags: ,
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: Web Standards
Jan
25
2012

Google Works on Internet Standards with TCP Proposals, SPDY Standardization

By

As part of Google’s continuing quest to dole out web pages ever more quickly, the search giant has proposed a number of changes to Transmission Control Protocol (TCP), the ubiquitous Internet protocol used to reliably deliver HTTP and HTTPS data (and much more besides) over the ‘net.

Google’s focus is on reducing latency between client machines and servers, and in particular, reducing the number of round trips (either client to server and back to client, or vice versa) required. When data is sent over a TCP connection, its receipt must be acknowledged by the receiving end. The sending end can only send a certain number of packets before it must wait for an acknowledgement. The time taken to receive an acknowledgement is governed by the round-trip time (RTT). With high bandwidth, high latency connections, clients and servers can end up spending most of their time waiting for acknowledgements, rather than sending packets.

When a new connection is made, a computer may initially send three packets before acknowledgement is required. Google wants to increase this to 10. With 10 packets, a browser can typically deliver an entire HTTP request to a server before it has to stop and wait for a reply.

TCP connections require a certain amount of negotiation between client and server, requiring a round trip, before data can be sent. Google is proposing to modify TCP so that some data can be sent during that negotiation, so that the server will have it on hand already, and can start processing it straight away.

TCP waits a predetermined time (the RTO or retransmission timeout) for acknowledgments to arrive. If the RTO expires, unacknowledged packets are assumed lost and retransmitted. This ensures that if the data has been lost in transmission that the sender is never waiting for an acknowledgement that will never arrive. This timeout value varies according to the network conditions and RTT, with a default of three seconds. Google wants to reduce this default to 1 second, so that if data has been lost, neither end needs to wait so long before it has another go.

Finally, Google wants to use a new algorithm to adjust how TCP connections react to packet loss. Packet loss can indicate networks that are congested, and TCP reacts by reducing the rate at which data is sent when this congestion is detected. The company claims that the algorithms currently used to respond to this packet loss can exact too great a penalty, making connections slow down too much and for too long, and that its new algorithm is better.

In addition to these proposed changes, Google is also suggesting other modifications, especially to make TCP recover better on mobile networks.

Changing TCP is not to be taken lightly. The protocol is already suffering due to buffer bloat undermining its built-in handling of network congestion. While Google’s proposed changes are well intentioned and might improve network performance, they come with the risk that an overlooked problem or a bad interaction with other traffic could cause widespread damage to the internet.

The proposed changes to TCP to reduce latencies and start sending data sooner are a continuation of previous work Google has done to try to make web serving, in particular, faster. The company has previously proposed other modifications to protocols such as SSL to similarly accelerate data transmission.

More far-reaching than these SSL tweaks is Google’s proposed alternative to the HTTP protocol that underpins the web: SPDY.

Initially, SPDY was a proprietary Google protocol implemented only in Google’s Chrome browser. That’s changing, however. Amazon’s Silk browser includes SPDY support, and Firefox 11 will include preliminary SPDY support. Partially motivated by SPDY’s uptake, the IETF’s HTTPbis Working Group — the team of industry experts tasked with maintaining and developing the HTTP specification — is considering the development of a new specification, HTTP/2.0, with the goal of improving the performance of HTTP connections. The working group will solicit suggestions from the industry, and with two, soon to be three implementations already, SPDY is likely to be well placed among those suggestions.

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

Photo: Ariel Zambelich/Wired.com

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: Web Standards
Dec
12
2011

Is Apple Using Patents to Hurt Open Standards?

By

Opera developer Haavard Moen has accused Apple of repeatedly using patents to undermine the development of web standards and block their finalization.

World Wide Web Consortium (W3C), the industry group that governs and oversees the development of web standards, requires that every specification it approves be implementable on a royalty-free basis, barring extraordinary circumstances that justify an exception to this rule. The specifications can contain patented technology, as long as royalty-free patent licenses are available.

Members of W3C—a group that includes representatives from Apple, Microsoft, Google, Mozilla, and Opera—are required to disclose any patents that they hold that are relevant to each specification. Depending on how far the specification is through the standardization process, they have between 60 and 150 days to make this disclosure.

If royalty-free licensing is available, the specification can proceed as normal. Participation in the development of a particular specification obliges W3C members to offer royalty-free licensing for technology used in that specification. Nonparticipants can also voluntarily offer a royalty free license, but they are not obliged to.

If, however, there is no commitment to offer royalty-free licensing for the patents in question, a Patent Advisory Group (PAG) is formed. The PAG will then assess whether the patent is truly applicable to the specification, and if so, how best to address the issue. The PAG might then seek prior art to invalidate the patent, or it might recommend that the specification be modified, to work around the patent. It might even advise abandonment of the specification. Only in exceptional circumstances will it decide that the specification should stand, in spite of the lack of royalty freedom.

Without an appropriate patent grant, browser vendors—whether open source or proprietary—cannot implement the specification without opening themselves up to a lawsuit. Such specifications would be, at best, an extremely risky proposition for anyone seeking to develop a browser, and none of the major browser vendors would even consider implementing a specification with known unlicensed patents.

Haavard identifies three separate occasions, twice in 2009, and again in 2011, where Apple has disclosed patents and not offered royalty-free licensing. In the first 2009 patent claim, Apple said that it had a patent covering W3C’s “widget” specification. A PAG was formed, and determined that Apple’s patent was not relevant. In the second 2009 claim, Apple claimed to have two patents covering W3C’s widget security specification. A PAG was again formed. It decided that one patent was not relevant, and the other didn’t apply. With both 2009 claims, Apple waited until the last minute to disclose its patents.

Touch Events

This time, Cupertino is claiming to have three patents, and an application for a fourth, that cover some of W3C’s touch event specification. This time the disclosure was made with about a month left to go. Again, the lack of royalty-free licensing means that a PAG is likely to be formed.

This in turn will delay the development of the specification and cost W3C members further time and money. The PAG process is not quick; the widget security PAG did not deliver its verdict until October of this year.

Haavard’s conclusion is that there is a pattern of behavior here; that Apple is trying to disrupt the standards process with its patent claims. He references the touch specification in particular—this is plainly an area where Apple has lots of expertise and interest in the technology, but the company opted out of working on the specification. If Apple had worked on the specification, it would have had to disclose sooner and offer licensing, and Haavard believes that avoiding this commitment is why Apple refused to work on the specification.

Apple’s is acting within its rights. W3C obliges members to disclose patent claims, and Apple is duly disclosing them. However, it’s easy to be sympathetic to Haavard’s argument. The two prior PAGs that resulted from Apple’s refusal to offer royalty-free patent licenses delayed and inconvenienced W3C, but ultimately on both occasions the groups decided that Apple’s patent claims were irrelevant. If Apple was hoping to keep some technology to itself, it did not succeed.

Moreover, W3C doesn’t require patent-holders to give up their competitive advantage. It’s acceptable to W3C for the royalty-free patent licenses to only cover implementations of the W3C specifications; if Apple wants to permit the royalty-free use of its touch patents in HTML5 browsers, but nowhere else, this would be an option. Such terms would allow browsers to implement the standard but still keep the technology off-limits to, for example, Android. But Apple did not offer such terms before, and so it seems unlikely that it will offer such terms this time.

Further, the only likely result of this is that Apple’s patents simply get worked around. W3C’s aversion to royalties means that it’s unlikely that it would accept any non-free license (should Apple even offer one), and the importance of touch input to phones and tablets means that W3C is unlikely to abandon the specification altogether. There’s no win possible for Apple—just wasted time and money for those seeking to make the web a more effective, more open platform.

Indeed, the result might even constitute a loss for Apple; the prior art that PAGs can uncover could jeopardize the patents themselves. The PAG subjects the patents to a certain amount of scrutiny—scrutiny that could be avoided through provision of a suitable license.

Apple has thus far not responded to our request for comment.

Apple’s work on WebKit and with W3C has undoubtedly helped the web community. But actions such as this show the company’s approach to standards and intellectual property is, at best, inconsistent, and and worst downright unhelpful: if open standards and Apple’s IP interests conflict, it’s the IP interests that win out. This may be good for Apple, but it’s bad for the open web.

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

Tags: , ,
File Under: CSS, Web Standards
Dec
7
2011

DocHub.io: CSS, HTML Documentation in a Clean, Searchable Site

By

The web is filled with great documentation for web developers. But sadly finding that great documentation is not always easy. Take the Mozilla Developer Network (MDN), for example. Mozilla’s developer site offers a wealth of documentation on CSS, JavaScript, HTML, SVG and more, but navigating through it can be tedious — there’s no global menu and searching is downright awful.

That led developer Rafael Garcia to create instaCSS, a faster means of browsing through the CSS documentation from MDN. Thanks to a much better search feature and a cleaner, simpler design with a nice global menu, instaCSS proved a hit with Hacker News readers. Due to popular demand Garcia has since moved the site to the broader DocHub.io domain and expanded to cover CSS, HTML, JavaScript and Dom docs.

Garcia has released his DocHub effort on GitHub, which means you can set up your own local instance for those times when you don’t have internet access (admittedly, those times are becoming rare for most of us).

While DocHub is a nice project, it’s not without its shortcomings. For example it lacks unique URLs, so you can’t link to anything within the site. It also uses hash-based URLs, which, among other crippling problems, breaks the browsers back button. [Update: DocHub.io has been updated numerous times since this piece was written and now has permalinks and a working back button in most browsers.]

Still, despite those two problems, DocHub.io is one of the better documentation sites around — definitely worth adding to your bookmarks.

Tags:
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:

« OLDER POSTS