Blend mode example in Chrome Canary. Image: Screenshot/Webmonkey.

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 new blend mode support is part of Adobe’s CSS Shaders proposal, which recently became part of the W3C’s CSS Filter Effects specification. There are two types of shaders in the spec, CSS fragment shaders, which provide features similar to what Photoshop’s blending modes offer, and CSS vertex shaders, which handle the 3D animation filters we’ve showcased in the past.

The blending modes currently available include all the familiar options you’ll find in Adobe Photoshop, such as multiply, screen, overlay, luminosity and other photographer favorites.

For more details and links to the corresponding specs, be sure to check out this post from Max Vujovic, who is working on the CSS Filters implementation in WebKit and Blink.

As the CSS Filter Effects specification progresses through the standardization process (and stabilizes), hopefully other browsers will add support as well.

WebRTC blasts off. Image: Tsahi Levent-Levi/Flickr.

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

Look Ma, no floats! Image: Abobe

While it’s possible to create amazingly complex layouts using tools like CSS floats, positioning rules and the odd bit of JavaScript, none of those tools were actually created explicitly for laying out content, which is why it’s amazingly complex to get them working the way you want across browsers.

Soon, however, you’ll be able to throw out your floats and embrace a better way — the CSS Flexible Box Model, better known as simply Flexbox. Flexbox enables you to create complex layouts with only a few lines of code — no more floats and “clearfix” hacks.

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.

Image: W3C

Among the highlights are Eric Meyer’s talk on Flexbox, and the future of sane layout tools — what Meyer calls “the Era of Intentional Layout.” Meyer’s talk is also notable for the reminder that, in Mosaic, styling a webpage was something users did, not page creators.

Another highly recommended talk is Lea Verou’s “Another 10 things you didn’t know about CSS.” The “Another” bit in the title refers to a talk Verou gave last year entitled “10 things you might not know about CSS 3.” Also be sure to read our recent interview with Verou for more on the W3C and web standards.

There are quite a few more videos available over on the W3Conf YouTube page, including Jacob Rossi’s talk on Pointer Events, which we linked to in yesterday’s Pointer Events coverage.

The proposed Pointer Events spec makes it easier to handle input from fingers, pens. Image: W3C.

The W3C recently moved Microsoft’s proposed Pointer Events spec to Last Call Working Draft. To help developers get up to speed, the IEBlog has published an overview of Pointer Events.

Microsoft has even helped to create a build of WebKit with experimental support for Pointer Events (for those not using Windows 8 or who’d prefer not to test in IE 10).

The goal of the Pointer Events spec is to provide a unified model for dealing with all the various input devices on today’s web, namely, the mouse, the stylus and the finger.

Pointer Events handle the various ways a user might be interacting with your site without requiring you to write unique code for each input method.

Currently most browsers register any input as a mouse event, even when it obviously is not (as is the case for most mobile browsers). It works, but it’s what you might call a blunt approach. Pointer Events adds some finesse to the equation, including details like the touch contact geometry size, the pressure applied or the tilt angle of a pen.

If you’d like to get your hands dirty with Pointer Events, either fire up IE 10 or download the experimental WebKit build and head on over to the W3C’s Web Platform docs. Microsoft’s Rob Dolin has a great overview tutorial with basic examples on how to get started. Also be sure to watch the video below from the recent W3Conf; Jacob Rossi, IE Program Manager gives a nice overview of Pointer Events and what you can do with them.

Right now only IE 10 supports Pointer Events, but Microsoft’s David Catuhe has developed a JavaScript polyfill, called HandJS, to support Pointer Events in browsers that don’t yet offer native support. Kudos to Microsoft for not just bringing pointer events to the W3C, but for working to add support to a competing browser and creating a polyfill for the rest.

We’ve written a lot about how you can make your website more accessible with WAI ARIA roles, particularly ARIA’s Landmark roles. As a bonus you can also use the roles to style elements.

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.

Image: Lea Verou

This is the first in a coming series of interviews with web developers. We’re excited to start with Lea Verou, a front-end web developer from Greece who has not only made lots of cool stuff we’ve linked to, but also recently joined the W3C to help work on web standards.

Webmonkey: You joined the W3C Developer Relations last year, which is a relatively new thing at the W3C, actively reaching out to web designers and developers. What does the day to day work of a W3C Developer Relations person look like?

Lea Verou: You’re absolutely right Scott, it’s a new initiative that Doug Schepers started last year. W3C was interested in outreach for years, but there was no official Developer Relations activity before.

My role is pretty mixed. I help organize W3Conf, our conference for web designers and developers, I help develop and promote WebPlatform.org, presenting at conferences around the world, I write articles about web standards in industry media and many other things.

WM: You were interested in web standards very early on, what was it that made standards important to you?

Verou: When I started developing for the web, IE6 was the most widely used browser. As you probably remember, making websites that work cross-browser was way harder back then than it is today. We had to rely on browser detection, ugly hacks and whatnot. I wished browsers could just agree on some common ground and implement that. A couple years later, I discovered that this is actually a thing and it’s called web standards. Since then, I made it one of my personal goals to raise awareness in fellow web developers, get browsers to implement them and advance the standards themselves for the common good.

WM: Of course many of those ugly hacks remain, especially for developers still wrestling with IE7 (IE6 seems to have been put to rest for the most part). What’s your take on supporting older browsers? Is that an important thing to do or is it time we leave them behind because they’re holding back the web?

Verou: I’m a big supporter of progressive enhancement and graceful degradation. Websites should be usable, if possible, in older browsers, but they don’t need to have all the bling. However, graceful degradation is not black & white. Everyone seems to have a different definition of what is “graceful” and what is “enhancement”.

Is a solid color an acceptable fallback for a pattern? What if your lightbox has no overlay? What if your stripes become a solid color? What if your transitions are not there? What if your code has no syntax highlighting? I tend to lean towards being more permissive instead of looking for perfection in older browsers, especially on websites targeted to a more technical audience. I will provide fall-backs, but I will not go out of my way and use proprietary IE7-specific stuff to make something look good there. With a < 0.5% global market share, it’s just not worth it.

WM: A lot of the developers I know have a kind of love-hate relationship with the W3C. But you wrote on your site that working for the W3C was “a dream of mine ever since I learned what a web standard is.” Can you talk a little bit about what makes the W3C great and why you wanted to work there?

Verou: Like I said before, promoting web standards was something I was already doing for years anyway. I felt that working for W3C itself would enable me to do it more systematically and have a bigger impact. For instance, one of my main tasks has been helping organize W3Conf — happening this February in San Francisco — which is aimed at showing web professionals that web standards are not some utopian ideal but practical to adhere to in everyday work, as well as educate them about recent developments that they can use today. Connecting those two worlds is a fun challenge!

WM: Standards do at times feel less than practical, especially because they’ve been changing a lot lately — e.g. WebSockets got a rewrite after it had already shipped in multiple browsers, ditto CSS Flexbox. So there’s these seemingly rapid changes, and then on the other hand it seems like we’ve been waiting for other things forever. I know the W3C recently launched, WebPlatform.org for developers, but what other resources would you suggest for web professionals who’d like to educate themselves about web standards, and more importantly stay up-to-date?

Verou: W3C is well aware of the fact that sometimes we can be slow and we are trying to speed things up to meet developer needs. This is why we are encouraging implementors (like browser vendors) to implement earlier on in the process so we can get feedback by developers and we’re putting more emphasis on testing, which is going to improve interoperability.

All this means that experimental features will ship which still need work. Having shipped in browsers is not an indication of stability. Browsers often ship experimental features so that developers can play with them and give feedback. This doesn’t mean the feature is frozen — quite the opposite, it means we need feedback to make it better.

Regarding resources, I know I’m weird, but I often read about new features in specs. I search for a feature, come across the spec, take a look on what else is there and then see if it’s implemented anywhere. I also often find good information on Twitter and looking at others’ code. There are also some websites with good information like:

• html5doctor.com
• css-tricks.com
• smashingmagazine.com
• netmagazine.com
• sitepoint.com
• alistapart.com

and many others.

WM: Now that you’re actually working for the W3C has your perspective on standards changed? Is there anything that looks different from the other side of the fence?

Verou: I was involved in standards before I joined W3C, so many things already looked different. For instance, many developers tend to blame W3C for being slow with standardization, whereas the reality is that often implementors are just busy with other things (we need multiple implementations for a spec to exit CR level) or spec editors are focusing their attention elsewhere.

Another common misconception is that spec editors and Working Group members are exclusively or mostly W3C staff. Whereas many W3C Team members do edit specs and participate in WGs, the majority of spec editors are employees of member companies, as evident in most specifications (you can see a list of the editors in the header). W3C is not some authority that dictates standards from up high, but merely a forum for interested parties to get together and collaborate on advancing the web.

WM: How can developers who aren’t (yet) well-known contribute to the process or give feedback about what works and what doesn’t?

Verou: Participating in web standards is a matter of joining the conversation. W3C is very open. Technical discussion happens in the public mailing lists and IRC, which you can join. Pragmatic feedback from anybody is welcome, especially from people who have tried using the feature in question. Experiment, try to make it work for you and share experiences — good or bad — about it. It might seem at first that you’re just one voice among many, but if your feedback is good, your voice is going to be heard. Technical arguments are judged on their merit and not their origin.

WM: I get tired just looking at your GitHub page — Pattern Gallery, -prefix-free, Dabblet, Prism and a bunch of other useful tools — where do you find the time to build all this cool stuff? And are you going to be able to keep doing it now that you’re at the W3C?

Verou: I actually released another tool after I joined W3C: Contrast Ratio. W3C supports me in making tools to help developers use open web technologies more effectively. In fact, improving Prism and Dabblet is one of my tasks at W3C since we are going to be using them in WebPlatform.org, our vendor-neutral documentation effort, where all the big players of the Web are working in harmony to create a valuable resource. However, I plan to slow down on releasing new things, so I can maintain the existing ones. Nobody likes to use abandoned scripts and tools, right? :)

WM: The first time I recall landing on your blog was for a post about CSS abuses, like making the Mona Lisa in pure CSS. Which is of course silly, but what caught my eye was that you wrote about how people should be using SVG, which is an awesome tool that almost no one seems to use (despite the fact that it often has better browser support than most CSS 3 features and works great on every screen resolution). Why is SVG still the neglected stepchild of the web stack and do you think that’s ever going to change?

Verou: SVG was significantly held back by a number of different factors. One was the lack of proper support in browsers for many years. Internet Explorer was promoting VML (a proprietary technology that influenced SVG) until IE8 and only implemented SVG in IE9, which is not that long ago. In addition, there are far more browser bugs in SVG implementations across browsers, since fewer people use it, so fewer of them get reported and fixed.

Last but not least, there just aren’t many extensive resources for SVG documentation, a gap that WebPlatform.org is trying to cover (and since it’s a wiki, you can help too!).
However, SVG is certainly picking up in the last few years, either directly by people using the format, or indirectly, through many of its features getting added in CSS. For example, CSS Transforms, CSS Filter Effects, Blending and Compositing, as well as CSS Masking, are all basically SVG applied to HTML with a simpler syntax.

WM: Everyone has their pet standard, personally I’d like to see CSS Flexbox get better browser support and end the float insanity — what’s at the top of your web standards wish list?

Verou: As an editor of CSS Backgrounds & Borders Level 4 I can’t wait for it to get more attention. Regarding other specs however, I’m very interested in the new SVG-inspired specs like Filter Effects, Compositing and Masking. They allow us to do things we badly needed for years and for the most part, they degrade pretty gracefully, unlike the new Layout modules or the syntax improvements.

To keep up with Verou’s latest projects and musings on web standards, check out her blog and follow her on Twitter and GitHub.