Adobe

decor

Web Platform Team Blog

Making the web awesome

CSS Shapes now available in Chrome 37 release

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

chromelogo

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.

Demo

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

Without CSS Shapes
the_11_guesses_no_shapes
With CSS Shapes
the_11_guesses_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 https://www.google.com/chrome/browser/.

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.

iframeflow.js

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.

Caveats

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.

Tinkering

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)'))
    document.body.classList.add('blend-mode');
}
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(...))

or

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>
  <span>T</span>
<div>
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.

<div>
  <span class="letter">T</span>
  <span class="strut"></span>
<div>
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

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.

Regions

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:

<br /><!--DVFMTSC-->&amp;lt;div<!--DVFMTSC-->&nbsp;class="content"<!--DVFMTSC-->&amp;gt;<!--DVFMTSC-->&amp;lt;/div<!--DVFMTSC-->&amp;gt;<br /><!--DVFMTSC-->&amp;lt;div<!--DVFMTSC-->&nbsp;class="region"<!--DVFMTSC-->&amp;gt;<!--DVFMTSC-->&amp;lt;/div<!--DVFMTSC-->&amp;gt;<br /><br /><!--DVFMTSC-->&amp;lt;style<!--DVFMTSC-->&amp;gt;<br />.content<!--DVFMTSC-->&nbsp;{<br /><!--DVFMTSC-->&nbsp;<!--DVFMTSC-->&nbsp;<!--DVFMTSC-->&nbsp;<!--DVFMTSC-->&nbsp;flow<!--DVFMTSC-->&minus;into:<!--DVFMTSC-->&nbsp;flow;<br />}<br />.region<!--DVFMTSC-->&nbsp;{<br /><!--DVFMTSC-->&nbsp;<!--DVFMTSC-->&nbsp;<!--DVFMTSC-->&nbsp;<!--DVFMTSC-->&nbsp;flow<!--DVFMTSC-->&minus;from:<!--DVFMTSC-->&nbsp;flow;<br />}<br /><!--DVFMTSC-->&amp;lt;/style<!--DVFMTSC-->&amp;gt;<br />

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!

Conclusions

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.”

MakersQuarter.com makes liberal use of several of these overlay effects, resulting in rich and visually stunning design.

MakersQuarter.com 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.

pelicans

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.

Conclusion

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.

Adobe Web Platform Round Up: coding, testing, tooling, and more

My team at Adobe exists to enhance the web platform. Adobe believes the web will become the ultimate platform for creative expression. We’re doing what we can to move the web towards that end. This takes several forms, including contributing open source code, contributing to web standards, and contributing to Adobe tools.

For the last few years, we have been fixing bugs and adding features to open source browsers – WebKit, Gecko and Blink. We’re aiming to increase browser compatibility and to increase the expressivity of the web platform. In addition to browser code, we work on open source projects that demo and polyfill new features for the web.

Along with sharing code, we work on web standards. We help edit the standards documents that say how a browser feature should behave. We write tests where needed and work on the test infrastructure at the W3C. And we help steward the Web Platform Docs effort to document the web platform.

Then we take the experience we’ve gained by diving deep into standards and browser code to move Adobe web tools forward. We offer advice on what new features to add, write code for internal and open source projects at Adobe, and have participated in an upcoming redesign of adobe.com.

Here are some quick highlights of our work from the first half of 2014. Follow any of the links for more in-depth information.

Shipping Code

Apple recently announced that Safari 8 will include both CSS Shapes and Compositing and Blending, two features our team worked on in WebKit. This is the second year in a row where the WWDC keynote mentioned our work. Last year, they shipped CSS Regions. Safari 8 will have an improved version of Regions as well (particularly in selection, thanks to a collaboration with a team at Igalia). But Safari isn’t the only browser where you can find our code.

CSS Shapes is also shipping in Chrome 37 (again, thanks to a collaboration, this time with a team at Samsung). Nearly all of Compositing and Blending is now present in current builds of Chrome and Firefox (with some finishing touches for Firefox hanging out in the beta channel, so they’ll be available soon). The clip-path implementations in WebKit and Blink have been updated to match the latest specification. And we’ve added a bunch of Canvas improvements (hit regions, Path2D, focus rings, etc.) to Firefox, Safari and Chrome.

We also fix bugs where we can. My favorite fixes from this year are a 10x improvement to compositing performance in WebKit, and a wide-ranging fix for viewport units in WebKit. We’ve been laying the groundwork for better filter support in Gecko, which has resulted in a number of bug fixes. Our engagement with the WebKit community resulted in two more reviewers from our team so far this year.

Polyfills and Demos

This year we have released a new CSS Regions polyfill that is more spec-compliant. We have also released a polyfill for CSS Shapes, so you don’t have to wait for every browser to catch up before trying it out. Our adobe-webplatform GitHub account has a lot of demos. Our CodePen has more examples and ideas we’ve shared.

Moving Standards Forward

We have been advancing W3C specifications both for the features where we work directly and other parts of the web platform we find interesting and useful. CSS Shapes and Compositing and Blending both made the Candidate Recommendation (CR) mark this year, which means the standards bodies think they’re ready to implement and test. CSS Masking is next up – it just went to Last Call, which is the step just before CR.

Our team has helped a few other specs move towards Last Call. Animations, Filter Effects, Canvas, Regions, and Baseline Grid all have been improved recently by our team members. A new Geometry Interfaces spec is in First Public Working Draft – its introduction to the standards process. We’re also working on adding better midpoints to gradient color stops, which was approved by the CSS and SVG Working Groups when we hosted their meetings at our Seattle office in January.

Testing

In the run-up towards shipping, we added a ton of tests to the W3C test suite for CSS Shapes. We added tests to several other suites as well (mainly around browser bug fixes we have been involved in). Rebecca Hauck (who now coordinates all of the CSS testing activities) recently checked in a massive refactoring of the entire CSS test suite structure. This will make it easier to integrate all of the CSS tests into the more general Web Platform Tests effort in the near future.

Tools

In addition to everything above, we also work with other teams in Adobe. We’re always looking for ways to improve the markup and CSS from all of our web tools. Brackets recently gained a shapes editor extension. SVG export from Illustrator CC has gone through a round of improvements. And we have a few more projects we’re currently working on that should be public soon.

What’s Next?

Expect more of the above over the next six months. We’ll continue to contribute to browsers and standards, and you’ll see more and more opened up in Adobe tools as features get widely implemented and interoperable. Keep up with this blog and our twitter account for news on what we’re currently working on (or considering leaping in to).

Background blending now available in Firefox 30

Last week, we announced that Chrome 35 was shipping background blend modes. This week, Firefox 30 was released with support for the background-blend-mode property. This makes it the second browser to add support.

Bennett Feely created some examples of gradients that have blending applied to them:

See the Pen Gradient with background blending by Adobe Web Platform (@adobe) on CodePen.


We’re excited that this feature is being adopted by more browsers! As always, let us know your thoughts or if you have interesting demos, here or on Twitter.

Improving Viewport Unit Support in WebKit

Viewport units are great for creating responsive designs. Unfortunately, issues with the WebKit implementation reduced their usefulness. A couple of months ago, I discovered that Timothy Loh had fixed many of the issues in Blink. Despite the size of the patch, it seemed like a prime opportunity to learn more about the CSS subsystem in WebKit and about viewport units in general. So, I took up the task to port the Blink fix over to WebKit. This turned out to be less than straightforward. In the year since Blink forked from WebKit there has been notable divergence in the structure of the CSS code. I ended up using the Blink patch as a guide and writing my own variant in WebKit. After a great number of revisions, the patch finally landed in WebKit about two weeks ago.

So, what works now?

The most obvious fix is that resizing now works. If you size an object with viewport units and then the user resizes the browser window, the object will resize as the window resizes. Prior to this patch, you would need to reload to get the resize to happen. This is an especially big boon for mobile web apps, since changing device orientation between landscape and portrait is simply a resize of the viewport. In addition, now getComputedStyle conforms to the spec and returns resolved pixel values for viewport units. This patch also makes it possible to use calc with viewport unit values. One of the demos from our shapes showcase clearly shows the resizing effect, as does our demo of positioning shapes with negative margins.

Animations and transitions with viewport units also didn’t work properly. In older versions of WebKit, the following example doesn’t animate, but in the latest WebKit nightly, it animates nicely.

See the Pen jpBxv by Adobe Web Platform (@adobe) on CodePen.

It is likely that other bugs have been fixed by this as well. Get the latest WebKit nightly and test it out for yourself. If you come across any more issues with viewport units that haven’t been fixed by this patch, please head over to bugs.webkit.org and file a bug! I would like to make the viewport unit support in WebKit as robust as it can be, and can only do that with your help.