Web Platform Team Blog

Making the web awesome


Today we’re proud to announce the launch of a new team website:

The site provides a new view into the team’s wide range of projects. We lay out a welcome mat to draw visitors into each project, then lead them to more detailed information, like what we share in blog posts.

Our mission is to create a more expressive web. With this new site, we want to connect new forms of expression with their enabling technology in a way that speaks to all web creatives. By putting design use cases front and center, we hope to feed a discussion that includes designers, developers, standards gurus, browser implementors and casual creators of apps and websites.

Like teams everywhere, we do a lot of research and project work that mutates into something totally different, or gets abandoned for other, more valuable, efforts. These are valuable lessons, which we will increasingly share on both the website and this blog. Feedback on what we’re not doing can be just as valuable as feedback on what we are doing!

Thanks for joining us on this next experiment. We’re excited to hear your responses and suggestions. Post your thoughts on the new website in the comments below or on Twitter: @adobeweb.

Posted in News | Comments Off on Announcing

Event: Evolving the Design Palette for the Web, 9/18

At the heart of it, the Adobe Web Platform team is an engineering organization. We address problems designers have when they bring their ideas to the web. We’re keenly interested in areas where designers have had to compromise their ideas due to limitations of the web platform. This informs the new work we take on and existing work we’re doing.

Next week, we’re hosting a special event to engage designers, begin to understand their design limitations and start the process of working together to solve them. We’re pleased to have a guest speaker Michael Janiak, Creative Director at Fluid. Following Michael’s talk will be drinks, a DJ, and casual conversations about evolving the web together.

If you’re a designer and will be in San Francisco, please join us on September 18 at the 111 Minna Gallery. Space is limited, so register now:

CSS Shapes Editor for Chrome

With the release of Chrome 37, CSS Shapes are enabled by default for everyone to use.

To make it easier for you to work with the new feature, there is now a CSS Shapes Editor for Chrome. This Developer Tools extension adds an interactive editor for shapes right in the browser. Learn more about it and watch a quick video demo of the editor in action on my blog post.

edit polygon shape

Editing a polygon path using the CSS Shapes Editor for Chrome

Standalone CSS Shapes Editor

The Chrome extension uses the same editing surface as the CSS Shapes Editor extension for Brackets. We think that’s practical and useful, so yesterday we also released the editing surface as a standalone CSS Shapes Editor on GitHub. As a developer, you can now integrate the shapes editor into your own tools, demos and interactive presentations.

CSS Shapes now available in Chrome 37 release

Support for CSS Shapes is now available in the latest Google Chrome 37 release.


What can I do with CSS Shapes?

CSS Shapes lets you think out of the box! It gives you the ability to wrap content outside any shape. Shapes can be defined by geometric shapes, images, and even gradients. Using Shapes as part of your website design takes a visitor’s visual and reading experience to the next level. If you want to start with some tutorials, please go visit Sarah Soueidan’s article about Shapes.


The following shapes use case is from the Good Looking Shapes Gallery blog post.

Without CSS Shapes
With CSS Shapes

In the first picture, we don’t use CSS Shapes. The text wraps around the rectangular image container, which leads to a lot of empty space between the text and the visible part of the image.

In the second picture, we use CSS Shapes. You can see the wrapping behavior around the image. In this case the white parts of the image are transparent, thus the browser can automatically wrap the content around the visible part, which leads to this nice and clean, visually more appealing wrapping behavior.

How do I get CSS Shapes?

Just update your Chrome browser to the latest version from the Chrome/About Google Chrome menu, or download the latest stable version from

I’d like to thank the collaboration of WebKit and Blink engineers, and everyone else in the community who has contributed to this feature. The fact that Shapes is shipping in two production browsers — Chrome 37 now and Safari 8 later this year — is the upshot of the open source collaboration between the people who believe in a better, more expressive web. Although Shapes will be available in these browsers, you’ll need another solution for the other browsers. The CSS Shapes Polyfill is one method of achieving consistent behavior across browsers.

Where should I start?

For more info about CSS Shapes, please check out the following links:

Let us know your thoughts or if you have nice demos, here or on Twitter: @AdobeWeb and @ZoltanWebKit.


The CSS Regions specification is currently supported by Internet Explorer 10+ and Safari (OSX and iOS). Though generally very close, the IE implementation was based on an earlier draft and works differently. In particular, the source of a named flow – the elements you apply the -ms-flow-into property to – must be iframe elements. This approach has some benefits: it allows the use of content from any source, including cross-domain content, with all the security benefits of an iframe. The standard specification, however, chose to limit named flow content to the current document using any element type.

This makes using CSS Regions in both environments slightly challenging. Since the WebKit implementation is easier to use – no iframes needed – and reflects more recent spec drafts, we attempted to write a JavaScript library that would let a region chain authored for Safari work in IE. The result is iframeflow.js.

How It Works

iframeflow simply generates the iframe required by IE and copies named flow content to the iframe document. It can either do so automatically by scanning the page’s stylesheets for named flows; or it can create an IE named flow from an arbitrary selector.


Of course, this library only helps in IE. To emulate CSS Regions across browsers, you should use the CSS Regions polyfill. But if your iOS app uses Regions in a WebView, iframeflow.js could help you produce a Windows 8 app with the same content.

Other known limitations include cross-domain stylesheets (their object model is off-limits). If the style of elements in your named flow depends on their ancestry – e.g. because they match child or descendant selectors – this styling may no longer apply in the iframe document. Other constraints are listed on the project page.


The source code is available on GitHub. Please let us know if you have any feedback. You can do so through GitHub issues, on this blog, or via twitter @adobeweb.

Coming Soon: CSS Feature Queries

Feature Queries are part of the CSS3 Conditional Rules specification, and offer a native method of testing for CSS feature support. You can use Feature Queries to test whether certain CSS rules are supported, and optimize your page for the available set of features. Feature Queries have a number of stable browser implementations in Chrome, Firefox, and Opera, and at least one recent experimental implementation in WebKit. As browser support continues to increase, it’s probably worth taking a look to see if Feature Queries fit into your current projects.

Feature Queries in CSS

Feature Queries look like Media Queries, but test support for CSS property/value pairs rather than display characteristics. As a basic example, you could ask a browser to apply a set of CSS rules if it supports a value of 0 for the margin property.

@supports (margin: 0) { /*CSS to apply*/ }

Let’s move on to a more realistic example. Let’s say you want to use background-blend-mode to colorize a background image, multiplying a color tint over the original grayscale image.

See the Pen Feature Queries + Blend Modes by Adobe Web Platform (@adobe) on CodePen.

body {
  background-blend-mode: multiply;
  background: linear-gradient(rgb(59, 89, 106)
                , rgb(63, 154, 130))
              , url(background.png);

Altogether a great effect, right? However, browser support is a bit of a pain. background-blend-mode has relatively wide support, but there are also a good number of browsers where you will not see the correct result. To address non-supporting browsers, we will lay down a base set of functionality – an approximation using a semi-transparent color overlay.

body {
  background: #3F9A82;
  background: linear-gradient(rgba(59, 89, 106, 0.8)
                , rgba(63, 154, 130, 0.8))
              , url(background.png);

The above code includes a single-color fallback if the semi-transparent color overlay isn’t supported. Then, using a feature query, we can conditionally update the background if background-blend-mode is supported. A feature query looks just like a media query, using @supports and adding the CSS declaration to be tested inside parentheses.

@supports (background-blend-mode: multiply) {
  body {
    background-blend-mode: multiply;
    background: linear-gradient(rgb(59, 89, 106)
                  , rgb(63, 154, 130))
                , url(background.png);

Feature Queries in JavaScript

The Feature Queries specification also provides a JavaScript interface: CSS.supports. We can take the above example, and test for support using JavaScript. If background-blend-mode: multiply is supported, we can add the blend-mode class to the <body> element.

See the Pen Feature Queries + Blend Modes (JS) by Adobe Web Platform (@adobe) on CodePen.

window.onload = function() {
  if (CSS.supports('(background-blend-mode: multiply)'))
body.blend-mode {
  background-blend-mode: multiply;
  background: linear-gradient(rgb(59, 89, 106)
                , rgb(63, 154, 130))
              , url(background.png);

As one further trick, you can also combine tests using logical operators and, or, and not. For example, if you wanted to test that the background-blend-mode and background property values were both supported, you could use either of the following:

@supports (background-blend-mode: multiply)
          and (background: linear-gradient(...), url(...))


CSS.supports('(background-blend-mode: multiply) \
              and (background: linear-gradient(...), url(...))');

Feature Queries are almost ready for primetime development. When considering whether to use them, just make sure that they are available in the same browsers as the features you are testing for. Although Feature Queries won’t make the headache of feature testing go away, they will hopefully make the problem a bit more manageable. Try it out, and let us know what you think.

One Weird Trick to Baseline-Align Text

I’m writing this post because I hope I’m wrong. I have found a silly solution to a common typographic problem, and I hope there’s a better way to do what I want.

The problem is baseline-aligning text. I want to position a character’s baseline at a particular spot, in a way that works with all browsers, fonts and font sizes. The reason I want to do this is for drop cap positioning. A drop cap should have its baseline aligned with the lowest line of regular text it’s next to. I can estimate where that baseline is, so the trick is figuring out how to get the drop cap’s baseline to match.

Let’s simplify the problem. Say I have a 100x100px div with a border. The div contains a span with a single letter, and I want the baseline of that letter to sit on the bottom edge of the border.

div {
  width: 100px;
  height: 100px;
  border: thin black solid;
span {
  font-size: 100px;
  line-height: 100px;
  background-color: #9BBCE3;

I’ve started with a font-size and line-height of 100px. This won’t do what I want, because in CSS line-height is measured from the ascender to the descender. You might think (as I initially did) that all I’ll need to do is find the descender height and use a margin to make the text sit down on the border. The descender height will vary from font to font, so whatever solution might have to be font-specific.

But I quickly found that not only is the baseline position dependent on the font, it also varies by browser. Here’s the result of the above in Firefox, Chrome and IE:

Default letter 'T' rendered in Firefox, Chrome and IE

Firefox, Chrome and IE rendering

Firefox and Chrome are both on MacOS using the same font, but the baseline is much higher in Firefox than Chrome. IE is using a different font file for the default font, but manages to match Chrome in this instance. At this point I thought there might be a bug in Firefox, or that I might just need to conjure a Firefox-specific offset to get cross-browser baseline alignment.

But it’s not as simple as that. The variations in browser baseline positioning are compounded by font changes. Here’s the result with font-family set to Adobe Garamond Pro (the same font file used in each browser):

Garamond letter 'T' rendered in Firefox, Chrome and IE

Firefox, Chrome and IE rendering

Here Firefox and Chrome are merely one pixel apart, and IE has decided to go its own way. I tried a few other fonts and found a mishmash of results – the browsers do not agree on where to place text baselines, and have no pattern across fonts that I could discern. Dealing with descender height in order to place a baseline at a particular point appears both font-specific and browser-specific in a way I couldn’t untangle.

By the way, I originally added the background-color to the span to see if that would illuminate why the results were so different. But as you can see that’s another cross-browser inconsistency. Chrome isn’t even consistent with itself on the extent of a span’s background when I change the font. This is a separate issue, and not terribly relevant to the baseline alignment problem.

So, what to try next? I know from past experience that inline images use the bottom edge of the image as the baseline. Perhaps there’s something useful about replaced elements or inline blocks that I can exploit. It turns out that if I add an empty inline-block strut to the div, I can use it to position the baseline for the entire line.

  <span class="letter">T</span>
  <span class="strut"></span>
div {
  width: 100px;
  height: 100px;
  border: thin black solid;
.letter {
  font-size: 100px;
  line-height: 0px;
  background-color: #9BBCE3;
.strut {
  display: inline-block;
  height: 100px;

The baseline of the strut is placed at its bottom margin edge, which is determined solely by the height of the strut in this case. And if the letter span’s line-height is smaller than the strut’s height, the letter’s baseline will move to match. Here I’ve set the line-height of the letter’s span to 0px to make sure it’s smaller. You can check out the result in any browser in this pen (try changing the font and/or the font-size):

The strut has to be empty. At first I had no idea why, but my colleague @sgalineau found the reference in the very last sentence of the CSS 2.1 section on line height. There’s a special case for an inline-block with no line boxes that gives us this useful result.

As I mentioned, my specific reason for all of this was drop cap positioning, but there are plenty of other reasons to want to align a text baseline to something else. Is this inline-block strut trick the best we have to work with in CSS? Can someone show me a better way? If so, leave a comment here or contact me at @adobeweb and/or @alanstearns.

CSS Regions and Selectors


The CSS Selectors system is the driving force behind the stylesheets of a Web page. The selector of a rule defines what elements or pseudo-elements get to be styled using that rule. The selectors language has advanced a lot lately and it allows a lot of complex constructs using tag names, ids, classes, pseudo-classes and so on.

An important part of the language are the combinators which define relations between two selectors. The Editors Draft of CSS Selectors Level 3 lists four combinators:

  • the descendant combinator (E F)
  • the child combinator (E > F)
  • the following-sibling combinator (E ~ F)
  • the next-sibling combinator (E + F)

There’s a general forward direction in the DOM tree when combining selectors. There is no “parent” or “ancestor” combinator. However, the CSS Selectors Level 4 draft defines the :has pseudo-class that’s supposed to fill in that role. The major limitation of this pseudo-class is that browsers are not supposed to implement it for dynamic selectors, just for cases that don’t impact performance too much, such as the Document.querySelector function.

To understand why :has is a problem if used for rule definitions let’s see how browsers actually do selectors matching. A browser doesn’t start with the rule and try to determine what elements must use that rule. It’s the other way around. The browser knows the element it needs to style and then it evaluates each selector from right to left, eliminating rules that don’t match. In the case of a combinator, once the right side was validated using the element, the browser then recursively verifies if the left side can be matched against the corresponding elements for that type of combinator. For example, the child combinator will use the parent of the element and the following-sibling combinator will verify all the previous siblings of the element to find a match. If all the selectors in the combinator match, the rule is used for the element.

This algorithm is efficient because most of the rules are usually eliminated in the early stages of the matching process. Also, when styling an element, only the ancestors and the previous siblings of the element matter. The :has pseudo-class complicates these rules. The elements matched by :has need to track all the changes in their DOM subtree that can enable or disable the rule. When misused, the :has pseudo-class can easily lead to document wide style invalidation and major performance degradations.


How CSS Regions can help in this situation? One of the interesting properties of CSS Regions is that content collected in a named flow can be rendered in regions located anywhere inside the document as long as cycles are avoided. This means that you can write stuff like this:

<div class="content"></div>
<div class="region"></div>

.content {
    flow-into: flow;
.region {
    flow-from: flow;

This code will display the content element inside the region element. In this situation, a rule with a .content + .region selector will actually behave like a parent selector. It will style the box containing the content.

I think this is especially powerful when dealing with interactivity. For example, the :hover pseudo-class is constrained by the selector rules. You can’t hover an element on a page and apply an effect to another element unrelated (not a child or sibling) to the first one. With regions this limitation can be avoided:

  1. Place the element to be hovered (A) as a previous sibling of the element you want to be styled (B).
  2. Add a region in the page and flow B inside it.
  3. Write a next sibling combinator rule between them A:hover + B and B will be styled even though it’s not rendered as a sibling of A any more.

Here is an example that better demonstrates the feature in Safari 7+:

Check out this Pen!

You can also add both elements to a flow thread and use forced breaks to split them in two different regions. This technique is used in the following example that works in Internet Explorer 10+:

Check out this Pen!


Feel free to experiment with this idea and bring new ones to the table. We’re always looking for ways to improve the Web Platform and empowering users to achieve the effects they want is a priority.

Lean Experiment: Overlay Effects

A very popular design trend on the web in recent years has been various forms of overlay effects, e.g., using large visual media (images, video) as a background and overlaying text on top of it using different techniques to create contrast between the content and the graphics. We see this in the form common UI elements – menu dropdowns, popup windows, stylized web site design, and really, everywhere it can be. Perhaps its foundation came from some native OS aesthetics introduced some time ago and have more recently become more ubiquitous, if not controversially so. As we spoke to web professionals about these trends, one person thought this design paradigm is so popular because it is “just so visually seductive.” makes liberal use of several of these overlay effects, resulting in rich and visually stunning design. makes liberal use of several of these overlay effects across its site.

As the charter of the Adobe Web Platform team is to Make the Web Awesome—specifically, by making a more expressive web—we’ve been looking into these types of effects and how we might make them better, easier to create, and more beautiful. With the work that we do on this team, we’re in a unique position to listen to our customers, take what we learn from them, and improve the Web to better enable them to be expressive and creative.

The Lean Experiment

At Adobe, we’ve recently adopted the also very popular Lean Startup Methodology. Teams across the company from Engineering to Marketing have been using it to inform decisions on virtually all aspects of the business. When examining these overlay effects to determine if there was anything we at Adobe could do to help, my colleague Bear Travis and I conducted a Lean Experiment. We did not have a particular solution in mind, but rather were using this methodology to identify and/or define the problem.

We began our exploration looking at only the frosted glass effect made popular by iOS 7. We quickly discovered a cluster of similar overlay effects and expanded our experiment to include frosted glass, blurred backgrounds, gradient fades, image tinting, and transparency overlays.

Tinted image, Newton Running. Transparency overlay, Veer. Blurred background, Dego Interactive. Gradient fade, FMK Catering

During our research phase, Bear also wrote an article on CSS Tricks on how to achieve some of these effects using CSS filters. As we looked at many examples on the web of these effects, we noticed that people were creating them in many different ways. Some achieved the effects with web technologies such as CSS opacity, filters, and linear gradients. We noticed that many others were making edits directly to the images themselves. In an effort to understand why people used so many different methods, especially those who used non-web solutions, we formed our experiment around this.

The Hypothesis

After coming up with our list of assumptions about how people are using these effects, we came up with the following hypothesis to test:

“Web creative professionals do not use some overlay effects because they are difficult to reproduce on the web.”

We will know this is true when:

  • Respondents say they had to alter their visual / overlay effect designs to suit what was possible / easy to do on the web.
  • Respondents dismiss some effects for technical rather than aesthetic reasons.

The Method

The main method we used to test our hypothesis was a series of interviews with Web professionals, from designers to developers and everything in between. Each kindly agreed to give us an hour of their time. The interviews consisted of a set of open-ended questions, designed to allow responses to go in any direction that could lead to new learning. In addition to the questions, we had visual examples of each of these effects that we showed interviewees around which to ask more specific questions. For the visual examples, we used variations of the pelican demo in Bear’s article on CSS Tricks.


The Results

The Lean Experiment measures results in two ways – quantitative and qualitative.

The quantitative results were unanimous: of all the people we interviewed, none responded that the web platform’s capabilities prevented them from creating the overlay effects they wanted.

The qualitative results could be summarized as follows:

  • Large visuals, including as backgrounds, were seen as a popular trend on the web. Some were attracted to the trend while some wanted to break away from it.
  • Web designers and developers were happy with the current set of overlay effects because they were familiar, easy to create, and known to work (performance, accessibility, and compatibility being the primary concerns).
  • It is unclear whether web creatives would use a different set of effects if they matched the same criteria, but it is clear that they are not actively searching or thinking about different effects.


Because we revealed no compelling information to pursue further in this area and since none of the people we interviewed seemed to express any difficulties in using these effects, we were able to prove our hypothesis false. This research shows that web professionals are able to do all the overlay effects they want to do. However, we believe that over time they’ll want to do other things that they may not be able to or may only be able to do using new emerging features. This is why we’ll remain interested in the issue, even though we see nothing actionable right now. We’d still certainly be interested in hearing more on this topic and could be willing to re-open the investigation, but for now we are satisfied that that there is not a current problem here that would require a more uniform solution.

If you have opinions or input on this topic, please let us know by taking a few minutes to complete our quick survey. If we gather more information to cause us to revisit this, we can then contact you to discuss your ideas further.

Fading effects using blend modes

Fading effects are quite common on the Web today. They are used to display or hide an HTML element or to change an element into another element, gradually.

Fading transitions are pixel-by-pixel blends between an HTML element (the source element) and either the element behind it or the color in the background. A solution based on animating the opacity property is used to make the source element more or less transparent so that the background element becomes more or less visible, thus simulating the desired effect.

The Compositing and Blending spec describes a new way to blend an element with the content behind it by using the mix-blend-mode property, which can be enabled on stable versions of Chromium, Firefox and Opera, and will soon be officially supported in Firefox 31 and Safari 8.

A blend mode is a formula used for mixing source and background colors. This mix of source and background prevents animation using CSS animations or CSS transitions. However, when the content is generated by a CSS property such as color, background-color, or background-image: radial-gradient(...), we can animate the value of this property, and the animated content will be used in the blending operation.

Let’s assume we have an image we want to display or hide using a fade effect. If the initial background is white, we can use the screen or lighten blend mode. That’s because applying a screen or lighten blend mode on white produces white and applying a screen or lighten blend mode on black leaves the image unchanged. So if we animate the background color from white to black the image is displayed; and if we animate the background color from black to white the image disappears. Similarly, when starting from a black background, we can use the multiply or darken blend mode.

In the example below, I use the darken blend mode combined with a simple transition from white to black on the background-color to hide the image. For more interesting effects, you can generate arbitrary colors between the initial white and the final black by animating the background-color property using CSS animations. Move the mouse over the images to see the difference between the mix-blend-mode based effect (on the left) and the opacity-based effect (on the right). For the image on the left, notice the parts with bright colors start fading away sooner than the area with dark colors.

Check out this Pen!

We can use this technique as an alternative to creating grayed-out or inactive content. To accomplish this effect, we need to use a background color that acts as an identity operator and doesn’t change the result of the blend mode.

  • Black doesn’t change the result for screen, lighten, difference or exclusion.
  • White doesn’t change the result for multiply or darken.
  • Gray (#808080) doesn’t change the result for hard-light or overlay.
  • A transparent background doesn’t change the result for any blend mode.

The codepen below demonstrates the hard-light blend mode combined with a background transition from black to gray (the first row), compared to opacity based fading (the second row).

Check out this Pen!

Here is another example using the color-burn blend mode and a background-color transition from slategray to transparent:

Check out this Pen!

If the content you want to blend is a color and one or more images, you can get the same effects using background-color, background-image and background-blend-mode – all set on a single div. The background-blend-mode property is officially supported starting with Chrome 35, Firefox 30 and Opera 22.

My design skills don’t do Blend Modes justice, so I can’t wait to see more cool samples using this feature. Please share yours here or on Twitter.