Web Platform Team Blog

Making the web awesome

Making the Web Sweeter with Food Network and Cupcakes

There are two things we know for sure that almost everyone loves: mobile applications and cupcakes. Food Network brought the two together in a beautiful tablet application called, appropriately enough, Cupcakes! (check it out on Apple’s App Store). Cupcakes! is kind of a cupcake encyclopedia, full of recipes, ideas, tips, and of course, inspirational cupcake photography.

When we saw the Cupcakes! app, we wanted to see if we could use some of the newer web platform features to bring the same type of experience to the open web. Food Network is always looking for more ways to engage their audience, so they agreed, and we teamed up.

Canvas Blend Modes

The first thing you see when you open the Cupcakes! demo is a giant cupcake. Watch carefully and you’ll see that the frosting changes colors using the power of canvas blend modes. Blend modes allow us to define how layer colors interact with each other. It works the same way layer blend modes work in Photoshop, creating more complex color combinations than opacity provides. In this case we’re using the blend mode color-burn by setting the globalCompositeOperation property like this:

context.globalCompositeOperation = 'color-burn';


You might have also noticed that the color conforms to the shape of the frosting. That’s because we’re masking the color with another image that represents the shape of the frosting. We’re able to achieve this effect with compositing, which allows us to define the visibility of one layer based on another. This is also achieved with the globalCompositeOperation property, but with the value destination-atop, which tells it to mask, or “cut out,” the bottom layer based on the top layer’s alpha channel.

context.globalCompositeOperation = 'destination-atop';


There are a variety of values that can be used with globalCompositeOperation. These can be applied in very creative ways to make a huge number of interesting visual effects.

Learn more about blend modes and compositing.

CSS Masks

We’ve seen how we can mask content in Canvas, but sometimes it is useful to mask semantic markup like images or other HTML content. This can be achieved with CSS Masks. CSS Masks are alpha masks: images whose alpha values are transferred to the underlying content. The syntax is identical to that used with the background-image property, which means we can size, position, repeat, and even apply multiple masks to the same element. We use masks throughout the demo to add a subtle texture to content like the navigation buttons.


Learn more about CSS Masking.

CSS Clip Paths

If you’re familiar with Photoshop, you probably know there are two kinds of masks: layer masks (which in Photoshop is a luma, or black & white, mask), and vector masks (composed of a vector shape that cuts out your layer). While CSS Masks are more akin to layer masks, CSS Clip Paths are the web’s version of vector masks.

We can use Clip Paths to mask parts of our content with CSS or SVG shapes. This allows us to reuse a frame for content throughout the site simply by applying a class without the need for images. It also gives us the ability to shape user-submitted photos without having to perform server side image manipulation. Clip Paths support CSS Transitions and Animations as well so we can animate the path of the mask from one shape to another (assuming the vertices of the vector shape match up). This technique is used throughout the site on the starburst buttons as well as the timer and menu.

Learn more about CSS Clip Paths.


Dynamic Masks

CSS Masks and Clip Paths are extremely powerful, as are the different ways we can animate them. But sometimes it’s useful to be able to draw masks dynamically with code. The easiest way to do this would be to draw and animate a canvas and use that as a mask. There is a way to do this in WebKit browsers (or formerly WebKit browsers like Chrome), though it is currently not standardized. Using the getCSSCanvasContext method, we can get a Canvas context that can be referenced from CSS. As parameters, the method takes:

  1. The context type.
  2. An identifier to be referenced from your CSS.
  3. The width and height of the canvas.

document.getCSSCanvasContext(‘2d’, ‘myCanvasId’, 100, 100);

You can then use it just like any CSS image and apply it as a mask:
-webkit-mask: -webkit-canvas(myCanvasId);

We are using this technique to create masked transitions between sections of the site.



If you’ve tried cooking from a recipe on your computer, you probably know it can be difficult to read the small type. It can also be easy to lose your spot when going back and forth from cooking to the screen. To solve this problem, we created a full-screen view you can access from the recipe page. We use regions to dynamically generate large slides that make it easy to both navigate the content, and to read it from a distance.

For obvious reasons, we didn’t want individual paragraphs (typically separate steps in the recipe) to get broken up across multiple slides. To achieve this, we’re defining how the paragraphs break within regions through CSS. By setting the break-after property to “always” on our paragraphs, it will always break our content into a new region after a paragraph tag.

-webkit-region-break-after: always;

Because the content can be variable length, and because we generate the slides dynamically from the content, we need to determine how many slides are required to display the entire recipe. We can do this by getting access to our flow from JavaScript, and generating regions until our overset property is false:

var myFlow = document.webkitGetNamedFlows().namedItem('recipeFlow');

if (myFlow.overset == true;) {
	//add another region
} else {
	//no more regions needed


CSS Shapes

Cupcakes! makes subtle but important use of CSS Shapes (for a more conspicuous demonstration of CSS Shapes, see Using CSS Shapes to Enhance Visual Storytelling). CSS Shapes allow us to have text wrap either inside or around both standard shapes and custom polygons. It can make the layout of text look more polished and better integrated with its surrounding content as in this paragraph that flows around Alton Brown’s headshot:

Screen Shot 2014-01-09 at 3.01.30 PM

We also use CSS Shapes to make sure captions don’t overlap with background images as in this example:

Screen Shot 2014-01-09 at 3.01.38 PM

Learn more about CSS Shapes.

Web Speech API

Another common annoyance when combining cooking with technology is having to touch your laptop or tablet when you’re hands are messy. In order to allow you to navigate the application without touching it, we incorporated the Web Speech API. The Web Speech API allows us to receive voice commands from the user’s microphone as text. In order to make the interaction more user-friendly, we map several appropriate phrases to individual pages, which means any number of voice commands will work as the user expects. There are also some built-in commands, like “forward,” “back,” and “recipe,” that allow you to perform various functions on the site. This means you can browse through the entire application without ever touching your mouse or your screen.

Leap Motion

As we continue to demand more from our technology, it makes sense for us to create new ways of interacting with it. Multi-touch and voice input have dramatically changed the way we use our devices, and now thanks to technologies like the Leap Motion Controller, we can also use the space above and around our computers to interact with them, as well. As we were looking for ways to allow users to flip through recipes without getting ingredients all over their laptops, the Leap Motion Controller seemed like a perfect fit.

 Fortunately, Leap Motion provides an excellent javascript API that makes integrating motion control into your website extremely straightforward. If you have a Leap Motion Controller connected to your computer, you can navigate through recipe cards simply by swiping forward and back. (See the video above for a demo.)


Most of the cutting edge features we used for the Cupcakes! demo are so new that they haven’t been tooled yet, but there is one notable exception. We wanted the site to look great at any size screen — particularly on tablets — so we’re utilizing media queries to make adjustments at various breakpoints. Designing multiple layouts for all necessary breakpoints can be difficult and tedious, but Edge Reflow simplifies the process by letting us lay out our pages and add breakpoints visually. Reflow allowed us to quickly conceptualize and communicate how elements should adapt and respond to all our target screen sizes.


We had a fantastic time both working with Food Network, and bringing their vision of Cupcakes! to the open web. Collaborating with partners and experimenting with real-world use cases and content helps us to refine our contributions to web standards, and helps guide the development of tools to help more people bring these types of experiences to life.

If you want to experience the Cupcakes! demo for yourself, you can check it out here (Chrome and Safari only, for now). Additionally, the entire codebase is open source and available on GitHub. If you have questions or comments, feel free to leave them below.

Fragmentation of masked and clipped content – Part 2

The first part of the article “Fragmentation of masked and clipped content – Part 1” described possible scenarios how a clipping path can be broken into different fragments. The demonstrations used the CSS Multi-column layout with equally sized columns.

Fragmentation of clipping path for CSS Multi-column. The clipping path is sized as if the content was not broken into different pieces. For each fragment, the clipping path position is determined relative to the position of the current fragment in the virtually unbroken content.

Other CSS layouts like CSS Regions or CSS Overflow allow more flexibility on styling of fragment containers. A fragment container is a box that contains a fragment of the element. In a multicolumn element, each column is a fragment container.

The following example has three fragment containers. Each container has a different size and position. The content “Lorem ipsum” flows from the first container into the other two containers.

Three fragment container of different size. The content flows into each container.

Like in the first part of this article, the second part also looks at clipping path examples to help to decide how they should be influenced by fragmentation. Masking would follow the choices we make for clipping. The clipping path is the same ellipse as before with a 50% vertical and horizontal radius.

As a fragment container gets wider, less height is needed to contain the text. Since the elliptical clipping path has a vertical height of 50% the absolute clipping path height shrinks. This can have an influence on the relative offset for each fragment. The following considerations explore different sizing ideas.

The width of the paragraph changes. As wider the paragraph gets, as more shrinks the height.

The variable width of  fragment containers also extends the possibilities how to fragment a clipping path. For this reason, all examples in the second part use the first consideration of the first part of the article. It will not explore the different relative positions of the clipping path on each fragment. See the graphic in the introduction.

First Consideration

Each fragment has a different width. It is not possible to simply assume that the content was not broken anymore. More calculations need to be taken into account. Each fragment could be handled as if it contained the entire element..

The clipping path is sized for each fragment as if the content was unbroken for this fragment.

A reference size gets calculated for each fragment and it is assumed that the content is unbroken for each fragment. That means that the layout for the same content is calculated for each deviating width. This is because for each deviating width the content height differs. The resulting rectangles for the example above are (width x height):

  1. 124 x 512
  2. 182 x 338
  3. 95 x 703

The size of the clipping path for the first fragment is determined by the 124 x 512, for the second fragment by the 182 x 338 and the last fragment by the 95 x 703. The offset of each clipping path would be relative to the offset of the content of the current fragment and is also relative to the size of the current fragment. All these calculations eventually results in the graphic above.

Even if it seems that the cost are high, all the calculations need to be done anyway for proper positioning of the content.

Second Consideration

The model can still be simplified. Instead of creating an individual clipping path for each fragment if would be possible to use one reference rectangle to calculate the clipping path for all fragments.

The clipping path is sized according to the widest fragment in the fragment flow. This clipping path is then used for each fragment.

The behavior in the graphic above is currently used by WebKit. The dimension is calculated by the reference rectangle of a fragment as well – assuming that the content fills the fragment and is not broken. Instead of doing this for each fragment, the widest fragment is chosen to calculate the rectangle for all fragments.

It could be that the idea derives from CSS floats. Imagine a paragraph that is not broken into pieces. A floating element pushes the content by side. The paragraph would still not be broken into pieces. The reference rectangle would use the widest dimension of the paragraph.

Text with floating element. The reference rectangle is determined by the paragraph as a whole.

Of course there are different other possible variations that use a fixed reference rectangle for all fragments. Some examples are listed below:

Third Consideration

So far all of the examples have used an elliptical clipping path that had a relative dimension. Lets consider a circular clipping path with a radius of 62px:

clip-path: circle(62px at 62px 62px);

The following graphic fills the circular clipping path with black to demonstrate the problem:

An absolute clipping path gets repeated into the second fragment because of the smaller reference rectangle of the second fragment.

The height of the second fragment is smaller than the height of the first fragment. Even if the clipping path already covered the first fragment, it will still show up on the second fragment as well giving undesirable results.

The solution for this problem could be to sum up all absolute heights of all fragments. This sum will be the height of the reference rect.

The heights of all fragments are summed up to determine the height of the reference rectangle. The height is calculated to 370px.

The width of the reference rectangle could be with as in the first conclusion or as in the second conclusion.

A circular, absolute clipping path broken at the proper place.


Fragmentation gets a lot more multifaceted if the fragments do not share the same width. Finding the right solution may depend on different factors. There might not be the right solution for all of these use cases.  If you have your own solutions that should be considered as well, mail them to the www-style mailing list. Use “[css-break][css-masking]” to prefix the subject line.

Fragmentation of masked and clipped content – Part 1

Clipping and masking are graphical effects for partly or fully hiding portions of an object. A clipping path defines an area where the content will be visible. Content outside the area is invisible. An image can be used as a “mask” and the luminance of the image will determine how much of your content will be visible on the screen. Photoshop and Illustrator users are probably already familiar with clipping masks and layer masks/opacity masks. Our team is working on enabling these features in browsers with the help of CSS. The article “CSS Masking” explains CSS Masking and clipping in more detail.

The clipping path in the middle clips the image on the left side. The result can be seen on the right.

Fragmentation of content

Clipping and masking can be applied to SVG elements and HTML elements. An HTML element also has the property that it can be “broken“ into different pieces. This principle is called “fragmentation” and allows web authors to use layouts like CSS Multi-column or CSS Regions. Content that does not fit into one column or the current region is broken into different fragments and continues on the next column or region.

This article looks at clipping path examples to help decide how they should be influenced by fragmentation. Masking would follow the choices we make for clipping. To simplify the examples, the article just analyzes CSS Multi-column layout with equally sized columns. Other layout proposals like CSS Regions can create fragments of different widths and will be considered in a follow-up article.

How does a clipping path apply to content that is split into different fragments? This question is currently discussed within the CSS WG. This article demonstrates different possible solutions taking CSS Multi-column as example. In the illustration below, the clipped content is a black colored text. The text flows from the first column into the second and third column. Each column has an equal width.

An example of CSS Multi-column in use. The content flows into three columns.

An ellipse, centered on the content area, with a horizontal and vertical radius of 50% is taken as clipping path.

The elliptical clipping path.

The markup for the example could look like this:

  <h2>Lorem ipsum</h2>
  <p>Lorem ipsum dolar...</p>
<div id="content">
  <h2>Lorem ipsum</h2>
  <p>Lorem ipsum dolar...</p>
  <h2>Lorem ipsum</h2>
  <p>Lorem ipsum dolar...</p>

body {
  column-count: 3; 

With the clipping path applied:
#content {
  clip-path: url("#clip");

<clip-path id="clip" clipPathUnits="objectBoundingBox">
  <ellipse cx=".5" cy=".5" rx=".5" ry=".5"/>

or simply:
#content {
  clip-path: ellipse();

The following graphics shows the clipping path applied to an element that is not fragmented:

The element on the left is not fragmented. The element on the right is the same element with a clipping path applied.

“Copy” the clipping path

A simple solution would be to “copy” the clipping path into each fragment. The clipping path would be sized and position for each fragment of the element individually, just as if each fragment is a separate element.

The elliptical clipping path is “copied” into each fragment of the element. Each fragment is responsible for positioning and sizing the clipping path individually.

Even though this seems to be a simple solution, it might not be the most desirable one. Breaking the clipping path into different fragments might be as desirable as breaking the content into different fragments.

Clipping and masking share the problem of fragmentation with the “background-image” and “border” properties. Therefore, parts of the discussion here may apply to these properties as well.

Note: The “copy” behavior may still be useful. It was suggested to let the “box-decoration-break” affect clipping and masking as well. Authors could switch between “copy” or one of the following considerations.

First consideration

In the first consideration, the browser assumes for each fragment that the content was not broken into different pieces.  The clipping path is sized according to the dimension of the “unbroken” content and positioned relative to the fragment position.

The clipping path is sized as if the content was not broken into different pieces. For each fragment, the clipping path position is determined relative to the position of the current fragment in the virtually unbroken content.

The clipping path in the first fragment is positioned at the top, in the second at the middle and in the third at the bottom.

Second consideration

The second consideration is a variation of the previous one. The clipping path is still sized as if the content was unbroken. But the position is relative to the top left of the reference box of each fragment.

The clipping path is sized as if the content was not broken. Each fragment positions the clipping path on its top left relative to the reference box.

Sizing relative to the “bounding client rect”

Another interesting solution is to compute the smallest rectangle (the “bounding client rect” named after the function getBoundingClientRect()) that includes all border boxes of each fragment and their descendants. The clipping path would be sized and positioned according to this rectangle. All fragments are clipped together as one piece by the same clipping path.

The clipping path is sized and positioned relative to the bounding client rect. The fragmented element is clipped as a “whole”.

The described behavior does not really count as fragmentation but is used by Firefox at the time of writing this article.


Fragmentation is an important part of the CSS layout and is documented in its own specification. The article presented different possible rendering models for clipping on fragmented content. There are more variations that can be considered.

The examples above all used the CSS Multi-column layout. CSS Multi-column has the benefit that the width of each fragment is of equal size. Other layout proposals like CSS Regions allow fragments of different widths.

Example of CSS Regions. The content flows between three regions.

How would fragments with different widths influence the sizing of clipping paths? This problem will be looked at in a follow-up article.

The CSS WG will need to decide which rendering model will be used in the future. Participate in the discussion! Sign up for the www-style mailing list and send your feedback.

Web Platform team passes 1,000 commits to WebKit

Earlier this month, the Web Platform team at Adobe reached a significant milestone: 1,000 commits to the WebKit open source project.  This only accounts for commits made by members of the team while they were employed by Adobe, and the majority of this work took place over the last 2 years.  We now have 11 WebKit committers, 3 WebKit reviewers, and many more contributors on the team. It has been a great pleasure to work with the WebKit community to bring new and engaging features to the web.  We are excited about the future of WebKit and look forward to continued participation in the project.

To learn more about what features the team has been working on in WebKit, please visit our team site at

Introducing the New Adobe Web Platform Showcase

Before Adobe’s Web Platform team begins work on a new web standard — whether it’s contributing to a specification or actually implementing a feature — we take some time to really understand the specific problems we’re trying to solve. Additionally, after a feature has been prototyped, we spend more time validating that it works the way developers and designers expect and want it to. The primary way we do both these things is by:

  1. Building cutting-edge experiences that intentionally push the edges of the web.
  2. Work with some of the best digital agencies and media partners in the business to make sure we’re solving real-world problems in powerful and intuitive ways.

The new Adobe Web Platform Showcase lists some of these experiments. You can learn more about which features and concepts each project focuses on by watching the embedded videos, or — if you don’t mind enabling cutting-edge graphical and layout features in your browser — you can even check them out for yourself. Feel free to use the video or blog post comments to let us know what you think.

CSS Shapes in Last Call

The CSS Working Group published a Last Call Working Draft of CSS Shapes Module Level 1 yesterday. This specification describes how to assign an arbitrary shape such as a circle or polygon to a float and to have inline content wrap around the shape’s contour, rather than the boring old float rectangle.

A Last Call draft is the signal that the working group thinks the specification is nearly done and ready for wider review. If the review (which has a deadline of January 7th, 2014) goes well, then the spec goes on to the next step. At that point, the W3C invites implementations in order to further validate the specification. We at Adobe have been implementing CSS Shapes in WebKit and Blink for a while, but this milestone opens the door for more browsers to take up the feature.

This means that 2014 will be the year you’ll see CSS Shapes show up in cutting-edge browsers. The effort then moves to making sure these implementations all match, and that we have a good set of tests available to show interoperability. My hope is that by the end of next year, you’ll be able to use shapes on floats in many browsers (with a fallback to the normal rectangle when needed).

We <3 Blue Beanies!

By Arno Gourdol

Today we celebrate web standards by donning a blue beanie. The tradition started a decade ago, inspired by the cover of Jeffrey Zeldman’s Designing with Web Standards.  While the technologies at the core of the web platform – HTML, CSS, SVG and  Javascript – evolve and keep improving, embracing web standards remain more important than ever.  We believe that an open web built on standards can empower creators everywhere to share their most important stories with the world. This is something we are passionate about, and that that is deeply embedded in our DNA.

Looking back, this has been a great year for web standards and we’re proud of our contributions. We saw several features that we championed finally reach a broad audience. CSS Shapes is making progress and we’ve built a great demo of the more engaging storytelling you can use it for. Blend modes are broadly supported in canvas, for stunning graphical effects (check out the demo). CSS Regions is now available in Apple’s iOS 7 and Mac OS X Mavericks, and we expect to see more beautiful page layouts on the web because of it. We’ve also added support for CSS Regions authoring in Edge Reflow and Edge Code. We like to support shiny web features in our tools!

Speaking of tools, we’re also making improvements in the SVG output from Adobe Illustrator, the CSS and web assets extracted from Photoshop with Photoshop Generator and we have added a brand new CSS Designer panel in Dreamweaver to give your more control than ever to create beautiful, standard-based, web content.

We’re contributing to many open source projects, such as WebKit, Blink and Gecko. This year we introduced two new open source projects, TopCoat  a CSS library for fast, beautiful web apps and Snap.SVG, the Javascript SVG library for modern web graphics. And of course, our more established projects are doing well, with Brackets the code editor for the web, regularly trending amongst Javascript projects on GitHub, and PhoneGap, the framework for mobile apps built with the web platform, winners of the InfoWorld BOSSie awards.

We invite you to participate in those projects or in others that support web standards. By developing in the open with the involvement of many of you, we collectively strengthen the foundation on which web standards can flourish.

Web standards wouldn’t be what they are if it wasn’t for a passionate community behind them. We’ve been thrilled to see the success of some of the efforts we helped initiate, including, the community-built website to document the standards of the web. The movement behind Test The Web Forward also gained momentum, with events in Sydney, Seattle, Tokyo, Shanghai and Shenzen. And to help establish a community of ongoing contributors we’ve been happy to pass the torch to the W3C.

So join us in celebrating web standards. Don a blue beanie (real or virtual!) and share your photo (hashtag #bbd13). Happy Blue Beanie Day!

Test the Web Forward Shenzhen Recap

On November 9, 2013, the eighth major Test the Web Forward event was held in Shenzhen, China. The primary goals of this event was to raise awareness of the crucial need for tests, to educate newcomers on the test creation and submission processes, and to cultivate a community of Open Web Platform contributors beyond the day of the event.

With the recent announcement of the W3C adopting the Test the Web Forward brand, for the first time this event was part of the W3C’s annual TPAC conference at the Shenzhen Wuzhou Guest House. With TPAC attendees traveling from all over the world, this TestTWF event drew over 40 experts and spec editors covering many W3C specs and areas, including HTML5, CSS, WebDriver, and Web Accessibility. It was an event that brought together a large group of enthusiastic web developers and an extraordinary number of people with deep knowledge of the Web.

Another first for Test the Web Forward was that this was a single day event. In the past, the education and hacking were split across two days but this event reduced the hacking time and focused more on the goals of education and raising awareness.

Early Saturday morning, over 250 attendees filled Huaxia Hall for a day full of learning, socializing, and hacking.



Just as the event was full of an unprecedented number of experts, the lineup of speakers was equally impressive.

The Keynote
We were honored to have Angel Li, Site Manager of W3C Beihang, take the time out of her busy TPAC schedule to join us and deliver the opening message to attendees. Angel gave an inspiring talk and emphasized the importance of interoperability on the Web and the vital need for tests during the W3C spec lifecycle.

Educational Talks

The first two talks were given by Belem Zhang of Intel. Belem attended the Shanghai event and exhibited such proficiency there, he was invited to Shenzhen to help educate more newcomers. Belem began with How to Read W3C Specifications, emphasizing that specs are not intended to be user manuals and are written in a way that test author can extract assertions that require supporting tests. He then moved on to the detailed instructions for Using testharness.js, the W3C’s JavaScript testing framework. To test the audience’s knowledge gained from his presentation, he ended with a short quiz and quickly handed out a prize to the first correct response!

The next two talks were given by Zhiqiang Zhang, also of Intel. Zhiqiang is among just a small group of people who’ve attended four TestTWF events, including being a featured speaker at the past China events and attending the first TestTWF in San Francisco. Zhiqiang described How to Write W3C Reftests, which is the type of test preferred by the W3C for testing how browsers visually render. These types of tests are particularly common and useful for testing CSS. Following a logical order, Zhiqiang then covered the very important topic of How to Review W3C Tests (or How to Write Tests That Pass Review). One of the more challenging problems facing the W3C now is having qualified reviewers to approve the growing number of incoming tests. Recognizing this need early on, Zhiqiang nominated this topic and delivered an excellent talk on the subject. Last, and most importantly, Zhiqiang covered Where to Report Bugs - pointing the bugbases for specs, tests, and for each of the major browsers.

Lightning Talks

After the presentations came a series of lightning talks, where spec editors and experts gave a quick overview of a number of specs that need tests. Each person made a pitch to the crowd to write tests for their spec:

David Burns, Mozilla: WebDriver
Leif Arne Storset, Opera: CSS User Interface
Alan Stearns, Adobe: CSS Shapes
Dirk Schulze, Adobe: CSS Masking
David Baron, Mozilla: CSS Fonts
Rik Cabanier, Adobe: Compositing & Blending
Mark Sadecki, W3C + Kenny Zhang, W3C:  Web Accessibility
Daniel Davis, W3C: HTML5
James Graham, Mozilla: WPTServer (newly implemented test environment)

lightning talks

After the lightning talks, attendees were encouraged to meet and mingle with the experts. They had their questions answered and by lunchtime, everyone had signed up for a testing group.


After lunch, attendees had several hours to hack. People carefully followed the GitHub setup instructions, got their test environments set up, and starting taking on test writing. The energy in the room was great and the experts and attendees were very engaged all day. As the pull requests began to come in, we started hearing the familiar TestTWF “gong” followed by ripples of applause as people got more excited with each new test submitted. Throughout the day, there were several raffles – from the random drawings emerged several lucky winners of prizes ranging from gift cards to iPad Minis to the Adobe Creative Suite Master Collection.


Closing Talk

Perhaps the biggest prize of all for attendees and experts alike was hearing the closing words from a very special speaker, Tim Berners-Lee, Director of the W3C and inventor of the World Wide Web. When he was introduced, the event emcee suggested that people close their laptops to give him their undivided attention, to which he replied, “Don’t close your laptops! Keep coding!” At that, the room erupted in laughter and applause. Tim thanked the crowd for showing up and making a difference. He encouraged everyone keep making a difference, to teach their friends and colleagues what they learned that day, and to host an event of their own.

Tim Berners-Lee

After the Event

In the days following event, we saw good evidence of achieving success in perhaps the most important goal of this event: cultivating a community of Open Web contributors beyond just this one day. For the week following the event, we saw unprecedented followup activity in GitHub. Experts continued reviewing and new test authors continued their work in progress. We were delighted that after some new test authors had their tests reviewed and merged that they asked to be assigned more tests to write! While there is still much more to do, we are once again pleased at the tremendous turnout and enthusiasm from the Shenzhen web community during and after this event.

Favorite Quotes

“Why don’t you ask the HTML Editor? He’s sitting right there.”
– Doug Schepers, W3C Developer Relations

“Writing tests is a lot of fun. I want work on more challenging tests later on!”
– Sherlock Zhong, Attendee

“It was so easy! I wrote my first test and found a bug!”

– Jonathan Dang, Attendee

“This was my first Test the Web Forward. I really learned a lot”
– Mark Sadecki, Accessibility Expert

Special Thanks

These events would not be possible without the help and support of so many great people in the Open Web community. A very special thanks to these people who arrived in China early and spent a long and very full Saturday to help Move the Web Forward:

Experts & Speakers
Denis Ah-Kang, Wilhelm Joys Andersen, David Baron, Robin Berjon, Bert Bos, Judy Brewer, David Burns, Rik Cabanier, Michael Cooper, Daniel Davis, fantasai, Sylvain Galineau, James Graham, Andrew Kirkpatrick, Tobie Langel, Philippe Le Hégaret, Angel Li, Peter Linss, Sangwhan Moon, Mary Jo Mueller, Simon Pieters, Mark Sadecki, Simon Sapin, Dirk Schulze, Michael [tm] Smith, Alan Stearns, Simon Stewart, Leif Arne Storset, Masataka Yakura, Belem Zhang, Kun Zhang, Zhiqiang Zhang, and of course, Tim Berners-Lee.


And to a wonderful group of people who volunteered their time to provide translation support. You all went above and beyond…

Wei Jiang, Aili Wang, Wei Wu, Xiaoqian (Cindy) Wu, Donald Zhao.


Many thanks to TestTWF attendee, Bob Zheng for taking these beautiful photos of this great event.

A chat about River Trail

If you are interested in parallel programming using JavaScript, check out a very cool project called “River Trail” from Intel and Mozilla.  River Trail is aimed at exposing the power of multicore programming to JavaScript developers.

This effort is part of a larger initiative at Intel to contribute innovation to the web platform.  It is great to see Intel working in this space.  I had the chance to interview the team a few weeks ago to ask them a few questions – I hope you guys like it!

Expect additional videos in the future addressing various topics – from JavaScript to more designer orientated content.  If you’d like to be notified when new videos are posted, follow @adobeweb.

Important links mentioned in the video:

Official River Trail github repo:

Final API:
Sample workloads repo + tutorial:
Cool parallel JS articles:

Big thanks to Tatiana, Jaswanth and Stephan from Intel for their time and kindness.

A chat about River Trail

If you are interested in parallel programming using JavaScript, check out a very cool project called “River Trail” from Intel and Mozilla.  River Trail is aimed at exposing the power of multicore programming to JavaScript developers.

This effort is part of a larger initiative at Intel to contribute innovation to the web platform.  It is great to see Intel working in this space.  I had the chance to interview the team a few weeks ago to ask them a few questions – I hope you guys like it!

Expect additional videos in the future addressing various topics – from JavaScript to more designer orientated content.  If you’d like to be notified when new videos are posted, follow @adobeweb.

Important links mentioned in the video:

Official River Trail github repo:

Final API:
Sample workloads repo + tutorial:
Cool parallel JS articles:

Big thanks to Tatiana, Jaswanth and Stephan from Intel for their time and kindness.