Web Platform Team Blog

Adobe

decor

Making the web awesome

Browser Support Matrix for CSS Blend Modes

If you want to check the implementation status of CSS Blend Modes in the browser you are using (or targeting), you can now easily do so by looking at the CSS Blend Modes Browser Support Matrix.

When creating this matrix, we took advantage of the awesome work done for CSS Regions. In fact, we used the same code, so behind the scenes, the support matrix uses QUnit for unit tests and BrowserScope for storage. The only significant change to the backend is the addition of a manual testing capability.

Don’t get this wrong – whatever could be automated, was. It’s just that some functionality simply can’t be tested automatically. To verify that the blending operation between two layers was done correctly, we would have to check the pixel color values of the resulting layer. There is no JavaScript API to do this in browsers, and due to security reasons there probably won’t be one in the future. The only exception is Canvas, whose pixels you can access by design, but those tests are automated.

Not adding manual tests would limit the testing to whether the related CSS properties are considered valid by the browser, and that would have left a large area of the feature uncovered. False positives could ensue. (e.g. at the moment, in some browsers only the parsing of mix-blend-mode is implemented; the property is valid, the automated tests pass, but no blending actually takes place).

We tried to make the manual testing experience as painless as possible. The tests are simple, and are integrated in the same QUnit suite that runs the automated tests (via asyncTest). To avoid unnecessary testing, when a specific property parsing test fails, related manual tests will not be displayed, and their results will be registered as failures.

As the implementation progresses, we will keep the matrix updated with the latest support. That is, within reasonable limits – we will do it for major releases, but not after every patch that gets submitted. Of course, if you want up to date information on a nightly build, or for some reason are unhappy with what you see in the submitted results, you can always run the tests in the browser yourself. Just don’t forget to enable the appropriate flag before you do. You can also check out the sources on github.

In learning from its CSS Regions predecessor, to keep the matrix clean, the results submission mechanism will not be available externally. The Regions matrix initially went for a crowdsourcing approach, but a few months in the ‘internet’ wild proved that to be ‘suboptimal’.

The testing currently covers the background-blend-mode, mix-blend-mode and isolation (parsing) CSS properties and the Canvas 2D globalCompositeOperation attribute. Support for testing SVG blending will be added in the future.

Finally, in case you missed the links before, be sure to check out the CSS Blend Modes Browser Support Matrix, and the source code.

4 Comments

  1. September 12, 2013 at 11:38 am, C Snover said:

    If you were using an automated testing tool like Intern that provides remote browser driving instead of QUnit, you would be able to create a functional test that takes a screenshot of the remote browser after the blend and then check that the blending worked correctly by looking at the contents of the screenshot, thus eliminating the manual testing requirement entirely from your test suite.

    • September 12, 2013 at 3:30 pm, Horia Olaru said:

      Thank you for the suggestion. Let me elaborate a bit on the reasons we chose this approach.

      We aimed for the tests to be a high level way to verify that the feature works in a specific browser. This means we try to keep them to a minimum so that the testing effort is manageable. They do not cover all possible use cases, but there are unit tests for that. Those actually run automatically in browsers where the feature is being implemented.

      Another one of our main goals was to allow users to easily run the tests themselves, in their own browsers. Using a browser driver would require them to install additional software, and we wanted to avoid that. On a separate note, if manual tests can be qualitative, asking the tester to look for a similar image to verify that blending is working, pixel tests most of the time need to have precise matches. This usually means adding expected screenshots for all browsers (potentially adding new ones after new releases); times the number of OSs, along with factoring in other variables such as antialiasing. This could become more trouble than it’s worth for a small number of tests that do not really have to provide very accurate results.

      Some users may want to run these tests on a Nightly, or Canary browser build (I run them on local builds myself). This is very likely to be the case for other users, since a lot of the CSS Blending implementation happens as we speak, and some properties are only available on experimental builds. I’m mentioning this because Intern also provides integration with remote testing services, but I have to admit I am not familiar enough with them to know if I can do a remote test with a custom browser build.

      Please don’t misunderstand – I am all for automated testing. However, right now, I think the effort to maintain a framework that does all the above is greater than that of running the tests as they are. Perhaps in the future, as the number of supported platforms grows, the approach you suggest will make more sense.

  2. September 13, 2013 at 2:17 pm, BrianMB said:

    The major OS holders lag behind in Web Standards, as usual, but any intention to confirm/deny blend support in the pending IE11 and Safari 7 releases?

    WebKit Nightly might sufficiently represent the latter, not certain.

    • September 18, 2013 at 10:09 am, Horia Olaru said:

      While we are indeed working on implementing the blending specification in WebKit, as the Nightly results show, what browser vendors are shipping is entirely their decision. What the matrix shows is all the information we have on the subject.