Web Platform Team Blog

Adobe

decor

Making the web awesome

Bringing blending to the Web

If you’re a user of our design applications such as Photoshop and Illustrator, you know how you can create very cool effects with blend modes. An Amazon search returns many books and a Google search on ‘photoshop blending tutorial’ returns more than 200,000 results. This points to a very widely known and used feature.

If you’re unfamiliar with blend modes, they are a set of operators that determine how 2 layers are blended together.
The following example shows the normal case where two images are combined with no blending:

There is no interaction between the gradient and the image.

By using the ’overlay’ blend mode, we can make the gradient interact with the image of the DJ like this:

By using this blend mode, the colors of the image of the DJ are recalculated such that the lightness or the darkness of the background gradient is preserved.

Last year, I joined the W3C and started contributing to the SVG and FX task forces.  I am now spending the bulk of my time on editing, discussing and implementing the CSS compositing and blending spec. You can find a very early draft here.

There already was a draft spec that described how to accomplish this in SVG, but there was no adoption in the major browsers. The FX task force, which oversees rendering features that overlap SVG and HTML, wanted a spec so blending and composting applies to all HTML elements, not just SVG. Our intent is to publish the spec through the W3C process and implement it in WebKit. If there is demand, we could potentially add it to the canvas specification as well.

The hardest part of writing this spec is not how to define the new proposed properties since this is well understood and done before (eg in SVG and PDF); it is how you can explain it so anyone can understand what it does and how it is supposed to work.

In today’s blog, I’m only going to cover how you can specify a blend mode.

The new draft will introduce a new CSS property: ‘blend-mode’ that takes the following values:

  • normal
  • plus
  • multiply
  • screen
  • overlay
  • darken
  • lighten
  • color-dodge
  • color-burn
  • hard-light
  • soft-light
  • difference
  • exclusion
  • hue
  • saturation
  • color
  • luminosity
You might be familiar with some of these values from their use in Photoshop, Flash , Illustrator and InDesign. Here is an example that shows the markup with ‘overlay’ blend mode:
<div style="background: url('gradient.jpg');">
   <img style="blend-mode: overlay;" src="url('dj.jpg')"/>

When blend-mode is applied, it interacts with every element that is rendered behind the element on which the blending mode is specified. In this example, anything that is behind the image will blend with it, not just the parent div with the image background.

A couple of weeks ago, our team got together in San Francisco for a hackathon and we tried to implement this in WebKit. I expected that we wouldn’t get very far, but lo and behold, it took us only a couple of hours to get something up and running.

The reason we could do it this fast was that CoreImage already supports these blend modes. In combination with our experience in shaders, we were able to hook this up and get GPU accelerated blending to work in our prototype. Unfortunately, the code we wrote for the hackathon is not of a shippable quality (which is why you won’t see it soon in a Webkit Nightly), but the fact that we could it so quickly is very encouraging. We are planning on showing the prototype and the draft spec to the W3C in May and if our proposal is accepted, we will contribute it to WebKit in the near future.

The cool thing about CSS blend modes is that you can not just apply them to simple HTML elements but also to SVG content, video or elements with CSS animations or transitions.

My next blog post will go a bit deeper over the syntax and will show more examples.

In the mean time, I’d love to hear your comments!

57 Comments

  1. April 04, 2012 at 1:07 pm, Ahmad Alfy said:

    Interesting!
    Consistency across different browsers is what concerns me! Browsers are unable to render shadows similarly! Shadows are considered basic compared to blending images! I don’t think it will be adopted to be honest.
    Now I am actually thinking, this is adding one more http request and will cost more bandwidth because we are using 2 images.
    Suddenly I am frustrated.

    • April 04, 2012 at 7:43 pm, Rik Cabanier said:

      We’re planning on creating an extensive test suite that exercises all the features and also provides expected renditions. This should make browser render blending consistently.

      I’m unsure why you think that this introduces an extra http request. All we’re introducing is an extra css keyword. Could you elaborate?

      • April 05, 2012 at 4:32 pm, BrianMB said:

        He’s suggesting that you merely recreate the final product of a blend in a graphics tool, then use that image in your app. He doesn’t fully understand the concept.

        Also, please consider renaming the “blend-mode” property to just “blend” or “blending” – looks and sounds nicer.

        • April 05, 2012 at 6:08 pm, Rik Cabanier said:

          We proposed a couple of suggestions for the ‘blend-mode’ keyword to the www-style mailing list and this is the one that people liked best.
          There will more discussions on the mailing list after the W3C face-to-face meeting. Feel free to chime in!

        • June 22, 2013 at 1:27 pm, Joshua Beckwith said:

          ‘blend-mode’ is the industry standard naming convention for what this thing does. Anyone who has experience with Adobe will probably agree.

      • April 10, 2012 at 7:51 am, Ahmad Alfy said:

        That’s great. Good luck :)
        What I meant about extra http requests is, instead of blending the images with Photoshop for example and coming up with one final image this way you will be calling two images and ‘blend’ both within the browser. Does that make any sense?

        • April 10, 2012 at 7:30 pm, Rik Cabanier said:

          ah, now I understand!
          In the majority of cases people will be able to keep their vectors since you can apply blending to them. This will cut down at least 1 http request and lower the number of bytes that are downloaded since you no longer need an image.

        • June 20, 2012 at 9:28 am, Paul d'Aoust said:

          I see what you’re saying — why not blend the two images in Photoshop and save having to composite them in the browser. But I think the author’s example was just illustrating what’s possible, rather than just what’s recommended. Personally, I see more value in applying blending modes to text and block, rather than images. This would save an HTTP request that would be required if I created the text or block in Photoshop.

  2. April 04, 2012 at 5:29 pm, Edward O'Connor said:

    Shouldn’t this just be a filter? I don’t think we should add yet another rendering stage…

    • April 04, 2012 at 7:43 pm, Rik Cabanier said:

      A filter only acts on the element itself. Blending requires that you have access to the element and its backdrop.
      In our experiments so far, we haven’t seen the need for additional rendering steps. Even though blending introduces a new stacking context, the page is still rendered in one pass.

  3. April 04, 2012 at 5:41 pm, bowerbird said:

    why don’t you get .svg working _correctly_ first,
    before you muck it up further with complications?

    -bowerbird

    • April 04, 2012 at 7:44 pm, Rik Cabanier said:

      There is a lot of value in having a CSS solution. For better or worse, designers are much more comfortable with CSS than with writing SVG filters.
      You can see this effort in a similar light as Apple’s proposal for CSS filter shorthands: simplify the syntax (and cut down on features).
      The idea is to make it:
      - easy to use
      - easy to add hardware acceleration
      - applicable to all content (not just SVG)

    • April 05, 2012 at 4:35 pm, BrianMB said:

      1. HTML content is more useful (in general) than SVG.

      2. Using CSS effects on SVG is more useful than SVG effects are alone.

  4. April 04, 2012 at 6:24 pm, Dale Sande said:

    This idea is pretty cool, but not hip to the idea of wrapping div around content for the sake of display. Not very semantic and ties design to content to tightly.

    In CSS we can have multiple backgrounds (http://goo.gl/tPoDE) what I think would be awesome is if we could enhance this spec for this new attribute. Something like:

    background: url(images/play_icon.png) no-repeat 5% 50% overlay, -webkit-gradient(linear, left top, left bottom, color-stop(0%, #ffcc00), color-stop(11%, #ffc903), color-stop(100%, #ff9d2f));

    In this example I can blend a Play Icon into a gradient background.

    • April 04, 2012 at 7:44 pm, Rik Cabanier said:

      I’m not sure what you mean by wrapping a div around?
      The content with the blend mode (= content + its background) will interact with everything that is underneath it.

      Your example does blending within the element itself. This is a very interesting use case that we haven’t thought of!
      Do you think we should make it part of the proposal?

      • April 04, 2012 at 8:16 pm, Dale Sande said:

        Your example illustrates blending the background image of a block with the image contained within that block.

        I think it would be awesome if we could leverage the concept of multiple backgrounds and blend them in the same block using the same CSS class.

        If you like the idea then that would be awesome to make that part of the spec proposal.

        • April 04, 2012 at 9:29 pm, Rik Cabanier said:

          The div was there only so the images would overlap. We could have used absolute positioning to get the same effect. (We had a discussion on this before the post went out and tried to capture it in the description that follows the code block.)

          I do like the idea of having blending within the block but have to think a bit more about it. I will add some comments to the spec.

          • May 02, 2012 at 5:03 pm, thinsoldier said:

            I think what the previous comments were getting is is that if I have purely decorative imagery on a page (maybe the backdrop of the whole site is a gradient from gold to black overlaid with tiling musical notes at the top horizontally and a different image of music notes at the bottom, horizontally again) then there’s really no good reason to use an IMG tag in the content since there’s no need for an alt attribute on that image. Therefore it would be better to achieve that background effect by use multiple background images.

            Now lets say the base gradient color changes from page to page. Currently we’d make the musical notes images semi-transparent pngs to achieve some appearance of “blending” with the gradient. But it would be better if we could use the proposed blend-modes in this situation.

  5. April 04, 2012 at 6:27 pm, Alan Mathieson said:

    This is the sort of thing that makes me cry. Really. Have you turned your back on us so much? Blend modes are on the web – have been for years. It’s called Flash. And the last time I looked Flash is still part of the web. Absolutely gutted.

    • April 04, 2012 at 11:10 pm, Deepa Subramaniam said:

      You are correct that blend-modes have been available in Flash for years. In fact, I believe they were introduced in Flash 8. But blend-modes, and the power it offers designers, even pre-dates its introduction in Flash. In fact SVG introduced blend-modes years before Flash. Creative tools like Illustrator and Fireworks have allowed designers to modify artwork via blending for a long time. The reality is that designers working in those design tools want their creations to be brought to life in Flash but also in HTML. In Flash, this is very simple but in the HTML world, you have blend-modes in SVG but those are not specifiable via CSS. This means a developer has to specify blend-modes in SVG but can’t have a single stylesheet to control all their CSS, including presentational attributes like blend-modes. This is a pain for developers and one that we are trying to address.

      We are in no way removing blend-modes from Flash. Instead, we are keen on taking the blending power that has existed in SVG, and make it usable in CSS.

  6. April 04, 2012 at 7:01 pm, Brian Grinstead said:

    Thanks for sharing this, and for doing all the footwork with the draft spec and prototype! I’ll be keeping an eye on the progress – I can’t wait to be able to use this. Is your prototype available anywhere?

    • April 04, 2012 at 7:46 pm, Rik Cabanier said:

      No, we haven’t made it public yet.
      We want to present it to the CSS working group first before we proceed with WebKit integration.
      Then depending on how we expose this, you can build it yourself or you can turn it on as an experimental feature

  7. April 04, 2012 at 8:27 pm, Ashraf said:

    Yes please!!

  8. April 04, 2012 at 10:18 pm, DilMat said:

    Very nice!
    I believe it would be a good idea to make blending available for canvas2d, as there could be achieved straight forward hardware accellerated effects for games (via drawImage), without having to loop through every pixel or having the asset as a distinct html element. In fact, I never really understood why blending was not in Canvas2d spec in first place.

    • April 04, 2012 at 11:08 pm, Rik Cabanier said:

      I agree that it makes a lot of sense in Canvas as well.

      Do you think we should push on that? I can see that basic blending could be implemented easily.
      However, things like non-isolated groups and knockout might be tricky since they need retained graphics. We could leave those out for now.

      • April 06, 2012 at 12:43 am, DilMat said:

        AFAICT, with the canvas element itself, there is neither implicit nor explicit nesting or grouping where blending is applicable. The element itself cannot have content (other
        than for fallback), and CanvasRenderingContext2D does not have any nested objects at a level relevant for blending (e.g. paths would be viewed as a single object from blending point of view, i.e. they would be traced before blending and without being affected by blend mode, just like path tracing is not affected by globalAlpha and globalCompositeOperation).

        Therefore, the concept of group isolation IMHO does not (yet) exist for CanvasRenderingContext2D API level, but it is trivial to implement at API-user level by using offscreen canvas(es).
        I don’t think that implicit retaining of intermediate graphics by setting state via something like beginGroup() does give much of a performance gain, and as it does not solve any unsolved problems, it might not be worth the hassle at all.

        Knockout however would require something like ‘clip-to-self’, which currently requires to do some sort of manual scanline at API-user level, i.e. accessing individual pixels, which is
        not hw-accelerated. Perhaps a ‘createClippingPathToSelf’ method is sufficient, as knockout then could be achieved by a reasonably low number of hw-acc API calls and offscreen canvases. But generic native scanline for CanvasRenderingContext2D could be even nicer.
        There also would be CORS implications, as such a clipping-path-to-self exposes information of the canvas pixel data.

        Additionally, filters would be something that I believe should also be exposed to CRC2D, e.g. via an ‘applyFilter(cssFilterString)’. They might even enable a hw-acc way for knockout (again explicitly retaining intermediate results on distinct canvas elements)

        Blending, knockout and filters certainly have relevant usecases in the scope of Canvas2D, so eventually they should be available to the CRC2D user. Filters should be quite easy to implement as well, and might even provide a way to do hw-acc knockout without state-dependent retaining of graphics.
        As some implementors tie their release cycle to their operating system release cycle, I would certainly be in favor of getting this adressed rather sooner than later, so to give those vendors a chance to not miss out on too many turns. So yes, push, please.

        I hope that I am not too lost in my own misconceptions and that some of this makes sense.
        Thank you for listening, with bonus points for allowing comments without having to log in with this or that account!

        • April 06, 2012 at 4:17 am, Rik Cabanier said:

          No, thank you for providing feedback!

          Canvas has indeed no concept of ‘grouping’. Because of this, all blending and compositing is done as if they are in isolated groups.
          Maybe we have different concept about what isolation is.
          In our proposal, elements with blending that are in an isolated group only blend with the elements of that group. In a non-isolated group they will blend with everything that is behind them (not just the group elements). The non-isolated case seems hard with canvas.
          Knockout and isolation can be solved in script if we define the API’s correctly and people believe that there’s value in the feature.

          I’n unsure where you concern of CORS stems from. clip-to-self seems unnecessary for blending but it’s possible that I’m missing something.

          Interesting that you bring up filters. This was also brought up on the canvas mailing list today.

          We can continue the conversation on this blog, or we can take it to public-canvas-api@w3.org so other people can chime in.
          I will see if I can find some time to add blending in Canvas to the compositing/blending spec.

    • April 05, 2012 at 4:36 pm, BrianMB said:

      DilMat, that is a great suggestion!

  9. April 07, 2012 at 9:15 pm, Mark Hurrell said:

    Diverging slightly from what you’re proposing, it would be great to also have some way to allow users to interact with elements beneath the blending layer. Maybe something like a display:filter property.

    Used in combination with your blending proposal, it could allow a simple way to create low/high-contrast variants of a design for users with visual or cognitive impairments (in the same way these filters work http://www.crossboweducation.com/Eye_Level_Reading_Ruler.htm)

    • April 09, 2012 at 7:23 pm, Rik Cabanier said:

      Unfortunately the movie is restricted so I can’t watch it but I think I understand what it’s doing.
      The reading ruler from that article definitely acts like a colored layer with CSS blending applied. (It’s not simply opacity.)

      Having the ability to ignore interactivity and pass it to underlying elements sounds a lot like pointer-events (see http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty) which is available to SVG elements.
      I can see how you could implement this feature with CSS blending, pointer-events and a bit of JavaScript.

  10. April 09, 2012 at 3:16 pm, John Nack on Adobe : Adobe’s working on blending modes for HTML said:

    [...] okay then: now Adobe’s helping bring Photoshop-style blending modes to HTML. The work can enable more beautiful, flexible pages & higher fidelity hand-off from [...]

  11. April 10, 2012 at 4:59 pm, Adobe vuole portare i metodi di fusione di Photoshop nell’HTML5 | Total-Photoshop Magazine said:

    [...] I metodi di fusione di Photoshop  (normale, dissolvi, moltiplica, sovrapponi, etc..) grazie ad una semplice regola CSS potrebbero far parte della nuova generazione di attributi e proprietà delle immagini   che inseriremo nei nostri siti web. La cosa è ancora in fase di sviluppo ma ci sono buone prospettive grazie alla semplicità di introduzione e alle modifiche già pronte per webkit, il motore che fa funzionare browser come Chrome e Safari. Come funzionerà nella pratica? Guardate queste due righe di codice: <div style="background: url('gradient.jpg');">    <img style="blend-mode: overlay;" src="url('dj.jpg')"/> Tutto qui. I dettagli, per chi ha voglia di smandruzzare contenuti in inglese, li trovate sul blog del team di sviluppo. [...]

  12. April 10, 2012 at 7:55 pm, Adobe Wants to Have Photoshop-style Blending Modes Built Into HTML/CSS said:

    [...] Bringing blending to the Web (via John Nack) [...]

  13. April 11, 2012 at 11:35 am, Adobe Wants to Have Photoshop-style Blending Modes Built Into HTML | I Need Coffee said:

    [...] Bringing blending to the Web (via John Nack) [...]

  14. April 23, 2012 at 9:26 pm, Blending CSS Gradients Like Photoshop | Jonathon Hill said:

    [...] CSS blending modes would solve this, but they aren’t here yet (you can do it with the HTML5 Canvas API, but that’s messy). [...]

  15. May 02, 2012 at 4:53 pm, thinsoldier said:

    div style=”background: url(‘gradient.jpg’);”
    img style=”blend-mode: overlay;” src=”url(‘dj.jpg’)”

    What if I didn’t want to use an IMG element?

    What if instead I used the Multiple Background Images feature. Could I still apply a blending mode to one of the background images?

    • May 02, 2012 at 4:55 pm, Rik Cabanier said:

      Blending will apply to any element such as , , etc so it doesn’t need be an image.

      The spec has a draft proposal to allow blending between the layers of your css box.

      • May 02, 2012 at 5:11 pm, thinsoldier said:

        I’m not referring to blending multiple html elements. I’m referring to blending multiple css background layers applied to a single element.

  16. June 15, 2012 at 5:34 pm, craig said:

    would this work for css shadows? I usually dont want to apply many blending modes to backgrounds (although i do occassionally on gradients) or images… What my primary interest in this proposal is about is the possibility of having blending modes that i can apply to inset and regular box-shadows and text-shadows.

    stuff like this:
    box-shadow: 0 1px 4px overlay #ff0000, inset 0 1px 1px screen #fff;

    would help out immensely!

  17. June 20, 2012 at 10:49 am, Paul d'Aoust said:

    Very important, and necessary, I think! There are currently ways we can hack it with a bunch of math — actually, right now I’m working on this very thing for the Stylus CSS preprocessor. Of course, my doesn’t work at all for textured foregrounds or backgrounds — only solid colours. So it’ll be really nice to have this implemented in browsers!

    I also see that in your spec, blending modes are implemented for background, foreground, box-shadow, and text-shadow — and border is being contemplated also. Very relieved to see, because it’d be nice to be able to set the blending mode of each of these independently in some situations, rather than setting the blending mode on the entire box (which is useful in most situations).

  18. July 02, 2012 at 3:28 am, Adobe: Web standards match 80 percent of Flash features | WestPenn Journal said:

    [...] up: Blend modes and DRM Drawing again on its Flash experience, Adobe also has proposed “blend modes” for Web graphics. Offered for years in Photoshop and Illustrator, Blend modes offer a variety of ways of overlaying [...]

  19. July 02, 2012 at 4:12 am, Adobe: Web standards match 80 percent of Flash features | Partners In Sublime said:

    [...] up: Blend modes and DRM Drawing again on its Flash experience, Adobe also has proposed “blend modes” for Web graphics. Offered for years in Photoshop and Illustrator, Blend modes offer a variety of ways of overlaying [...]

  20. July 02, 2012 at 4:18 am, Adobe: Web standards match 80 percent of Flash features | The Website Guru said:

    [...] up: Blend modes and DRMDrawing again on its Flash experience, Adobe also has proposed “blend modes” for Web graphics. Offered for years in Photoshop and Illustrator, Blend modes offer a variety of ways of overlaying [...]

  21. July 02, 2012 at 4:35 am, Adobe: Web standards match 80 percent of Flash features | Dubai News|Dubai Hotels|Dubai Business said:

    [...] up: Blend modes and DRM Drawing again on its Flash experience, Adobe also has proposed “blend modes” for Web graphics. Offered for years in Photoshop and Illustrator, Blend modes offer a variety of ways of overlaying [...]

  22. July 02, 2012 at 6:56 am, Adobe: Web standards match 80 percent of Flash features - Latest Technology - News & Articles said:

    [...] up: Blend modes and DRM Drawing again on its Flash experience, Adobe also has proposed “blend modes” for Web graphics. Offered for years in Photoshop and Illustrator, Blend modes offer a variety of ways of overlaying [...]

  23. July 02, 2012 at 10:23 pm, Adobe: 80 Prozent von Flash sind heute mit Webstandards umsetzbar | silicon.de said:

    [...] aktuelle Adobe-Vorschläge für das Web der Zukunft sind Mischmodi: etwa Bilder, die die Flächen innerhalb von Buchstaben ausfüllen. Auch einen Kopierschutz hat es [...]

  24. July 03, 2012 at 12:46 pm, Adobe: Web standards match 80 percent of Flash features said:

    [...] up: Blend modes and DRM Drawing again on its Flash experience, Adobe also has proposed “blend modes” for Web graphics. Offered for years in Photoshop and Illustrator, Blend modes offer a variety of ways of overlaying [...]

  25. July 06, 2012 at 5:22 pm, Adobe: Web standards match 80 percent of Flash features - Magazine Design Software said:

    [...] up: Blend modes and DRM Drawing again on a Flash experience, Adobe also has due “blend modes” for Web graphics. Offered for years in Photoshop and Illustrator, Blend modes offer a accumulation of ways of [...]

  26. July 12, 2012 at 5:35 pm, martyfmelb said:

    Of concern to me is the apparent lack of linear blend modes (linear dodge/burn/light). Are all of the given blends going to be calculated in linear colour space or the “native” colour-space? (For Photoshop users, this is the difference between gamma 2.2 and gamma 1 in your colour settings.) Considering colour-space issues are very important for “realism” in rendering. Firefox gets it right with its SVG filters: its blur filter looks brilliantly natural!

    • July 12, 2012 at 7:07 pm, Rik Cabanier said:

      They are all going to blended in device color space just like in Flash, PDF, Illustrator and Photoshop. Looking at the underlying implementations in FireFox and WebKit, they are also not linearizing the colors.
      I have asked people on the Photoshop team about the color setting for gamma and they told me that that feature is almost never used (and even when it’s turned on it is sometimes ignored by the application on purpose).

      You are correct that the additional Photoshop blend modes are not part of the spec. Do you believe they should be? We’ve been focusing on the ones in the PDF spec since that is what the existing SVG spec was trying to implement.

    • July 16, 2012 at 6:21 pm, Rik Cabanier said:

      Also, the ‘linear’ keyword doesn’t mean that the blend mode happens in linear space. Linear dodge is just a slightly different version of the color dodge formula

  27. July 18, 2012 at 8:39 am, bt77 said:

    please oh please oh please oh PLEASE keep this up!!! i don’t want to hear anymore negative nay sayers – this is innovation, and that is a good thing. as a visual designer who works in interactive, i’ve been talking to my team of developers about wanting blending modes in css for the past year or more. i will be SUPER excited when you guys succeed at getting it just right and get the W3C to adopt it, b/c i know you will! God speed!

  28. May 27, 2013 at 6:32 pm, Erik Veland said:

    Any progress on this? Experimental implementations?

    • May 27, 2013 at 7:43 pm, Rik Cabanier said:

      yes!
      Blending in Canvas has landed in WebKit, Chrome Canary (behind a runtime flag) and Firefox.
      Blending in background images has landed in WebKit and Chrome Canary (behind a runtime flag).

      We have a patch for blending between element for WebKit and are discussing how to implement this with the Chrome people