Here’s what you need to do check out the feature in your favorite browser:

Mozilla Firefox

For Firefox, canvas blend modes are enabled by default in the stable version, so there are no prerequisite steps for enabling canvas blend modes.

Chrome Canary

To see canvas blending at work in Chrome, download the latest Canary build, navigate to chrome://flags , turn the “Enable experimental WebKit features” flag and restart the browser.

Safari

For Safari, simply download one of the nightly builds from http://nightly.webkit.org.

Once you’ve completed these steps, navigate to this codepen to see canvas blending at work!

As you can see from the video above, the mobile version is more interactive and expressive than the version we created for the browser. Since the primary interaction model on mobile is touch, we believe devices provide an opportunity for more playful and engaging experiences.

Delivering these types of experiences on mobile devices today frequently means having to build native applications for every platform you want to target. However, as the web platform becomes more powerful, we are going to see an increasing number of these experiences implemented entirely with standard web technologies.

Indirect

CSS gives you many tools for defining where your content flows. But the tools available so far are indirect. You can use a float to say “don’t flow in this area.” Or you can use a margin to keep an area clear. You get one rectangular box for your content, and the tools let you cut away from the rectangle to make a more interesting shape.

Take this layout. An article flows through three areas, creating some visual interest. There are ways of achieving something like this layout now, but they are all indirect and have limitations.

You can create this with margins (ignoring the blue boxes for the moment) – right margin to begin with, then left margin, then auto on the left and right sides. The main limitation with this method is that you have to break your content up into three pieces to have something to assign those margins to. So the height of these columns is fixed. Another limitation is that you’re defining the column width by subtracting the margin from the container size. Since you define a single margin value, you’re stuck with a particular length or percentage column width.

You could also create this with floats. You define the column size by subtracting the float width from the container size, so again you’re stuck with a particular length or percentage column width. The height can be flexible, though. You’d just have to add some clearing to the second float and the column heights could be determined by the float heights. But to maintain this height flexibility, you’d have to continue using (two) floats for the last centered column with more clearance. All of these floats would need to be at or near the beginning of the content, to make sure there are no gaps between the float areas where a line of text would take up the entire width of the container. That’s a lot to maintain just to say where your content doesn’t flow.

Direct

Unlike these indirect methods, CSS Regions allows you to define the three column areas directly. This has all sorts of advantages. You get the benefit of using min-width and max-width to create a flexible but still readable column width. Since the CSS Region for each column is a fully-stylable box, you can position the column using any CSS method you’d like, instead of relying on the quirks of a single feature like floats.

I’ve put a CodePen together that creates the layout above using CSS Regions and Flexbox. You can see how it works in Chrome Canary. Because each column is its own box, I can make the first two columns flex items. This allows me to give the column a min-width and max-width width that flexes as more or less space is available. And if a lot of space is available, the space between the column and the blue box can flex as well. I’ve used two flex containers to ensure that no more than two flex items are arranged next to each other.

The best part of using Flexbox is that if the available width is too small, the wrapping flex containers create a single-column layout for mobile without any changes to the widths I’ve defined. I do have one media query in the CodePen, but all it does is change the order of the second blue box so the mobile layout runs text-box-text-box-text. Try it out with different screen widths.

Future-Proof

The reason that I can create this layout using CSS Regions and Flexbox is because I define the region boxes directly. Flexbox does not have to know anything about CSS Regions – it just operates on the boxes inside the flex container. CSS Regions can participate in any new CSS feature that works on boxes (which tends to be most of them). So as CSS improves, you gain more and more expressive power by defining where your content flows directly using CSS Regions.

The Adobe Web Platform team recently partnered with two talented contractors (Edan Kwan and David Vale) to build a mobile application that showcases one of the features the team has been implementing in WebKit and Blink. The application is modeled after a travel app – with the addition of some really cool CSS Custom Filters (aka CSS Shaders) to enhance the UI. The application provides a glimpse into the new capabilities that will be available to designers and developers interested in creating compelling UI experiences using web standards. CSS Custom Filters are defined in the CSS Filter Effects Specification.

The application was written entirely in HTML, CSS and JavaScript and packaged for Android using Adobe’s PhoneGap and a custom build of Google’s Blink rendering engine. The application also runs on desktop computers; CSS Custom Filters are currently available in Chrome behind the CSS Shaders flag, so anyone can start experimenting with them now.  See how custom filters have been used to create an enhanced user experience in this travel app.

The code for this travel application has been open sourced under the MIT license and is available right now on GitHub. We love feedback, so feel free to clone it, fork it, and experiment with it. Members of the Web Platform team are at MAX and will be at the Web Platform booth with Android devices that have the demo running. Be sure to stop by and check out just how easy it will be to add engaging effects to an application using CSS Custom Filters.

Configuration

Because some of the features the demo uses are still experimental, the article needs to be viewed in Chrome Canary with the following runtime flags enabled:

• Experimental WebKit features
• CSS Shaders

To learn more about enabling runtime flags, see this tutorial.

Once you have Chrome Canary installed and properly configured, go check out the demo. (Note that the entire project is open source and available on GitHub.) Of course, if you’re in a hurry, you can always just watch the video above to get a feel for the experience.

Editor’s Marks

Some of the advantages of modern layout capabilities can be subtle, so we created an "editor’s overlay" mode which highlights the more noteworthy features and explains how they were implemented. To enable editor’s marks, click on the bar at the bottom of the article (or just press the tilde key).

Regions

In order to have better control over the flow of the article, we used CSS regions. At its core, regions allows you to separate your content from where and how it gets displayed. Specifically, it allows you to designate which part of your DOM is your content, and which elements your content should flow through. The flow of the content happens automatically, adjusting for things like font size changes, resizing, zooming, etc.

In the "Forest Giant" demo, we use regions to make the content flow throughout the page in interesting ways, even creating shallow columns in one instance. Without regions, the designer would have had to break the content up manually, and would have to make major adjustments to the entire page if the content ever changed. With regions, the content is automatically broken up across various elements as the source text flows through the specified region chain.

Regions are also an excellent tool for responsive design. When you change the size and/or position of your regions in response to changes in screen size, your content automatically reflows through your region chain.

Learn more about CSS Regions.

Exclusions

CSS Exclusions allow text to flow along either the inside or the outside of a shape. Take a look at the drop cap at the beginning of the article. Without exclusions, the text to the right of the "O" would be vertically aligned, creating uneven spacing. By using exclusions — and specifically shape-outside — the text is able to follow the contour of the initial letter creating a much cleaner and far more polished visual effect.

Another example of exclusions is the text at the bottom of the article. Notice how the paragraph follows the shape of the map. This type of high-end layout was not formerly possible with HTML content. Without exclusions, the best way to do this on the web would probably be through the use of images, however you then lose the ability for your text to be resized, indexed, searched, copied, and easily updated.

Learn more about CSS Exclusions.

Balanced Text

The concept of balanced text is fairly subtle, but once you’re aware of it, you’ll find that it makes a huge difference in the way your content is laid out. By default, browsers wrap text one word at a time which means you can easily end up with lines containing only one or two words while the line above it might stretch the entire length of your container. Although this is something we’re pretty accustomed to seeing on the web, it’s not a layout that would ever be permitted in print. When designers have full control over how lines of text are broken up, they will balance the text such that every line is approximately the same length.

We’re using a balanced text polyfill for both the subtitle of the article, and the pull quote between the second and third paragraphs. To see how it works, try resizing your browser horizontally. If you have a wide enough monitor, you should see the entire pull quote on one line. As you decrease the width of your window, you will see that the text always wraps in such a way as to keep the lines close to the same width.

Learn more about Balanced Text.

Custom Filters

Most of us are accustomed to applying filters to images in applications like Photoshop and Instagram. And if you’ve used SVG on the web extensively, you’ve probably also experimented with SVG filters. Now you can apply the same visual effects to any HTML elements using CSS Filters.

The advantages of filters are:

• They can be applied dynamically which means you don’t have to preprocess your assets.
• You can apply them to any HTML element (not just images).
• They can be animated with CSS Animations.

We’re using a custom filter at the bottom of the article to allow users to "peel back" the bottom of the page and expose an interactive infographic (click on the "Explore the President Tree" text to see the filter in action). The effect is a subtle but fun way to create a sense of depth in the content, and is achieved entirely through CSS.

Learn more about CSS Custom Filters.

WebGL

Because the "Forest Giant" article is about the second largest tree in the world (but probably the biggest in terms of mass), we wanted to convey a sense of size. If you click on the "Click Here to Pan & Zoom" link below the thumbnail of the giant sequoia, you’ll see a huge image of the tree assembled tile-by-tile until you reach the top. Try scrolling around the image and note how small the three scientists appear in relation to the tree they are studying.

This effect is accomplished with WebGL (through a library called three.js). Although WebGL is not a specification or implementation that Adobe is contributing to directly, we’re a big fan, and it was the perfect technology for building a smooth 3D animation.

Learn more about WebGL.

Conclusion

Advances in technology have proven many times that convenience often trumps fidelity. For example, MP3s became popular — even at their initial low bitrates — because it was more important for us to have all of our music available wherever we were than it was to have the best possible audio quality. Similarly, digital books, magazines, and newspapers are replacing their analog counterparts at an increasing rate because convenient and instant access to content frequently supersedes aesthetics.

Now that the internet has helped to make content ubiquitous, we’re starting to see a shift back toward production value. Users want HD video, beautiful and fluid user interfaces, and they increasingly expect content to be presented in interesting and compelling ways. With features like regions, exclusions, balanced text, custom filers, and WebGL, content producers will no longer have to choose between reach and design. Working with National Geographic’s stunning visual content, Adobe has proven that the web of tomorrow will enable both.

While this first round of support in limited in scope, it is another step down the road towards providing a complete implementation of CSS Exclusions and Shapes.  In addition to Hans’s examples, his post also includes an interactive demos that you can play with to see the algorithm in action.

The Chromium Embedded Framework (CEF) is an open source project that allows developers to easily display HTML content in their desktop applications. The HTML view can be finely controlled and even extended through the available API. Underneath, the HTML rendering is done through the Chromium browser project, on top of the Blink engine (formerly WebKit) and the V8 JavaScript virtual machine.

As frameworks usually go, CEF provides mainly a set of headers and a library. It is available on Windows, Mac OSX and Linux, though there is still work to do to have feature parity between platforms. C++ and C APIs are available as a part of the project, but there are projects out there which maintain wrappers for other environments like .NET, Java and Python.

Relationship with Chromium

CEF comes in two versions – CEF1 and CEF3, both of which are actively maintained. These two projects expose almost the same API to embedding clients, whie rendering HTML using the Chromium flavor of WebKit (now Blink). Where they differ is in how they hook into the HTML engine underneath, but to better understand that, it is useful to have a general overview of the Chromium architecture.

The Chromium architecture has three main layers: Blink (formerly WebKit) API, Content API and Chrome. The Blink API provides access to the rendering and V8 JavaScript engine which together run in a single process. The Content API adds the multi-process architecture and provides implementations for more complex HTML5 and browser features like accelerated compositing, Geolocation and WebRTC. The Chrome layer includes the Chrome browser user interface and feature implementations like history management, extensions and bookmarks that are tightly coupled to the Chrome browser. The Chromium team is currently working to introduce a fourth concept, called Components, which will provide modular implementations for browser features that span multiple layers.

The Blink and Content APIs are not stable and many features have additional implementation requirements. CEF provides these implementations along with a stable API that hides most of the underlying Chromium and Blink complexity. CEF1 uses the Blink API directly and as a result shares the single-process architecture. CEF3 uses the Content API and benefits from the multi-process architecture and many of the advanced features that are implemented in the Content API. As an added benefit for CEF3 the Components changes will make it easier to selectively enable and share feature implementations that at this time cannot be shared due to tight coupling with the Chrome layer.

CEF3 implements some of the interfaces and delegates that the Content API provides, much in the same way that Chrome does. While a developer can embed Chromium starting directly from the Content API, this would involve a rather significant amount of work, which is already done in CEF3. This includes implementing the Content API interfaces and delegates that the application wants to manipulate, and while doing so, also writing the platform code for the platforms the application needs to run on (Windows/Mac/Linux). Using CEF, on the other hand, is as simple as writing a few lines of code before firing up a modern, up-to-date HTML5 view right inside the application.

Both CEF1 and CEF3 include parts Chromium into the resulting library, and as such, have a build dependency on the Chromium code. The project maintains compatibility with a specific revision of the Chromium code underneath, which is updated pretty regularly. From that point of view, embedders don’t have to worry that updating Chromium will break their application.

From here on, the term CEF will refer to CEF3, unless specified otherwise.

Getting Started

Probably the simplest way to start using CEF is to download one of the binary releases. CEF maintains branches that are compatible with the Chromium stabilisation branches used for releases. The periodic binary releases are usually built from one such stable branch.

The distributable package contains the headers, the library, some required resources, and also a test application called cefclient. This is where you should be looking. It is the perfect showcase of how to use CEF, from starting up the framework to implementing the HTML content callbacks exposed through the API. You can test things out by hacking at the application code, quickly rebuilding, and so on.

Note that you can also pass Chromium command line switches to cefclient, and they will have the same effect they would have in the browser (if they apply).

If you want to contribute, or use a feature that is not currently in one of the binary releases, you will have to build the CEF library from source. Although CEF is itself pretty lightweight, this also involves building Chromium, which makes the job a bit more complicated. I will not go into details in this post, but if you’re looking for a place to start, have a look at the CEF automate folder. The python script inside checks out both the CEF and Chromium source code and proceeds to build the final CEF package. The README file in the same folder describes the process in more detail, and also contains some required steps to be performed before running the script.

Adobe Contributions

Our more considerable contributions to CEF, aside from various bug fixes are listed below.

IME on Mac [CEF1]

The first considerable contribution we made to CEF was implementing the missing platform code for the Mac OS X Input Method Editor (IME). In CEF1, this code was upright missing. In CEF3, it is already available underneath the Content API umbrella.

Tracing API [CEF3]

The tracing mechanism is a Chromium development tool which can be used to profile the Chromium code across threads and processes. Just type chrome://tracing in the Chrome URL bar if you’re wondering what this is, and start tracing. Our contribution was to expose the internal tracing API as a part of the CEF API. Embedders can use these methods to profile calls inside their own client application in the same view as the whole CEF – Chromium – Blink stack.

Offscreen Rendering on Windows and Mac [CEF3]

This feature allows embedders to receive paint notifications from CEF instead of having CEF render directly to a native window. The embedder can then handle the rendering themselves using technologies like OpenGL or Direct3D. As a part of this feature, UI events can also be forwarded to the HTML page. It is particularly useful when an embedder wants to draw something else on top of the HTML view or integrate with an existing application framework that performs its own rendering. Using offscreen rendering provides a simple solution for synchronized drawing between two overlapping views, even two HTML views. This would be a real hassle when dealing with two overlapped, transparent native views.

Another use case is to break the boundary between 64 and 32 bit processes. Since Chromium does not support 64 bit builds at the moment, CEF binaries will also be 32 bit bound. Hence, a 64 bit application will not be able to link directly with CEF. The HTML rendering could, however, be isolated in a 32 bit process without any UI, thanks to offscreen rendering. The rendered HTML results could then be passed through a bridge back to the 64 bit application, and drawn inside UI objects belonging to it.

Next Steps

We plan on contributing the IME functionality for offscreen rendering on Mac. Since implementing offscreen rendering overrides some of the internal Content API implementations, IME needs to be fitted to work without the native window it was bound to.

We are also working on setting up an automated build infrastructure for CEF. This will build CEF regularly, run the unit tests, and post the builds at a public location. We are still ironing out the details on this project (nightly builds vs change by change builds, branches vs trunk etc.).

To Sum Up

If you need a simple, cross-platform way to display HTML content in your desktop application, CEF may be exactly what you’re looking for. It is open and has a healthy community behind it, as also shown by all the applications that are using it.

We will be joining a whole entourage of other teams  from Adobe to be at Adobe Max 2013 in LA! We are going to be presenting not just sessions but also workshops and labs exclusive to MAX participants. Here are what we are going to be talking about:

Sunday 5th May 2013

Lab: Deep Dive into Web Standards and Technologies, Sunday 9.00am – 403B (Session Details)
Razvan Caliman will conduct an exhaustive hands-on session for those who are yet to get dazzled by the newer features offered on the web through HTML, CSS, SVG and JavaScript.

Monday 6th May 2013

Lab: Layout on the Web: What’s New, Monday 2.45pm – 409B (Session Details)
In this lab session you will get to experience a hands-on tutorial that examines the latest features for laying out content on the web and how they can simplify design patterns in use today from Bear Travis.

HTML5 for ActionScript 3.0 developers, Monday 5.00pm – 510
Thibault Imbert, our Group Product Manager will take a deep dive into JavaScript & HTML5 and explain what is different from ActionScript 3.0.

Tuesday 7th May 2013

Advanced Layout with CSS, Tuesday 8.30am – 513 (Session Details)
Alan Stearns who edits the Regions specification, will speak on various layout features that are available now and those that will be available in the future including Flexbox, Grid Systems, Regions & Exclusions

Philosophy Behind Responsive Web Design, Tuesday 8.30am – 511B
Kristofer Joseph was one of the developers of Reflow, and he will walk you through some of the common pitfalls & misconceptions around responsive web design and how to achieve your design intent with simple workflows.

SVG Reboot, Tuesday 1pm – 514 (Session Details)
Dirk Schulze who is a co-editor of the SVG 2 specification, will speak with Alan Greenblatt on what SVG is, and demonstrate some features of SVG that are useful while also demonstrating some advanced features of SVG 2 that are making their way into browsers.

Creating Web Experiences with Users in Mind, Tuesday 4pm – 501A (Session Details)
Alex Chiculita and I will take you through some context for why you should care about user experience and some of the technical details of what makes a web experience awesome.

Combining Web Graphics: SVG, HTML, CSS, 2D and 3D Canvas, Tuesday 4pm – 514
Dmitry Baranovskiy will talk about Canvas, SVG and how to combine multiple graphical features to create a compeling effect.

Wednesday 8th May 2013

Go Beyond the Canvas Box to Create Your Own Cinematic Effects, Wednesday 11am – 511C (Session Details)
Alan Greenblatt will speak on how to use custom filters to create compelling web experiences and the state of browser support.

Getting Shellacked with TopCoat, Wednesday 1.30pm – 511A
Kristofer is now working on TopCoat – a UI Framework that is minimally invasive, and will talk on how to use TopCoat to build your next native desktop or mobile applications with examples of applications that use this library while also talking about how you can be a contributor to this Open Source project.

Lab: Creating Special Effects for your Web Content with CSS Filters and Shaders, Wednesday 1.30pm – 402AB (Session Details)
In this lab session you will learn about using a GLSL shader to apply interesting UI effects to create interesting web experiences from Alan Greenblatt.

The Quest for the Graphical Web, Wednesday 3.30pm – 506 (Session Details)
Ethan Malasky, our Engineering Manager is going to walk us through the history of graphics on the web and how we are at the threshold of a new era of web graphics.

Exploring Digital Reading Experiences, Wednesday 5pm – 503
CJ is going to be speaking about creating digital reading experiences and his experiences working on creating such applications using powerful new technologies.

Wait there is more!

A lot of our team members (in addition to those listed) will be around to talk to you in the Community Pavilion, and at the Adobe Booth and will be on hand to show you two brand new demos that we will be sneaking in. We will also have loads of webplatform.org & testthewebforward.org stickers to give away! Look us up at either of these places if you would like to chat about what we are doing for the web, the hows and the whys.

See you at MAX!

Following the usual format, the event kicked off on Friday evening with a series of tech talks. Elika “fantasai” Etemad began as the keynote speaker, giving an inspiring and thought-provoking talk on how to approach writing W3C spec tests. She gave advice on how to extract testable assertions, how to design robust tests, and things to consider when reviewing tests.

Then Microsoft’s Kris Krueger and I each gave short talks on how to write W3C tests. I covered reftests, which are used when a test case requires a browser’s rendering to be verified and Kris covered testharness.js, which is the W3C’s JavaScript test framework. The attendees were very engaged and interested in all of the talks, evident from the good questions that followed.

After the presentations, there was a series of lightning talks, where several experts introduced themselves and tried to recruit new test writers for their favorite specs. After the pitches were made, people formed groups to write tests for HTML5, Pointer Events, CSS Flexbox, and CSS Transforms. The evening wrapped with a great spread of food and plenty of cold beverages. Everyone was ready with a plan to hack the next day.

On Saturday, groups formed in three rooms – Kris led a team in the HTML5 room, Arron Eicholz from Microsoft joined Elika and me in the CSS room, and Jacob Rossi (also with Microsoft) paired with the president of the jQuery Foundation, Dave Methvin to lead a group writing tests for Pointer Events. This was a great example of the community having a voice in how each TestTWF is is run. Dave reached out to the organizers suggesting a focus on the Pointer Events spec, so he was invited as an expert and along with Jacob, turned out lots of new tests!

Over in the HTML5 room, Kris’ team was also writing lots of tests and finding bugs. Greg Bulmash quickly exposed some interoperability issues with the HTMLOptionsCollection tests he wrote.  It was also very cool to see some remote people participating in this event. Opera’s Odin Hørthe Omdal (and expert alumni from TestTWF Paris) was online in Norway reviewing tests.  Ms2ger was also reviewing tests and even quickly fixed a bug in testharness.js found by Alan Stearns during the event. This was the first truly global TestTWF.

In the third room were the CSS folks. Those writing tests for CSS Flexbox were in good hands with Arron and Elika.  They put the spec on a large projector and walked through the sections to help people identify test cases.  Elika then went into further detail on the points she had discussed in her talk the night before, reiterating the three main points every test author should consider:

1. Does the test pass when it’s supposed to pass?
2. Does it fail when it’s supposed to fail?
3. Does it test what it thinks it’s testing?

The rest of the CSS people wrote tests for CSS Transforms. It was great to see people learning and collaborating on the best test design for this very cool CSS feature.

Designing a CSS Transforms test

All in all, it was another great event, producing over 500 new tests!. People left knowing more than they did when they came, we grew the community, and we moved the Web forward just a little bit more.

Next stop: Tokyo!