Web Platform Team Blog

Making the web awesome

September 2014 Extensible Web Summit

A month ago I attended the second Extensible Web Summit, held this time in Berlin. I blogged about the first one back in April. Hopefully we’ll see more of these events in the future. All of the sessions were collaboratively minuted, so you can read through the notes and see what was discussed.

What is the Extensible Web?

The first main session was a conversation about just what an extensible web means. There has been a lot of talk about exposing underlying primitives in order to make features less magic and more extensible. I made the point that the word primitive can be a trap. It’s not always the lowest-level primitive that needs to be exposed for extensibility. Sometimes the best strategy is to provide a relatively high-level API underneath an even higher-level feature (as long as the API we expose now does not preclude going deeper in the future).

As an example, take some proposed CSS wizardry like float:bottom. We could provide a high-level feature like this with nothing more than an API to set a new ‘bottom’ keyword. Or we could delve the depths of layout mechanics and box trees to expose the primitive mechanisms from which this high-level feature could be implemented from the ground up. I don’t think either extreme is a viable approach. The highest level feature isn’t adaptable enough to be extended to new use-cases. And the lowest-level delving is way too much effort to build out one new feature.

There’s lots of room between the extremes. Analyzing the magic behind a high-level feature can help desribe a slightly lower-level feature, and you can add APIs for the next level down. It might turn out that grid layout gives enough expressive power to solve the use cases for float:bottom, while providing the necessary adaptability for similar use cases. And it might make sense to provide a bit of introspection into the details of grid layout, so that script can refine a responsive grid in ways difficult to express declaratively in CSS. Iterating on features in this way gets us closer to the lowest level primitives at each step.

Getting Developer Input

One main reason for these events is to bring developers together with standards people and browser implementors. The web needs input from the people using the platform to set priorities and evaluate proposals. One session at this event was a discussion on how to get more developer input in web standards. Robin Berjon described some of his efforts that will bring discourse-style forums to

It turned out that quite a few developers at this session had worked (separately) on the difficulties of providing a good editing environment on the web. This is an area with a lot of current interest in the standards community. Hopefully the connections made at this conference will lead to a clearer set of editing APIs focused on the needs of these developers who have already put so much effort into this problem.

Remote Debugging

I had brought up the topic of a common debugging protocol at the first summit. This time I got to meet Kenneth Auchenberg, who is behind (the site that sparked my interest in the topic). We talked a bit about what Mozilla has been doing mere minutes before they announced their new debugging add-on that lets you use Mozilla tools when debugging on iOS and Chrome on Android. Kenneth just gave a presentation at Fronteers detailing other efforts around making web debugging more interoperable.

What’s Next?

The next Extensible Web Summit is tentatively planned for spring of next year in the bay area. Please consider attending if you’re near by. Sign up at specifiction and add your ideas on where the web platform should go. And please provide feedback on what we’re doing on the Web Platform Team at Adobe.

Evolving the Design Palette for the Web: Event Recap

On September 18, the Adobe Web Platform team held a great event at the 111 Minna Gallery in SF. We called the event Evolving the Design Palette for the Web and invited designers from all over the Bay Area.

We were lucky to start the evening with a fantastic guest speaker, Michael Janiak, Creative Director at Fluid. Michael ignited the crowd with his talk on the current state of designing for the web (see his slides here). He noted that the first 25 years of the web were technology-driven and now the next 25 years will be expression-driven. In other words, the way the web evolves will be determined by creative aspirations of designers, not developers. His talk ended with a Call to Action for designers stop compromising on their creativity, engage with teams like ours at Adobe, and more generally, have their voices be heard within the open web community.

Michael’s talk was followed by drinks & a DJ and a lot of mingling where we met a lot of designers and started to learn about the challenges they face. While our team had many conversations that evening, some of our key takeaways were:

  • Designers are frustrated and feel disenfranchised
  • Animations on the web are very difficult
  • Fonts & text rendering and layout is a challenge on the web
  • Faster execution is often a limiting factor, not necessarily whether something is technologically possible
  • Designers rely heavily on tools and look to them to help solve difficult problems

We’ll to continue to engage the great group of people we met that evening and with the broader design community. We are doing this to inform the current and future work we’re doing, and to advocate for designers who are compromising when bringing their creative ideas to the web. If you’re a designer who is as passionate as you are frustrated with the web today, let us know what challenges you face! Feel free to mail us directly at

Drop Caps Are Beautiful

As a design pattern that predates movable type, initial letters or “drop caps” remain quite common in books and magazines today. They can be merely decorative, they can help navigation by emphasizing the beginning of a new section, or both. Yet they seem comparatively rare on the web and are even more obviously missing in most e-books.

What is missing?

Though CSS offers the basic layout mechanisms needed for initial letters – floats and ::first-letter – the solution is incomplete. For the result to be visually appealing, a drop cap has to align with its adjoining text in a specific way. The diagram below shows how the baseline of the capital “H” should rest on a baseline of the adjoining text; and how, in the most common case, the top of the H should align with the top of capital letters in the first line.

Through careful adjustment of various properties – font-size, height, margin, line-height… – one can achieve a similar result in CSS. There is a catch: the resulting set of layout values will be tightly coupled to the metrics of a specific font family. If font fallback occurs, the alignment is lost. Any change to the original page design – new font size, a change of paragraph line-height – will also require updating all these values.

As an example, here is an initial letter in the online New Yorker:

Dropcap set in Neutraface

Drop cap set in Neutraface

Though this capital “I” is a little short – its top is lower than that of the capital “U” in ‘Utah’ – its baseline does line up well with the third line of text. But if the preferred Neutraface family does not load and the browser falls back to the next specified family, we would see this when the layout defined for Neutraface is instead applied to Helvetica Neue:

Screen Shot 2014-09-16 at 12.57.49 PM

The same page after font fallback to Helvetica Neue.

Often, no baseline alignment is even attempted. For instance, in this Vanity Fair article the baselines of the initial letters do not line up with those of the adjoining text. Dave Cramer collects more examples on his tumblr.

The initial-letter property

To fix this, the CSS Working Group is discussing the initial-letter property specified by Dave in the CSS Inline Layout module (The alignment diagram we used earlier was copied from the specification). Since earlier this month, you can try it out in Webkit Nightly.

It is very exciting to have a native implementation to play with, though there is of course more work to do to finalize the feature design and implement it across browsers.


In the meantime, we thought we would try to lay out drop caps using JavaScript and CSS. The result is dropcap.js.  Using a single line of code you can specify the height of your drop caps and which baseline they should line up with. The project’s built-in demo page will let you play with common font families and some sample text. For instance, a four-line high drop cap set in Baskerville with text in Times New Roman:

Screen Shot 2014-09-17 at 10.59.01 AM

The library and its source code are available on GitHub. Let us know what you think on this blog or via @adobeweb on Twitter.

CSS Regions: Moving further with iOS8

On September 17th 2014, Apple released iOS8 which included the new Safari 8, featuring improved support for CSS Regions. We take this opportunity to highlight the most important changes from the previous version:

Correct painting of content overflowing the region chain
We completely redesigned the way overflowing content is displayed in regions. Starting with Safari 8, the content is no longer clipped at the region’s content box, but properly overflows the region. Furthermore, using position:relative on the flowed content doesn’t affect the way it is fragmented across the region chain.
In Example 1 below, if you hover the orange button, you will notice that using position:relative on the content causes it to overflow the regions and be properly painted.

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

Example 1

Improved scrolling of content in regions
You can now set the last region in the chain to overflow:scroll. In such cases, the last region will properly scroll its content. When the scrolling limit is reached, the scroll effect is applied to the region’s container. We created the codepen in Example 2 so you can test this behavior by scrolling the right most region. Besides this, we ensured the scrollIntoView method now works as expected.

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

Example 2

Improved rendering performance for content inside regions
With the new Safari, the HTML content requiring hardware acceleration (e.g. video) is rendered using the GPU even when displayed inside regions. This way, if you use CSS Regions for your design, you will not incur any performance penalty.

Flowing fixed positioned elements into regions
With the new release, position:fixed elements flowed into regions are spec compliant. They are now correctly sized and positioned relative to the viewport and not the first region in the region chain.

Improved, fully spec compliant selection
Thanks to the collaboration with our colleagues from Igalia, we managed to improve the way selection of content displayed in regions works. You are now able to combine in a single selection content from a region chain and from outside the region chain. Of course we ensured that, even when combined with CSS Regions, selection is still spec compliant, following the DOM selection. For more information, we highly recommend the blog post from Igalia developer Manuel Rego Casasnovas.

WebInspector integration
The WebInspector received some great new features for helping developers use regions. As you can see in Example 3, one of the most obvious additions is the highlighting of the entire region chain and providing information about the flow thread when hovering one of the regions.

Regions WebInspector sample

Example 3

These are the major changes related to CSS Regions that you’ll find in Safari 8. We hope you enjoy using regions as much as we enjoyed building it and we’d love to hear your opinion in the comments section below or on our twitter account.

Blending HTML elements in Safari and Firefox

In June 2014 at the Worldwide Developer Conference, Apple announced that Safari 8 would ship with support for CSS Blending. With the recent release of iOS 8, you can now use blend modes on your Apple mobile devices! OS X Mavericks users who update Safari to version 7.1 can also start experimenting with this new feature. And this is not the only good news: Firefox recently enabled the mix-blend-mode CSS property by default in version 32, released on September 2, 2014.


Safari and Firefox are the first browsers to ship the CSS Blending feature! These implementations are based on the CSS Blending specification – which has reached W3C Candidate Recommendation status. There are a few remaining work items to be completed in these two browsers: the non-separable blend modes in Safari and the CSS isolation property in Firefox.

Chromium also has a complete implementation of the CSS Blending specification: the background-blend-mode property is supported by default, while mix-blend-mode and the CSS isolation property are available behind the experimental features runtime flag. You can play with the full implementation of blend modes in Chromium-based browsers (Chrome and Opera) by enabling this flag.

Want to know more about CSS Blending? The Adobe Web Platform Team’s website contains additional information about this feature, along with a list of useful resources that will allow you to create compelling visual effects using blend modes.

Please share your thoughts and experiences regarding CSS Blending in the comments here, or on Twitter.

Happy Blending!

Safari and Opera join Chrome in shipping CSS Shapes

The last few weeks have been exciting for CSS Shapes. At the end of August, Shapes shipped in Chrome 37. Then in early September, Opera 24 also shipped with support for Shapes. And now, iOS 8 just launched with Shapes support in Safari! Also, support for OS X versions of Safari will be coming soon.

What is CSS Shapes?

CSS Shapes allows you to build layouts like this on the web. In this example, the text content wraps around the contour of the hanging-lamp and the wall (photo and demo by @ZoltanWebkit). The contour of the shape is defined by a polygon with the help of the CSS Shapes Editor. (Note that this example uses the CSS Shapes Polyfill, so it works in all browsers.)

See the Pen Hanging-Lamp, with polyfill by Adobe Web Platform (@adobe) on CodePen.

If you’re not familiar with CSS Shapes, you should definitely take a look at Shapes 101 article. More information and useful links can also be found on the CSS Shapes page.

But can I really use it now?

Yes! Even though Firefox and Internet Explorer don’t support CSS Shapes yet, you can use them today in production. In browsers that don’t support Shapes, you simply get the standard float wrapping behavior. For example, view the following demo in a browser that supports shapes and one that does not.

See the Pen Monsters, without polyfill by Adobe Web Platform (@adobe) on CodePen.

For cases where having the shape is essential, you can use the CSS Shapes Polyfill, which supports many of the use cases for CSS Shapes. The polyfill is smart enough to use the built-in Shapes functionality in your browser if that is available. For example, here is the previous demo with the polyfill enabled, so it will look great in browsers that support shapes and browsers that don’t. Most notably, if you compare the source of the two demos, you will notice that nothing needs to change but to include the JavsScript for the polyfill.

See the Pen Monsters, with polyfill by Adobe Web Platform (@adobe) on CodePen.

If you’re doing something more exotic, like emulating shape-inside, then you can use Modernizr — or when they are more widely supported, Feature Queries — to remove or modify the floats when CSS Shapes support isn’t present. The following example does just that.

See the Pen Emulating Shape Inside with Shape Outside, with Modernizr fallback by Adobe Web Platform (@adobe) on CodePen.

Make something cool

We hope you’re as excited about the availability of CSS Shapes as we are. Go out and play with it, and build great things! We’d love to hear about your experiences and the things you build in the comments here, or drop us a line on Twitter @AdobeWeb!


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

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.