Image: Screenshot/Webmonkey.

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

WebP versus JPEG. Click the image to see the full size examples on Google’s WebP comparison page. Image: Google[/caption]

Want your website to load faster? Slim your images. According to the HTTPArchive, images account for roughly 60 percent of total page size. That means the single biggest thing most sites can do to slim down is to shrink their images.

We recently covered how you can cut down your website’s page load times using Google’s image-shrinking WebP format. Unfortunately, one of the downsides to WebP is that only Opera and Chrome support it. But that may be about to change — Firefox is reconsidering its decision to reject WebP.

The change of heart makes sense since most of the objections Firefox developers initially raised about WebP have since been addressed. However, Firefox hasn’t committed to WebP just yet. As Firefox developer Jeff Muizelaar writes on the re-opened bug report, “just to be clear, no decision on adopting WebP has been made. The only thing that has changed is that we’ve just received some more interest from large non-Google web properties which we never really had before.”

Whatever the case, if Firefox does land support for WebP it would help the fledgling format cross the line where more browsers support it than don’t, which tends to be the threshold for wider adoption.

If you’d like to experiment with WebP today, while still providing fallbacks for browsers that don’t support it, be sure to check out our earlier write-up.

What if your web browser were also your phone? That’s a future being imagined by Mozilla, Ericsson and AT&T.

Mozilla has combined Firefox’s WebRTC support with Ericsson’s Web Communication Gateway and AT&T’s API Platform to put together a working demo of calls — both voice and video — and text messages all made from within Firefox.

Mozilla’s “WebPhone” is one part Skype, one part Apple’s Messages and all parts web.

The demo builds on previous Mozilla efforts like the recent WebRTC video calling demo with Google, as well as the Firefox Social API demo Mozilla showed off last year (the Social API provides the glue that brings your mobile contact info into Firefox in the video above).

Aside from the cool factor, web-based calling has a potentially huge benefit for users — no more need for your phone. Mozilla’s WebPhone concept would make it possible to call from any device and the person you’re calling would still see your info.

WebPhone also makes it easy to receive calls and messages anywhere. Anyone who’s ever used Apple’s Message app knows that it’s nice to get messages on the desktop, eliminating the need to track down your phone when you’re already in front of a screen. WebPhone would make it possible to not only get messages on whichever device you’re using, but take calls as well.

Indeed what’s most surprising about Mozilla’s WebPhone demo is that AT&T and Ericsson are involved since more than anything they’re participating in a vision of the future where they are little more than pipes for sending data.

If you happen to be in Barcelona Spain for the ongoing Mobile World Congress event you can check out a live demo of WebPhone at the Mozilla booth. For now the rest of us will have to settle for the demo video above.

Tracking Webmonkey. Image: Screenshot/Webmonkey.

Developer Marko Dugonjić takes responsive design’s emphasis on you to new levels of interactivity with his experiment in typesetting by face detection.

Using a very cool JavaScript headtracking library — which taps WebRTC and getUserMedia to access your webcam — Dugonjić’s app calculates how close you are to the screen and adjusts the font size to make text more readable.

To see it in action, head on over to the demo page and grant it permission to use your webcam. For the most useful example, check out the onload-based implementation, but for a better sense of how it works be sure to try the “Realtime” version.

It may not be the most practical experiment and how well it works depends on plenty of factors well beyond the control of the site (how good your eyes are, whether or not you’re wearing your glasses and so on), but it’s not hard to imagine how this could be very useful in some situations — for example, bumping up font-size when your site is displayed on a television.

When you’re done playing with the resizing demo be sure to check out Dugonjić’s more practical and more immediately useful Typetester.

Modified WebRTC logo by Tsahi Levent-Levi/Flickr.

The demo bypasses a centralized server and instead makes a direct peer-to-peer connection between browsers. The key component of the demo is a set of work-in-progress standards known as WebRTC.

WebRTC is a proposed standard — currently being refined by the W3C — with the goal of providing a web-based set of tools that any device can use to share audio, video and data in real time. It’s still in the early stages, but WebRTC has the potential to supplant Skype, Flash and many device-native apps with web-based alternatives that work on any device.

The app that the Chrome and Firefox teams developed is available on Google Code and there’s a demo app available on Google app engine if you’d like to try it out for yourself. To make it work you’ll need to use either Firefox Nightly or Chrome 25 (currently in the beta channel). In Firefox, you’ll need to go to about:config and set media.peerconnection.enabled to “true.”

Mozilla has previously showed off a demo of WebRTC with it Social API and Chrome has previously used parts of WebRTC for an interactive sand sketching experiment. This latest demo relies on a new WebRTC trick known as RTCPeerConnection, which should arrive in final form in Chrome next month and Firefox around the end of May. The RTCPeerConnection support in both browsers means there’s no need for plugins and developers can rest assured their apps will “just work” across browsers. Together Chrome and Firefox account for just under 60 percent of browsers on the web.

There is of course one other major browser that’s not yet coming to the WebRTC party.

Indeed Microsoft has proposed a WebRTC competitor to the W3C, though thus far little has happened beyond the initial proposal. As it stands now neither WebRTC nor Microsoft’s competing CU-RTC-Web proposal are actual W3C standards, but work is progressing on WebRTC and, with browsers already implementing it in the wild, it stands a much better chance of becoming a standard one day.

It’s still a little early to throw out Skype. For now you’ll have to content yourself with a very cool demo and the tantalizing possibility to one day soon you might not need Skype, Facebook or any other third-party server to chat with friends around the web.

Image: Kevin Dooley/Flickr.

Transcoding video is the process of taking a user uploaded video and converting it to a video format that works on the web, typically MP4 and WebM. Consumer video services like YouTube and Vimeo handle this for you behind the scenes. But if you want to actually build the next Vimeo or YouTube you’re going to have transcode video.

Open source tools like ffmpeg simplify the video transcoding process, but require considerable server power to operate at scale. And server power is something Amazon has in spades.

Amazon’s foray into video is hardly the first cloud-powered video transcoding service — Zencoder is another popular service (and runs on Amazon servers) — but Amazon’s offering is marginally cheaper and well-integrated with the company’s other services.

The Amazon Elastic Transcoder works in conjunction with the company’s other cloud offerings like S3 file storage. You send a video from one S3 “bucket” to Transcoder, which then converts it to the formats you need and writes the resulting files to another S3 bucket.

For now the Elastic Transcoder will only output MP4 video containers with Apple-friendly H.264 video and AAC audio. The new Transcoder options in the Amazon Web Services control panel allow you to create various quality presets if, for example, you’re delivering video to both mobile and desktop clients.

As with all Amazon Web Services the new Transcoder has a pay-as-you-go pricing model with rates starting at $0.015 per minute for standard definition video (less than 720p) and $0.030 per minute for HD video. That means transcoding a 10 minute video (the max on YouTube) would cost you $.15 for SD output and $.30 for HD, which sounds cheap until you start looking at transcoding several hundred 10-minute videos a day (200 a day would set you back $60 a day for HD). Amazon’s free usage tier will get you 20 minutes of SD video or 10 minutes of HD video encoded for free each month.

Amazon’s rates are marginally cheaper than Zencoder, which charges $0.020/minute for SD and double that for HD. Zencoder does have a considerable edge when it comes to output format though, offering pretty much anything you’d need for the web, including live streaming, while, at least for now, Amazon’s offering is limited to MP4.

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.

Unlike progressive JPEGs, you just never know what a baseline image is going to be until it loads. Image: rickastley.co.uk

Everything old eventually becomes new again and lately that’s meant a revival of interest in something most web developers probably abandoned long ago — progressive JPEG images.

Progressive JPEGs offer some advantages over their more common “baseline” counterparts, including potentially smaller file sizes and faster perceived load times. But there are trade offs to bear in mind before you start converting your back catalog of images.

If you happened to have missed the pixelated image loads of the circa 1999 web, here’s a brief refresher: There are two primary types of JPEG images, baseline and progressive. These days the vast majority of photos you encounter are baseline JPEGs, which means they start loading with the fully rendered top of the image and then continue to draw in the rest of the image as the data is received.

Progressive JPGs on the other hand load the full photo right off the bat, but with only some of the pixel data. That means the image briefly looks pixelated and then appears to sharpen focus as the rest of the data loads. This was the generally recommended way to optimize images back in the days when 56K dial up was considered smoking fast.

Lately, with mobile devices bringing bandwidth limitations back to the web, there’s been something of a resurgence of interest in progressive JPEGs. The Web Performance Advent Calendar even ran a piece entitled “Progressive JPEGs: a new best practice.” Here’s developer Ann Robson’s take on why you should use progressive JPEGs instead of baseline:

Progressive JPEGs are better because they are faster. Appearing faster is being faster, and perceived speed is more important that actual speed. Even if we are being greedy about what we are trying to deliver, progressive JPEGs give us as much as possible as soon as possible.

If you’re building responsive websites, progressive JPEGs are also appealing because you can avoid the content reflow that happens when baseline images are loaded after text content. With progressive JPEGs, because some data is loaded right off the bat, text doesn’t jump around (you can avoid this for non-responsive images by specifying the image dimensions).

Be sure to read Robson’s full article for some important caveats regarding progressive JPEGs, including the fact that browser support is less than ideal. All browsers will render progressive JPEGs just fine, but many of them — Safari, Mobile Safari, Opera and IE 8 — render progressive images just like baseline JPEGs, meaning there is no speed difference.

Another strike against progressive JPEGs is that they must be rendered multiple times as more data arrives. So while they may be marginally faster and possibly make users feel like the page has loaded faster, they hit the CPU pretty hard. That makes them potentially slower than baseline JPEGs in one of the use cases they’re supposed to be ideal for — underpowered mobile devices.

But perhaps the most questionable aspect of progressive JPEGs is whether or not users actually perceive a fully loaded, but blurry image that eventually comes into focus as faster than an image that takes longer, but renders all at once. Unfortunately I haven’t been able to find any actual usability studies addressing that question. I suspect that how you feel about progressive JPEGs is probably, among other things, a good indicator of how long you’ve been using the web, which is to say that if you’re all-too-familiar with progressive JPEGs from watching them slowly sharpen into focus over painfully slow dialup it’s hard to see them as anything but an annoying anachronism.

So, should you switch to progressive JPEGs? As with most things in web design there is no right answer. First you should look at your site’s stats, see which browser and devices your visitors are using and whether or not those browsers even render progressive JPEGs progressively. Assuming they do and you want to test progressive JPEGs, check out this old, but still very relevant, post from Yahoo YSlow developer Stoyan Stefanov, who has some data on when, where and how to use progressive JPEGs.

Flickr’s redesigned Explore page. Image: Flickr

Hot on the heels of its awesome new iPhone app, Flickr has rolled out some changes to its web interface, revamping the navigation bar, which Flickr says makes it easier to get around the site. Flickr has also added the popular “justified” view of photos to the Explore landing page.

The Flickr blog says the changes are rolling out to everyone over the next few days, so if you don’t see them yet just be patient.

While Flickr says the new nav bar is “designed to make browsing Flickr faster and easier,” whether or not that’s true depends a little on which features you frequently use. The new navigation definitely simplifies things, but it does so by moving more than a few menu items off to obscure places. For example, options like browsing through your tags or looking at your collections have been moved out of the “You” menu to “More.” Similarly, the link to log out or get to your new mail have been moved to a new menu hidden in your user icon.

Flickr hasn’t outright deleted most menu items; they’ve just moved them to new locations. Sometimes that’s a good thing — for example, removing the “your” from all the options under a menu already named “You” makes sense — and other times it’s annoying, for example if you frequently browse by tags.

Less confusing is the new Explore page, which adopts the “justified” view that Flickr previously introduced for its Contacts, Favorites and Group Pool pages. The new layout tiles images to fit more photos at larger sizes in a smaller space and makes, well, exploring, more interesting.