The Future of Style aggregates posts from various blogs that talk about the development of Cascading Style Sheets (CSS) [not development with Cascading Style Sheets]. While it is hosted by the W3C CSS Working Group, the content of the individual entries represent only the opinion of their respective authors and does not reflect the position of the CSS Working Group or the W3C.
@counter-style
width descriptor renamed to pad.getComputedStyle() for
grid layout properties.an+b syntax redefinition in CSS3
Syntax.The CSS Working Group has published an updated Working Draft of Selectors Level 4. Selectors is a pattern-matching syntax for identifying sets of elements in a document, and is used e.g. for applying CSS declarations to elements in a document tree.
Additions include some new selectors:
:blank for elements that are empty or contain only white
space, and
:placeholder-shown for inputs that are showing a placeholder.
Review and improved naming suggestions are particularly welcome on
these—and also on the
drag and drop pseudos.
Another important change is lifting restrictions on
:matches() and :not() to accept complex
selectors, and the definition of two profiles, one
for CSS matching and another for less performance-intensive uses
like querySelector. We particularly encourage
implementers to comment on whether this split is reasonable, or
whether different things should be included/excluded.
The Working Draft includes a list of changes since the previous WD.
As always, please send feedback to the (archived)
public mailing list
www-style@w3.org with the spec code ([selectors])
and your comment topic in the subject line. (Alternatively, you can
email one of the editors and ask them to forward your comment.)
align-self property values, like they do
in other layout modules such as flexbox (and also block)On April 12-13, Microsoft hosted a record-setting Test the Web Forward event to advance the Web by creating interoperability tests. Dozens of volunteers from Adobe, AT&T, Blackberry, Mozilla, and many other local companies joined us at our Seattle offices to learn about Web standards testing, how to write CSS and HTML tests, as well as the tools available for test suite management. Attendees from around the country - and even Canada – contributed to create a record-breaking 514 overall new tests.
The quality and correctness of different browsers’ HTML and CSS standards compliance continues to vary widely. The W3C requires independent tests of all normative requirements in a specification in order to move a W3C Web specification from a candidate recommendation to an official recommendation. These tests are used to ensure that at least two browsers fully support each normative statement. As you might imagine, creating all of these tests is daunting; HTML5 is expected to need well over 100,000 tests, to say nothing of CSS3 modules, WebApps, Media Extensions, etc. We have submitted thousands of test cases for HTML, CSS, and SVG that can be viewed at the W3C and the Internet Explorer Test Center, however more tests are still needed. These tests benefit all browsers – and ultimately the entire Web developer community – by ensuring a consistent, predictable behavior. As different browsers improve their same-markup support, we can all realize the promise of HTML5 and CSS3.
A few years ago, several members of the standards community turned to crowd-sourcing to help create new tests, this resulted in Test the Web Forward events.
With the sponsorship of major players like Microsoft, Adobe, Google, and Mozilla, the Web community has come together, running local test-writing sprints around the world—France, China, Australia, and the US. Each sprint not only generates hundreds of tests, but also engages with and educates Web developers about the specifications that make up the Web platform.
Our friends at Adobe were instrumental in setting up a successful event, building upon their experience in running previous events. In Seattle we kicked off the hack-a-thon on Friday night, with inspirational and informative presentations from Mozilla's fantasai (Elika Etemad), Adobe's Rebecca Hauck, and Microsoft's Kris Krueger, explaining why we need tests, what type of tests are available, and how to create them. Here’s a quick outline:
Stand-alone tests typically rely on visual verification: if a failure condition occurs, red content will show.
Reference tests compare a test against a visual reference that has no dependency on the feature being tested. Note that the test includes a link to the reference test against which is should be compared. For example, if you wanted to test that DIVs render background colors correctly, you might make a ref test using TABLEs.
Object Model tests depend on a JavaScript test harness; they verify that the object model reflects what static style sheets specify. For instance, this CSS media query test.
These presentations were followed by 2-minute pitches from Saturday's session test leaders on why participants might want to pick a particular focus (CSS Flexbox, Pointer Events, CSS Transforms, CSS OM, Backgrounds & Borders, Exclusions, or HTML5), though session participants were free to write tests against any API or spec they felt passionate about.

Following breakfast the next morning, participants broke up into three rooms with session leaders helping out in each. Each area was staffed by experts (in addition to the speakers from the previous evening): Arron Eicholz (Microsoft, CSS); Jacob Rossi (Microsoft, Pointer Events); Sylvain Galineau (Adobe [formerly Microsoft], CSS); Alan Stearns (Adobe, CSS); Dave Methvin (President of jQuery, HTML).
The leaders instructed everyone on how to determine where tests were needed and how to create code that tested the specific assertion that we wanted to capture. Volunteers could either work on their own, work in small groups, or get 1:1 help with the experts.
When all was said and done, the sprint generated 514 submitted tests, just edging out the record set by the Paris test sprint and setting a new bar for upcoming sprints to beat. After a few celebratory drinks, the end of the night saw the raffling off of a Surface Pro which was won by a student volunteer who joined us from the University of Washington.
In IE10, we have added support for a long list of new standard features across CSS, HTML, SVG and the DOM. We have published some of our test cases for these new features on our IE Test Center. We will be submitting more, but we still need help from the community to get the right tests written and move these specs forward.
We are excited to be part of the community working towards a more innovative and interoperable Web. We support several initiatives in this direction, like the recent donation of JavaScript documentation to Webplatform.org, or our continued efforts to simplify cross-browser testing with modern.ie. If you want to help move the Web forward, too, come and join us at one of the next Test the Web Forward events! In the meanwhile, you can learn how to contribute tests, or review existing tests online. To hear about upcoming events and to stay in touch with the rest of the Test the Web Forward community, please subscribe to our W3C mailing list: public-testtwf. If test writing sounds too intense, but you are still knowledgeable and passionate about the Web, you can get involved with the WebPlatform Docs project and help document the Web.
For more info and updates, follow our Internet Explorer developer relations handle on Twitter @IEDevChat, this initiative’s handle @testthewebfwd and in particular #testtwf.
We will keep you posted on upcoming events and we are looking forward to meeting you soon!
—John Jansen, Kris Krueger, Arron Eicholz, and Jacob Rossi – Internet Explorer
flow-into.:blank to match.For Mobile World Congress 2013, W3C worked with several developers including Tomomi Imura (Nokia), Steren Giannini (Joshfire), and Dominique (Dom) Hazaël-Massieux (W3C) on two Web applications to demonstrate some of the new capabilities of HTML5 and related technology. I asked some of them about their experiences creating a camera app, a photo gallery app, and the server-side technology to stitch them together. The resulting demo worked as follows:
The camera project began in the Core Mobile Web (Coremob) Community Group as a way to illustrate both the current capabilities and limitations of the Open Web Platform (OWP).
Ian: Tomomi, when did this project start?
Tomomi: Originally, the app was nothing more than a prototype I wrote for fun. John Kneeland, from Nokia also wanted to work an app that would showcase the capabilities of the OWP. The Coremob CG seemed like the right venue, and we developed the specs in the fall of 2012, shortly before a Coremob face-to-face meeting.
Ian: The Open Web Platform intends to lower the cost of cross-device development (see the related interview with Todd Anglin on the Kendo UI survey). As you built the camera app, what did you find was relatively easy to make work across devices? What was difficult (and how did you solve it)?
Tomomi: Creating a user interface that is platform independent is one of the keys to cross-platform development. When I created the UI for the camera app, I designed it to be independent of the platform's look-and-feel, so a common CSS was all I needed. Non-trivial CSS works fine on all targeted smartphone browsers so I can say that designing the UI was the easiest part. Also, canvas works as expected on most browsers so I did not need extra workaround to support cross-platform.
However, to be honest, it was not as easy to make it cross-platform as I initially expected. A big reason is that the app was meant to showcase new features, which means it relies on new Web technologies that are in the early phases of standardization and not yet broadly interoperable. I found there was no browser that implemented correctly all the APIs I used in the app. In particular, I struggled to use IndexedDB to write photos to local storage. At the time I was coding, only Firefox and IE10 had implemented IndexedDB according to specification. Chrome 18 (was the released version at that time. Now, finally Chrome 25 is out of beta) supports basic IndexedDB, but was using an older version of the specification with no blob support for the database. I had to write extra code to make the demo work on Chrome.
Beside the workaround code, I used PhoneGap for Windows Phone 8 because IE10 for mobile lacks HTML Media Capture capability, although all other features worked fine. This is a hybrid app that, I think, is useful for illustrating how to work with HTML5 in a transitional mode where features not yet available on certain platforms.
Ian: What would you like to do next with the camera app? It's an open source project - are you looking for help from the community on specific aspects?
Tomomi: We have a bunch of things in the pipeline, notably writing tutorials on all aspects of building this app (like providing camera access using HTML media capture, storing pics in IndexedDB, etc.). We also have a nice table with all the key features required to build this app and how well (or poorly) they are supported in different browsers. I definitely want to share our experience in more detail with developers. Before doing that, I plan to simplify some of the code (to remove some hacks). This will cause more browser incompatibility, but my goal is not to promote hacks and tricks, but rather working with Web standards.
Ian: Steren, Joshfire volunteered to be part of this project because you already had a Web-based gallery app. What has been your experience so far (generally) getting your app to work across different devices? In particular, the app works on some televisions. What has been your experience so far with Web technology on televisions?
Steren: Joshfire is creating tools to build applications for today's devices and the ones coming tomorrow. For us, Web technologies are the logical solution to build a multi-device application that is sharing the same codebase on all these devices. The Web Gallery was developed under this model: 80% of the code is shared by all the versions of the app, and the remaining 20% is just for layout adaptation, view hierarchies, and user interactions.
Web technologies have been selected by TV manufacturers as the official tool to build applications for connected TV. That's a good thing and their browsers are now getting better. It was not the case in 2011, where some TV browsers had critical bugs and suffered from major performance issues. Today, it is more easy to develop for TV, I would say it is similar to mobile web development.
Ian: From your perspective, what are the priority features of the Open Web Platform where you think we need to make progress in order to close the gap with native platforms?
Steren: I think developers need features, frameworks and documentation that will help them to build rich client side applications more easily. And to close the gap with native platforms, they also need to be able to access device specific sensors and features (as enabled by projects like Phonegap). Native platforms have application ecosystems that are more than simple URLs: they ask permissions, install locally and auto-update in background. I think the Open Web Platform should provide the same mechanisms. An important priority is also to identify browser problems in the implementation of the specifications. Today, developers notice too many implementation differences that do not appear to be a priority for browser manufacturers.
Ian: Dom, you built the server that hosted the camera and the gallery apps. What were your priorities in building the server? What solutions did you adopt?
Dom: As in any other project, my priority was to do as little as needed. In this case, the server mostly had to act as a go-between for the camera and gallery apps, receiving pictures from the former to display with with the latter.
I chose to develop a node.js-based solution, since I was confident it would let me assemble the various pieces I needed easily; also, one of the features that we were likely to use, Server-Sent-Events, is much easier to implement in an asynchronous environment such as the one provided by node.js.
Ian: We set up this apps to run in a local environment (that is, not on the Web). If we wanted to make available a Web version of these apps, what would you have to change in the server configuration? How would you deal with security? Privacy? Flooding our server with photos?
Dom: There are two options for having the app run in an open environment:
The first approach would require some changes in the camera app and the server-side component. The second would require a new client-side component, and would also benefit from different kinds of Denial of Service attack protection (e.g., rate limiting the number of pictures that can be uploaded, using techniques to avoid robot-based submissions, etc.).
I would probably handle privacy issues at a different layer. We would need a policy and a process to determine when and how a given picture can be posted (e.g., asking the submitted to vouch they're not posting a picture of someone without their agreement), and how pictures could be taken down.
Ian: Thank you all for the insights, and good luck with the evolution of these apps!
The CSS Working Group has published an updated Working Draft of CSS Grid Layout. This CSS module defines a two-dimensional grid-based layout system optimized for user interface design.
This is a major update: not only has the draft generally been reorganized and much of the prose rewritten to fill in missing details, avoid repetition, improve precision and terminology, and ensure alignment with Flexbox, but it’s switched to a new positioning model. The old grid layout model uses properties to indicate the starting row/column and the item’s span. The new grid layout model positions each edge of the item to a grid line.
There are tons of issues marked in the draft, such as:
We’re totally looking for feedback, particularly on syntax
issues, so please send comments to the (archived)
public mailing list
www-style@w3.org with the spec code
([css-grid-layout]) and your comment topic in the
subject line. (Alternatively, you can email one of the editors and
ask them to forward your comment.)
Comments have also been enabled on the cross-post over at CSS3.info. We strongly encourage feedback and suggestions for improvement from the design community!
The CSS Working Group has published an updated Candidate Recommendation of CSS Values and Units Level 3. This CSS3 module describes the common values and units that CSS properties accept and the syntax used for describing them in CSS property definitions.
This is publication mainly just incorporates some minor fixes and clarifications. It also defines the interaction of scrollbars and viewport units. Changes since the last publication are listed in the Changes section.
As always, please send feedback to the (archived)
public mailing list
www-style@w3.org with the spec code
(>>[css3-values]<<) and your comment topic
in the subject line. (Alternatively, you can email one of the
editors and ask them to forward your comment.)
color-correction is still
needed.nav-* properties to level 4.
Contact Web and TV and Opera about nav-* changes. Ask
for comments from WAI PF and SVG and any groups we asked for
previous Last Call.The CSS Working Group has published a first public Working Draft of the CSS Overflow Module Level 3.
This module describes:
This draft is still relatively early in development, but the group welcomes feedback on all aspects of the draft.
As always, please send feedback to the (archived)
public mailing list
www-style@w3.org with the spec code
([css-overflow-3]) and your comment topic in the
subject line.
#123abc to be a valid ID
selector, to match HTML5. Need to collect data on this.:nth-child()/etc don’t
require a parent: they’re based on siblings. This is a change from
Selectors Level 3 REC.:matches() to the specificity of the actual matched
selector.The CSS Working Group has published a Candidate Recommendation (and call for implementations) of the CSS Conditional Rules Module Level 3. This module describes the @media and @supports rules and associated APIs. It extends CSS level 2 by allowing nesting of certain at-rules inside ‘@media’ and adding the ‘@supports’ rule for conditional processing.
The working group is interested in feedback from authors and implementations, contributions to the test suite, and feedback on the tests in the test suite.
Changes since the last Working Draft are listed in the Changes section.
As always, please send feedback to the (archived)
public mailing list
www-style@w3.org with the spec code
([css3-conditional]) and your comment topic in the
subject line.
image-rendering, distinguishing between
auto and smooth, perf considerations for
animations.Today, we are updating modern.IE with enhanced tools and resources to help you test your sites for modern browsers like Internet Explorer 9 and 10, while also helping you support older versions of browsers. These enhancements address the most common feedback, suggestions, and requests that we have received from enthusiastic users since introducing the site in January.
With today’s update, we are making available a new offer, new downloads, and tool enhancements on modern.IE. Some highlights include:
We continue to offer 3 months of free BrowserStack access so you can easily test across browsers and OS platforms without changing your primary development environment.
We are excited to see the developer reception to modern.IE so far. We appreciate the thoughtful feedback in tweets and suggestions you have offered on ways we can help save time and improve how you test your Web experiences. Today’s modern.IE release incorporates much of that feedback. Please do keep the comments coming, as we will continue to update the site regularly.
We heard that the most common way you test across browsers is through virtualization of browser and operating system combinations using your favorite virtualization platform, such as Hyper-V, VMWare, VirtualBox, or Parallels. However, costs to purchase software and licensing can be difficult if you’re that startup looking for your first big breakthrough.
Today we’re making it just a little easier with a new combo offer: We’ll ship you a copy of Windows 8 and Parallels Desktop 8 for Mac virtualization on a USB stick for a $25 donation to your favorite charity, courtesy of our friends at Swish. (Update 10:45am PDT 4/2/2013: The Windows Quickstart offer sold out quickly. Given how popular these were, we will look into making other offers available in the near future.)
We only have a limited supply available. You can get the details and pre-order here.
You told us that you want to be able to access as many testing environments as possible with minimal extra effort. Today we announce new virtual machines that are available for free:
We also received lots of feedback from developers on Mac and Linux concerning how to simplify your testing experience. We have added Parallels for Mac images for all IE versions. Many of you had some challenges downloading the VMs previously, and in response, we have updated the VM installation process to be simpler. Complete download information is available here.
Based on your feedback and experience, we have enhanced the scan a Web page URL tool to provide more flexibility and to offer more detailed and actionable guidance. Over the past two months, you have scanned hundreds of thousands of URLs – from top sites like Facebook, Pandora, and Yahoo! to the local pizza store near you. We have studied the most common coding issues reported on these sites and looked at which issues resulted in fixes or enhancements to the site. We also received hundreds of new ideas directly from the community. The result was a set of new enhancements that make the scanner a more complete testing solution for your site:
We have also made dozens of bug fixes in the scanning tool to handle Web pages that used less common practices or frameworks & libraries. If you scanned a Web page and got an error, we encourage you to try it again!
modern.IE will be available in 18 languages throughout the next two days, making it a bit easier for site developers around the world. The supported languages include Arabic, Bahasa Indonesia, Chinese (Simplified, Traditional, and Hong Kong), Dutch, French, German, Italian, Japanese, Korean, Portuguese (Brazilian), Russian, Spanish (Spain and Latin America), Swedish, Thai, Turkish, and Vietnamese.
We will continue to enhance modern.IE with your help. Please continue to share your feedback on this resource. Please continue to let us know what you like, and what we’re missing!
-- Sandeep Singhal, Group Program Manager, Internet Explorer
The CSS Working Group has published an updated Working Draft of CSS Counter Styles.
This spec documents the existing CSS 2.1 and 2.0 counter styles
in better detail, adds a handful of CJK and other list styles, and
adds an @counter-style rule which allows authors to
define their own counter styles.
Significant changes since the last Working Draft are listed in the Changes section. Significant additions include:
width descriptor for, e.g. zero-filled countersspeak-as descriptor for customizing
text-to-speechdisclosure-*
styles, intended to be used for the HTML
<details> element and similar use casesWe’d especially appreciate a review of these additions. We expect the next publication to be Last Call.
As always, please send feedback to the (archived) public mailing list www-style@w3.org with the spec code () and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)
The CSS Working Group has published an updated Working Draft of CSS Custom Properties for Cascading Variables.
The Variables spec defines a family of “custom” properties, whose names and values are completely author-defined. These properties provide values to “CSS variables”, a new type of value, which are substituted with the values they stand for, allowing authors to create more modular and maintainable style sheets by centralizing the definition of common values.
We’d appreciate people to review this draft carefully, as we expect to take it to Last Call soon. In particular, the section on the variables API is new, and we would appreciate feedback on it.
Significant changes are listed in the Changes section.
As always, please send feedback to the (archived) public mailing list www-style@w3.org with the spec code () and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)
offsetParent and region parenting.This is our weekly Openweb Platform Summary from March 18, 2013 to March 24, 2013. You can read again the last week blog post. Your comments are helpful.
Sometimes Web designers wish to be able to create a smooth
scrolling effect when adjusting the scroll position of a page. Tab
Atkins (and someone else at Google) is proposing
to modify
Boris Bzarsky (Mozilla) is
explaining
the current behavior in Mozilla. Simon Pieters (Opera) is wondering
if there should be way to control the time dependency of the
scrolling.It could become also a good opportunity for users to have
more control on it and deactivate it through user stylesheets. Read
the
full thread.scrollTo and scrollBy
functions in CSSOM
View to take a third parameter: an optional "smooth" string. If
omitted, the scroll is instant.
:first-child without parentCSS world is sometimes harsh. A :first-child can
never
match a root element because it has no parent element and so is
not the child of any elements. Read the
full thread. The issue comes with DocumentFragment
what should happen in this case. Boris Bzarsky and Tab Atkins
outlined some
possibilities.
input type="range"When using <input type="range">, it might be
useful to have it vertical or horizontal. Jonathan Watt was
working on its support inside Mozilla and asking if there
should be a property inside CSS for it. It seems that a specific
attribute orientation is an intermediate solution in the
meantime.
min-width and max-width as
pseudo-classesDo we need :min-width/:max-width
pseudo-classes for CSS layouts? A
blog post is explaining the issues related to Responsive Web
design per elements and layout resizing when in a different context
than the main document. This started a
gigantic thread on CSS list with very interesting concrete
cases.
Charles McCathieNeville (Yandex) has posted use cases related to appcache.
video
playlistHow would you implement the playlist in HTML?
longdesc is
backIf you have been living under a rock, you might not know, but
longdesc attribute is in the process of being back in
HTML5. Not yet done. There are still a few
issues to solve before.
This is our weekly Openweb Platform Summary from March 11, 2013 to March 17, 2013. You can read again the last week blog post. Your comments are helpful.
When discussing about Shadow DOM, security questions having been raised such as keeping the integrity of a Shadow DOM. Boris Zbarsky explained what are the current ways to have access to it.
Brian Kardell proposed
to have additional CSS constructs to combine selectors and/or
create sets of selectors. He outlined his ideas in a
blog post too. François Remy explained
the ideas of Brian on the list and outlining that not
already exists, or can be emulated with commas and
there is a missing and operator. He also noted
that a full syntax for
:and/:or/:not would be
useful.
Anne van Kesteren (who is now working for Mozilla) is in the
process of revising the
fetching of data. He is tackling the issues one by one for
adding consistency to the Open Web Plaftorm. The
Origin header is
specified in different ways depending on the interface. He also
tested
data urls and network errors,
HTTP Authentication,
crossorigin, .
Kenneth Russel is
proposing to get an ImageData constructor with
preexisting data. Read the
thread.
:matches() to
:any().order property
affect auto-placement and z-order in Grid, just as it does in
Flexbox.As developers build on the full capabilities of HTML5, touch, and hardware accelerated graphics, the web today is more engaging for consumers than many imagined. The experiences developers are building today simply were not possible just a few years ago.
Saturday marked the third anniversary of the IE Test Drive site. What started as a few examples of hardware-accelerated HTML5 to help developers imagine the potential of the web, has grown to a collection of over 140 feature-packed demos. Test Drive gives you a taste of what’s possible with HTML5 and modern browsers on modern hardware: HTML5, CSS3, ECMAScript 5, touch, GPU-powered graphics, blazing performance, audio/video, mobile, games, and more.
The support you’ve shown is humbling – over the last three years the Test Drive has received over 130 million page views! That’s more than a page per second for the last three years! We’ve had a lot of fun building the demos, and thought we’d take a look back at some of our favorite demos along the way.

The IE Test Drive Site contains over 140 demos!
| Audio Explosion | Touch, see, and hear IE10 |
| CanvasPinball | The perfect work time break |
| Chalkboard | IE10 takes other browsers to school |
| FishBowl | HTML5, CSS3, Video, Audio, Canvas, Fish |
| FishIE | Started the fish revolution |
| Flying Images | Our very first Test Drive! |
| Galactic | Out of this world performance |
| Hamster Dance Revolution | Get ready to become addicted |
| Love is in the Air | We love you too |
| Minesweeper | Speed that’ll make your browser explode |
| Mr. Potato Gun | Actions speak louder than marketing videos |
| Psychedelic Browsing | Our “highest” viewed demo after 2am |
| Speed Reading | How fast can your browser speed read? |
| Touch Effects | Touch your way to a faster experience |
| Tracking Protection | Putting your privacy first |
IE10 continues to deliver the best performance for real world Web sites on your Windows device, and the Test Drive is a great place to experience what’s possible yourself. Take the Test Drive for a spin today and let us know what you think!
We’re always excited and humbled by the amazing experiences developers are building on the web every day. Thank you for your continued feedback and for using IE10.
— Jon Aneja, Program Manager, Internet Explorer
Building Vyclone's Interactive Experience with HTML5
The Web is more engaging and productive for consumers, as developers unlock the full potential of HTML5. In this guest blog post, Anton Molleda of Plain Concepts talks about his experience and learnings while developing Vcylone, a social video editing experience built on HTML5 and many of the new features in next generation browsers like Internet Explorer 10. Vcyclone builds on capabilities like pointer events, multi-touch gestures, and hardware accelerated canvas and CSS3 to make this Web site feel more like an app.
— Rob Mauceri, Group Program Manager, Internet Explorer
Hello everyone,
My name is Anton Molleda and I work for Plain Concepts. These last few months the team at Internet Explorer has been collaborating with the awesome crew that makes up the hot up and coming social video startup Vyclone. As a Web developer, having the opportunity to push the envelope with what the Web can do is one of my passion points. Fortunately, I’ve been lucky enough to help out on this project. And today, I want to share with you some key learning we had while we worked together to create a video editor on the Web for Vyclone, using just HTML5 and JavaScript!
Vyclone is a social video platform that lets you co-create, sync and edit multiple views of a shared moment, effortlessly.
When Vyclone first started, it solely focused on mobile devices. But soon they realized that while the recording experience is great from a phone, editing that video was limited due to the screen size and power of the device. Thanks to the progress done these last few years in modern browsers, HTML5 was a viable option as the way to go to create this new tool.
The core of Vyclone’s Web editor is composed of three parts:
The video preview: Where a low quality version of the cut the user is creating can be watched (on the left)
The vidgrid: Where all the available sources are presented to the user showing a given point and time (on the right)
And the timeline: Which indicates a linear view of which source is playing over the course of the video. A source playing during a certain amount of time is called a cut (shown above the player controls)

As the user plays the video and starts adding new cuts to the timeline, the video preview switches to reflect the new source, and the vidgrid highlights the source file with triangle corners to identify to the user which video is selected.
So in building this out, we ran into a very interesting challenge with sheer amount of video manipulation, the performance we were getting back, and the user experience. Let’s dig into what we did to make this happen on the Web. So we’re using video, canvas and requestAnimationFrame (RAF). We have a video in the background that is played, and in each RAF we draw the active source into a canvas (in the video preview) or we calculate its new size and position into the vidgrid.
So far so good, but what happens when we let the user interact with it? For example, what happens when a user moves the timeline forward and back, or adds / removes video sources (cuts)? When we first started prototyping this out, we thought the standard approach would be to take care of that as soon as the event is fired - because that's the way we've been taught, right?
But what happens when those events can be fired tens of times per second, or even hundreds of times per second? And what if those handlers need to update the UI? Do we really need to force a layout refresh 130 times per second when the delta change could sometimes be less than a pixel? Talk about performance drag!
If your machine has an i7 with 8GB of RAM, you can probably afford computing power to do that. But what about people with an older rig? Or an ARM device? Those users will not have the same experience and will see the reaction time of the Web site slow way down.
Our first approach was to queue the action in the RAF but there were some problems with this approach, such as, you can RAF up the same function for the same "tick", effectively making things worse. To solve for this, our first approach was to have a variable that will tell us if the action was already queued up. Something like this:
var queued = false; function myAction(){ //your awesome code here queued = false; } function onEvent(evt){ if(!queued){ queued = true; requestAnimationFrame(myAction); } }
This code is not bad but still has some problems. If you are doing something related with the event position (mouse or pointer) and a delta, you might find that you’ll struggle with this approach. The solution we used in the timeline is to accumulate the event value and process it on myAction:
var deltaX = 0, queued = false; function myAction(){ //your awesome code here uses deltaX deltaX = 0; // we reset the deltaX so it can be incremented // next time onEvent is executed queued = false; } function onEvent(evt){ if(!queued){ queued = true; deltaX = evt.translationX; // in the case of a pointer, if you are // using a mouse you will have to do some // magic with pageX or similar :) requestAnimationFrame(myAction); }else{ deltaX += evt.translationX; } }
With this approach you should be pretty much ready to go. We kept adding functionality and then noticed some new problems popped up.
By handling those events when appropriate at each requestAnimationFrame we were able to achieve a higher level of responsiveness without sacrificing computing power. But since requestAnimationFrame executes the functions in the order, they are queued up so sometimes we were drawing before cleaning, or moving the timeline when we didn't have to and we had to create a lot of cumbersome code to make sure it got executed the order we wanted.
We saw that code wasn't very friendly and we were losing some cycles waiting for other actions to be performed so we decided to change again how we handled the input. It was at this moment that we thought about this as a game loop. If you’re not familiar in (simple) game architecture, the game loop is basically a continuous loop that gets executed regardless of the user interaction and splits apart when different events and actions should occur. From the Wikipedia article Game Programming, a simplified game loop in pseudo code could look like this:
while( user doesn't exit ) check for user input run AI move enemies resolve collisions draw graphics play sounds end while
That was exactly what we needed. Taking advantage of RAF we created a tick function that is executed continuously and inside this tick function we decide what we have to do depending on previous user input or other factors.
The simplified tick for the vidgrid is something like this:
function tick(){ //we clean if we've changed the size of the quadrant if(needsClean){ cleanCanvas(); } // if we have to change the quadrant's frame because we are // the active one (or the opposite) if(newFrame){ drawFrame(); // we draw just the frame in a separate canvas so it // doesn't need to be calculated all the time, and it // is still faster than copying from an image } //we draw the new frame if we are playing or seeking if(dirty){ draw(); drawFrameInQuadrant(); } requestAnimationFrame(tick); }
The values of needsClean, newFrame and dirty are updated on the event handlers (when the user is seeking, video playing, etc.).
It was this shift in the way we thought about the user interactions, going to a game loop mechanic, that allowed us to improve the performance and simplify our code in the editor.
Big takeaways, if you are building something is requires high interactivity and receives a lot of user input, think about how potentially using a game loop can make your life easier! It sure did for us. And if you haven’t had a chance to check out Vyclone’s sexy new Web editor (if I don’t say so myself), get going! Click ‘Remix’ on any video on Vyclone.com and you’ll see our Web editor. It works equally well with mouse or touch input. I highly recommend giving it a go on a Surface Pro!
Enjoy! Hit me up with some comments below if you have any questions!
— Anton Molleda, Plain Concepts
min-width/min-height to zero for Flex
Items:root { font-size: 1vw } @page
{ width: 50em } and what to do to break it.animation-direction reverses an animation, the
timing function goes in reversez-index is *not*
optional on page-margin boxes.format() in
image() for fallbacks, and where to register new
subtypes.display shorthand, so
that it is not accidentally reset by style rules setting the box
type@page
‘size‘, and similar situation with
@viewport sizing.@page OM to
css3-page, exact OM API TBD.@keyframe rules
cascade.pseudoElement on
animation events. Mark at-risk. Revisit in a few months if it’s a
web-compat problem.
width feature. Expect LC in a few weeks.column-gap, not to column-width (use
column-count for that, it’s better).weekly Openweb Platform Summary from February 17 to 24, 2013. You can read again last week version. Your comments are helpful.
A new Working Draft for CSS Animations has been announced
The key generator maximum value in IndexedDB is
9007199254740992. When reached, an error is generated
but it was not specified which type of errors.
store = db.createObjectStore('store', {autoIncrement: true});
store.put('a', 9007199254740992);
r = store.put('b');
r.onerror = function(e) { alert(e.target.error.name); };
It is now:
ConstraintError
The discussion about syntaxes for variables in CSS has been restarted by Jens Meiert. See also this thread
Robin Berjon checked which areas of the Open Web Platform needed more tests. Here there is an opportunity for you to help.
Henrik Andersson has mentionned how impossible is it to style many elements in the browser.
In the thread, Tab Atkins has mentionned that it is not a lack of will, but it is a very hard issue to address with a lot of work to do. We have a tendency to forget that it would be indeed cool to have this, but it also means that people need to dedicate time for it, and there are not that many talented people to write specifications and implementers to test them in parallels.
How do you give hints to the browser that it is not necessary to load an image before it actually tries to download it. Let's say there is
background-image: image("whatever.webp", "whatever.jpg");
but the browser is not supporting webp. There should be a way to tell the browser that this is a webp image. Add a pinch of mime-type, mix slightly with explicit metadata and you get a long thread
It has been decided that the work about HTTP2 would be done on W3C Mailing-List and the work edited on GitHub. You can follow the commits to the specification and the issues. Finally, youcan also read the most current editor's draft.
When an XHR request is going on and the user is aborting it, through esc for example. What should happen? Currently there is a difference in between the "natural" network abort and the ones cancelled by the users. Anne van Kesteren is proposing to remove the user specific ones.
The Future of Style features:
If you have a post you want to add to this feed, post a link (or the whole thing) on the CSS3 Soapbox. If you own a blog with frequent posts about the future of CSS, and want to be added to this aggregator, please get in touch with fantasai.