To see the new blend modes in action, grab a copy of the latest Chrome Canary or WebKit nightly builds, enable the CSS Shaders option in about:flags and point your browser to Adobe’s sample code over on Codepen. Previously, CSS Shaders required a special build of WebKit [Update: As Adobe’s Alan Greenblatt points out in the comments, CSS shader support has been in Chrome stable since v25 (you still need to enable the flag). But if you want to play around with these new blend modes then you’ll need Canary (or a WebKit nightly).]
The first release of Firefox with support for WebRTC is right around the corner and Mozilla is encouraging web developers to go ahead and start experimenting with what Mozilla refers to as “the real future of communications.”
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 in your browser.
WebRTC support is already baked into Firefox for Android. Both the getUserMedia API and the PeerConnection API — key components of WebRTC and the cornerstones of web-based voice chat — are already supported though you’ll need to enable them in the preferences. See the Mozilla hacks blog for more details.
The same APIs are also now part of desktop Firefox in both the Nightly and Aurora channels. Expect both to make the transition from Nightly to final release as part of Firefox 22 (due some 10 weeks from now).
As Adam Roach, who works on Mozilla’s WebRTC team, writes, with these tools landing and some impressive demos from both the Firefox and Chrome WebRTC teams, “it’s tempting to view WebRTC as ‘almost done,’ and easy to imagine that we’re just sanding down the rough edges right now. As much as I’d love that to be the case, there’s still a lot of work to be done.”
That’s part of why Mozilla is asking developers to start experimenting with WebRTC — to help discover what works, what doesn’t and what needs to be better.
“As long as you’re in a position to deal with minor disruptions and changes; if you can handle things not quite working as described; if you are ready to roll up your sleeves and influence the direction WebRTC is going, then we’re ready for you,” writes Roach.
But it isn’t just experimenters that Mozilla is interested in, “for those of you looking to deploy paid services, reliable channels to manage your customer relationships, mission critical applications: we want your feedback too,” says Roach. He goes on to caution that developers should “temper your launch plans.”
Still, while it’s perhaps too early to launch a serious business built around WebRTC, you won’t have to wait long. According to Roach, WebRTC will be “a stable platform that’s well and truly open for business some time next year.”
If you’ve been using the HTML5 hgroup tag, now would be a good time to stop. The hgroup tag is in the process of being removed from the W3C’s HTML5 specification.
While the official reason for hgroup‘s demise is the lack of support for hgroup semantics — the W3C requires two “reasonably complete implementations” — hgroup is fraught with accessibility problems and lacks many compelling use cases.
The hgroup tag was intended to be a way to group h1-h6 tags, for example a header and a subheading, but the semantics behind the tag mean that only the first header in an hgroup is visible to any accessibility API. As Steve Faulkner, co-editor of the HTML5 spec, writes on the W3C mailing list, this “effectively removes any notion of a subheading semantic for users and any way for it to be conveyed via an accessibility API.”
In other words hgroup ends up being semantically no different than a div tag, which is why Faulkner called for hgroup to be removed from the spec in the first place. As of this writing it’s still there, but Faulkner says he’s “working on the edits” (which will include some advice on how to handle groups of header tags).
So what should you do if you’ve used hgroup in your code? Well, if you can, consider removing it. But the browser support — which is limited to parsing and CSS — won’t likely change. And it’s also possible that some compelling use case will come up that motivates the W3C to add it to the HTML 5.1 spec (one hopes with better semantic rules) and browser to support it. In the mean time though, slowly step away from the hgroup and no webpages get hurt.
HTML5 and CSS 3 offer web developers new semantic tags, native animation tools, server-side fonts and much more, but that’s not the end of the story. In fact, for developers slogging away in the web design trenches, one of the most promising parts of CSS 3 is still just over the horizon — true page layout tools.
Perhaps even more powerful — especially for those building responsive websites — the Flexbox order property allows you to create layouts completely independent of the HTML source order. Want the footer at the top of the page for some reason? No problem, just set your footer CSS to order: 1;. Flexbox also makes it possible to do vertical centering. Finally.
We’ve looked at Flexbox in the past, but, unfortunately the spec has undergone a serious re-write since then, which renders older code obsolete. If you’d like to get up to speed with the new syntax, the Adobe Developer Blog recently published a guide to working with Flexbox by developer Steven Bradley.
Bradley walks through the process of using Flexbox in both mobile and desktop layouts, rearranging source order and elements to get both layouts working with a fraction of the code it would take to do the same using floats and other, older layout tools. The best way to wrap your head around Flexbox is to see it in action, so be sure to follow the links to Bradley’s demo page using either Chrome, Opera or Firefox 20+.
For some it may still be too early to use Flexbox. Browser support is improving, but obviously older browsers will never support Flexbox, so bear that in mind. Opera 12 supports the new syntax, no prefix necessary. Chrome supports the new syntax, but needs the -webkit prefix. Like Opera, Firefox 20+ Firefox 22 supports the unprefixed version of the new spec. Prior to v22 (currently in the beta channel), Firefox supports the old syntax. IE 10 supports the older Flexbox syntax. Most mobile browsers support the older syntax, though that is starting to change. [Update: Mozilla developer Daniel Holbert, who is working on the Flexbox code in Firefox, wrote to let me know that the Flexbox support has been pushed back to Firefox 22. Actually the new Flexbox syntax is part of Firefox 20 and up, but until v22 arrives it’s disabled by default. You can turn it on by heading to about:config and searching for layout.css.flexbox.enabled pref. Set it to true and the modern syntax will work.]
So, as of this writing, only two web browsers really support the new Flexbox syntax, though Firefox will make that three in the next month or so.
But there is a way to work around some of the issues. First off, check out Chris Coyier’s article on mixing the old and new syntaxes to get the widest possible browser support. Coyier’s methods will get your Flexbox layouts working in pretty much everything but IE 9 and below.
If you’re working on a personal site that might be okay — IE 9 and below would just get a simplified, linear layout. Or you could serve an extra stylesheet with some floats to older versions of IE (or use targeted CSS classes if you prefer). That defeats some of the benefits of Flexbox since you’ll be writing floats and the like for IE, but when usage drops off you can just dump that code and help move your site, and the web, forward.
Conversat.io, simple video chat in your browser. Image: Screenshot/Webmonkey.
WebRTC is changing the web, making possible things which just a few short months ago would have been not just impossible, but nearly unthinkable. Whether it’s a web-based video chat that requires nothing more than visiting a URL, or sharing files with your social networks, WebRTC is quickly expanding the horizons of what web apps can do.
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.
Cool as WebRTC is, it isn’t always the easiest to work with, which is why the Mozilla Hacks blog has partnered with developers at &yet to create conversat.io, a demo that shows off a number of tools designed to simplify working with WebRTC.
Conversat.io is a working group voice chat app. All you need to do is point your WebRTC-enabled browser to the site, give your chat room a name and you can video chat with up to 6 people — no logins, no joining a new service, just video chat in your browser.
Currently only two web browsers support the WebRTC components necessary to run conversat.io, Chrome and Firefox’s Nightly Channel (and you’ll need to head to about:config in Firefox to enable the media.peerconnection.enabled preference). As such, while conversat.io is a very cool demo, WebRTC is in its infancy and working with it is sometimes frustrating — that’s where the libraries behind the demo come in.
As &yet’s Henrik Joreteg writes on the Hacks blog, “the purpose of conversat.io is two fold. First, it’s a useful communication tool…. Second, it’s a demo of the SimpleWebRTC.js library and the little signaling server that runs it, signalmaster.”
Both tools, which act as wrappers for parts of WebRTC, are designed to simplify the process of writing WebRTC apps — think jQuery for WebRTC. Both libraries are open source (MIT license) and available on GitHub for tinkering and improving.
If you’d like to learn more about SimpleWebRTC and signalmaster and see some example code, head on over to the Mozilla Hacks blog for the full details.