Surfin' Safari

Co-written by Beth Dakin and Mihnea-Vlad Ovidenie

CSS regions are an exciting technology that make it easier than ever to create rich, magazine-like layouts within web content. Regions have been under development in WebKit for a while now, and we’re delighted to tell you that they are available for use in Safari on iOS 7, Safari 7 on Mavericks, and Safari 6.1 on Mountain Lion.

Magazine-like layout

So I wrote this little article for my personal blog:

That’s cool and all, but wouldn’t it be so much cooler if it had a more interesting layout like this?

So fab! Without regions, achieving a layout like this is a pain. You have to figure out exactly which parts of the article can fit into each box and then hard-code the article content into the appropriate boxes. And after all that work, the design will get totally messed up if the user changes the font size! The layout looks cool, but doing it this way is a lot of work, and it isn’t even a little bit flexible.

Regions make achieving this layout as easy as pie. They allow authors to indicate that some sections of content are intended to define an overall layout template for a portion of the document and that other sections of markup represent the content that is intended to fill that template. The semantically-related content that will flow through the template is called a “named flow.” In our example above, the named flow is the text of my article. Once it has been named, the named flow is distributed into disjointed containers called regions, which can be positioned in any way to achieve the desired layout.

Our simple example only scratches the surface of what you can do with regions. We’ll get to more sophisticated applications later, but first let’s take a closer look at the code.

What is a named flow?

A named flow is a collection of HTML elements extracted from the document’s normal flow and displayed separately. Any HTML element can be part of a named flow. When an element is collected in a named flow, all of its children are collected with it.

You identify a collection of HTML elements as a named flow by using the CSS property -webkit-flow-into. In our example, the named flow will be the elements that contain the text of our article:

<style>
    #flow-content { -webkit-flow-into: pizza-manifesto; }
</style>
<div id=”flow-content”><h1>Pizza is amazing</h1>...</div>

Our example only has one, but a document can have any number of named flows, each with its own name.

Flowing into regions

A region is a block-level element that displays content from a named flow instead of its own content. Regions can have any size and can be positioned anywhere in the document. They are not required to be siblings or to be positioned next to each other in the layout.

A region consumes content from a single named flow. Most of the time, to achieve an interesting layout, there will be more than one region associated with a named flow, and when that is the case those regions form a region chain. When content from a named flow does not fit into a region, the content simply flows into the next region in the chain.

Making an element a region is as easy as adding the -webkit-flow-from CSS property. In our example, the regions are the elements that form the layout template for the document’s overall design:

<style>
    .region { -webkit-flow-from: pizza-manifesto; }
</style>
<div class="region" id="region-1"></div>
<img src="pizza.jpg" width=512 height=342>
<div class="region" id="region-2"></div>
<div class="region" id="region-3"></div>
<div class="region" id="region-4"></div>
<div class="region" id="region-5"></div>

Take a look at the code for the actual document to see the code for the regions side-by-side with the code for the named flow.

One key thing to remember about regions is that they are only visual containers. Region elements do not become the DOM parents of the elements flowed inside them; they only establish the bounding boxes that visually constrain the flow content.

Advanced regions features

One cool feature in the CSS Regions specification is region styling. With region styling, a designer can style the content based on which region it ends up flowing through. For example, if you wanted to change the color of the text displayed in the second region of the article flow, you could do so with region styling:

<style>
    @-webkit-region #region-2 {
        p { color: green; }
    }
</style>

The extra styles are dynamically applied behind the scenes whenever the layout of the article content in the regions changes. So for example, if the user resizes the browser window and different pieces of content end up flowing through the styled region, the content will update dynamically. At this time, you can only style regions with the CSS properties color and background-color, but we intend to progressively add support for more properties, so stay tuned! In the meantime, check out this version of our article that uses region styling.

There is also a whole object model available for interacting with regions and named flows from within JavaScript. The proposed API will make it even easier to create fluid designs that adapt to layout changes. For example, authors can use the API to determine whether or not there are enough regions to display the content from the named flow. Handy stuff!

Dreaming with regions

CSS regions are powerful, and when they are combined with other advanced CSS features like shapes, filters, flexible boxes, transforms, and media queries, incredibly sophisticated designs can emerge.

Back in February, during a CSS regions pattern rodeo hosted by CodePen, Tyler Fry and Joshua Hibbert created some awesome regions demos. Tyler won the contest with his reading carousel made out of regions and transforms, and Joshua created an exploding book, featuring a nice hover effect when opening the book.

The Adobe WebPlatform team has created some very compelling demos with regions in partnership with National Geographic. Check out this article that seamlessly integrates text and photographs to create a flexible design. Adobe has also created a demo that is so cutting edge you will need to download a WebKit Nightly to view it properly. This beautiful prototype uses regions, so the article content breaks up automatically across the different containers, and if font size or window size changes, or if the user zooms in, everything reflows automatically. Check out the source code here!

We are so excited about regions as a technology and excited that they are already available for use in shipping browsers. We plan to continue to refine our implementation in WebKit and to add additional features, so be sure to check back for improvements.

I am happy to announce that as of r155146, we now require our various ports to build with compilers that support some C++11 features. This means that we don’t need to use the COMPILER_SUPPORTS() macro to conditionally use these features anymore. These are:

• Type inference
• Static assertions
• Move semantics

We’ve chosen these three features because they are well-supported in recent versions of the compilers we use: clang, MSVC and GCC.

What does this mean for people writing code? Here are three code examples where these three features come in handy:

Type inference

Type inference using the auto keyword will automatically deduce the type of a variable based on its initializer. This is especially useful iterators. This loop:

HashMap<OriginStack, OwnPtr<ExecutionCounter> >::const_iterator end = m_counters.end();
for (HashMap<OriginStack, OwnPtr<ExecutionCounter> >::const_iterator iter = m_counters.begin(); iter != end; ++iter) {
    ...
}

becomes

for (auto it = m_counters.begin(), end = m_counters.end(); it != end; ++it) {
    ...
}

Unfortunately, the new range-based for syntax is not supported by all compilers, but this is definitely a step in the right direction.

Static assertions

static_assert is a way to declare compile-time assertions. If an assertion is false, the compiler will produce an error. WTF already has a COMPILE_ASSERT macro that provides this functionality, but static_assert produces better error messages.

COMPILE_ASSERT(sizeof(AtomicString) == sizeof(String), atomic_string_and_string_must_be_same_size);

gives the error

/Source/WTF/wtf/text/AtomicString.cpp:43:1: error: 'dummyatomic_string_and_string_must_be_same_size' declared as an array with a negative size
COMPILE_ASSERT(sizeof(AtomicString) == sizeof(String), atomic_string_and_string_must_be_same_size);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /Source/WTF/wtf/text/AtomicString.cpp:23:
In file included from /Source/WTF/config.h:62:
In file included from /Source/WTF/wtf/FastMalloc.h:25:
In file included from /Source/WTF/wtf/PossiblyNull.h:29:
/Source/WTF/wtf/Assertions.h:324:60: note: expanded from macro 'COMPILE_ASSERT'
#define COMPILE_ASSERT(exp, name) typedef int dummy##name [(exp) ? 1 : -1]

Whereas

static_assert(sizeof(AtomicString) == sizeof(String), "AtomicString and String must have the same size");

gives

/Source/WTF/wtf/text/AtomicString.cpp:43:1: error: static_assert failed "AtomicString and String must have the same size"
static_assert(sizeof(AtomicString) == sizeof(String), "AtomicString and String must have the same size");
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Move semantics (rvalue references and move constructors)

Move semantics can provide improved performance when passing objects by value by moving the data instead of copying it. What it means for WebKit is that we can stop using out parameters in functions that return Vectors. For example:

void HTMLFormElement::getNamedElements(const AtomicString& name, Vector<RefPtr<Node> >& namedItems)
{
    // http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-form-nameditem
    elements()->namedItems(name, namedItems);

    HTMLElement* elementFromPast = elementFromPastNamesMap(name);
    if (namedItems.size() == 1 && namedItems.first() != elementFromPast)
        addToPastNamesMap(toHTMLElement(namedItems.first().get())->asFormNamedItem(), name);
    else if (elementFromPast && namedItems.isEmpty())
        namedItems.append(elementFromPast);
}

becomes

Vector<RefPtr<Node>> HTMLFormElement::namedElements(const AtomicString& name)
{
    // http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-form-nameditem
    Vector<RefPtr<Node>> namedItems = elements()->namedItems(name);

    HTMLElement* elementFromPast = elementFromPastNamesMap(name);
    if (namedItems.size() == 1 && namedItems.first() != elementFromPast)
        addToPastNamesMap(toHTMLElement(namedItems.first().get())->asFormNamedItem(), name);
    else if (elementFromPast && namedItems.isEmpty())
        namedItems.append(elementFromPast);

    return namedItems;
}

(Note that this may have been true in the past in some cases too, due to the named return value optimization), but now it’s safe to do this for all Vectors with a zero inline capacity as well as HashMap and HashSet too!

Move semantics is an interesting topic that I hope to cover further in another blog post, so I’ll only mention it briefly here.

One more thing

Astute readers may have noticed another C++11 feature in the previous example that we can now use. With C++11 there is no need to use a space between right angle brackets when closing template arguments lists! This means that

OwnPtr<Vector<RefPtr<Node> > > m_childNodes;

becomes

OwnPtr<Vector<RefPtr<Node>>> m_childNodes;

Personally I’m really excited about using these features and I think they will be useful throughout the codebase. In time we’re going to start requiring even more C++11 features but this is a good start.

About a month ago, I had a moment of clarity and started converting WebKit code to using references instead of pointers when passing around objects that are known to exist. At first I was just playing around, but it gradually got more serious and other people started chipping in patches too.

Darin suggested I write this blog post to clear up any confusion there might be about why/when to use references, so let’s cut to the chase! There are two main reasons for using e.g Frame& instead of Frame*. Reason number one:

It documents that we are referring to an existing Frame object, and that it’s safe to call member functions on it.

Compare this example:

// WebKit in 2012, so gaudy!
return m_page->mainFrame()->eventHandler()->mousePressed();

..to this:

// WebKit in 2013, so fab!
return m_page.mainFrame().eventHandler().mousePressed();

In the old version, it’s not clear that m_page, mainFrame() and eventHandler() are non-null. In fact, you’d need a pretty good understanding of the WebCore object model to know which pointers could be null and which ones couldn’t. It was typical for functions to be littered with checks like this:

if (!m_page)
    return false;
if (!m_page->mainFrame())
    return false;
if (!m_page->mainFrame()->eventHandler())
    return false;

…which brings me to reason number two:

It exposes unnecessary null checks by turning them into compile errors.

C++ doesn’t let you null check references, so you have no choice but to remove them. This is awesome, because it means smaller and faster code, both binary and source wise. The CPU doesn’t have to spend time checking if the object is really there, and you don’t have to spend time worrying about what to do if it isn’t. Everyone wins!

So when should you be using references?

• If you were going to return a pointer, but you know it will never be null, make it a reference!
• If you take a pointer argument, but you don’t want to handle it being null, make it a reference!
• If your class has a pointer member that never changes after construction, make it a reference!
• BUT if your code has a RefPtr<Frame>, note that switching to a Frame& would no longer ref/deref the Frame, which may not be what you want!

My dream is that one day, if I see a -> or a *dereference, there will also be a null check in the preceding lines (or a comment explaining why it’s safe to dereference.) This may not be entirely realistic, but let’s see how far we can get.

WebKit now supports the srcset attribute on image (img) elements (official specification from the W3C). This allows you, the developer, to specify higher-quality images for your users who have high-resolution displays, without penalizing the users who don’t. Importantly, it also provides a graceful fallback for browsers that don’t yet support the feature.

See the new feature in action. Note that you’ll want a recent nightly build of WebKit. I’ve also included part of the demo inline below.

As you may know, WebKit has supported the -webkit-image-set CSS function for more than a year now. It lets CSS properties that take images provide a list of candidate image urls, each with a modifier such as “2x”. This allows the browser to chose the best image for the user’s device. Before this feature, if you wanted to support high-resolution displays you had a few options, each with some downsides. You could duplicate your CSS. You could use JavaScript to query the device pixel ratio and update image resources after the page has loaded, possibly triggering multiple image loads. Or you could hard-code a higher-resolution image and thus penalize some users who were downloading more data than necessary. And if you were providing images of different resolution, there was the added pain of specifying related CSS properties such as the background-size or slices for border-image. It was annoying. Thankfully -webkit-image-set solved this by allowing you to write one simple rule and have the browser do the work of deciding which image to use and therefore which to download. (Hmmm… maybe -webkit-image-set deserves its own blog post! )

The srcset attribute on img is very similar to -webkit-image-set. In fact, you can think of it as the markup equivalent to the CSS feature. Like the list of candidate images in -webkit-image-set, you add a new attribute srcset to your image elements. It’s designed to be backwards compatible: browsers that don’t support the attribute ignore it, and continue to use the src value. Meanwhile, browser engines such as WebKit can look at the srcset and decide which image best suits your user’s device. In most cases you won’t need anything more than this:

<img src="normal-image.jpg" srcset="better-image.jpg 2x">

Notice the “2x” after “better-image.jpg”? That tells the browser that if you’re on a display with two or more device pixels per CSS pixel, it should use “better-image.jpg” instead of “normal-image.jpg”. And if you’re not on a high-resolution display, the browser will fall back to the value specified in src. You can also specify another candidate for 1x displays in srcset (as shown in the example).

You can read more about srcset in the official specification. Note that at the moment WebKit only supports the resolution modifiers (e.g. 1x, 2x, 3x). As with any new feature in WebKit there may be bugs, so please be on the lookout for anything that doesn’t behave as expected. In particular, you should verify that WebKit is downloading the minimal resources for a page, because that’s one of the goals of this feature.

Special thanks go to WebKit community members Romain Perier and Yoav Weiss who made important contributions (r153624, r153733) to this feature.

User visible changes

Sam Weinig removed the JavaScript APIs for Microdata. Microdata failed to gather support from both authors and engine developers. The removal of the APIs had been proposed on webkit-dev and got unanimous support.

Timothy Hatcher modified the rendering of SVG images onto <canvas> to allow the canvas to remain untainted in some cases. Specifically, if an SVG image does not embed foreign content (e.g. HTML), rendering in onto a canvas will not taint the canvas. Any foreign object in the SVG still cause the canvas to be tainted.

And some less dramatic changes:

• Simon Fraser tweaked the algorithm that sends fake mouse events to speed up scrolling further. If a page’s event handlers start misbehaving and take more than 10 milliseconds to process an event, the engine throttles the fake events to one per 250 milliseconds.
  It is worth repeating the usual word of warning: web page event handlers should always be well written or the user experience suffers.
• Andreas Kling improved the performance of inserting rules into an empty stylesheet with JavaScript.
• Christophe Dumez killed DOMImplementation::hasFeature() (following the specification). Calling hasFeature() now always returns true for anything but SVG. Authors are expected to use direct features detection through their JavaScript APIs instead of using hasFeature().
• Christophe Dumez also changed window.atob() to throw an exception if there are too many padding characters. Previously WebKit would silently ignore the characters.
• Rob Buis made the SVG property stroke-dasharray animatable. With this change, you can use CSS Transitions to animate the pattern of dashes used when stroking paths.
• Jer Noble added support for MediaKeys.isTypeSupported. This is part of the Encrypted Media Extensions APIs. This particular API lets the runtime ask the browser if a certain Key System is supported.
• Alex Christensen enabled WebGL by default on the WinCairo port.
• Bruno de Oliveira Abinader made the CSS properties text-decoration and text-decoration-line non-inherited, following the specification.

Engine changes

• Antti Koivisto made a nice change to the architecture by removing style recalculation from the responsibilities of Element. Instead of having Node and Element perform the style update, this is now done through standalone functions acting on the API of Element.
• Mark Rowe added support for MallocStackLogging to FastMalloc, which makes debugging memory problems heaps easier on Mac OS X and iOS.
• Tim Horton fixed the rendering of composited images with EXIF orientation.
• Renata Hodovan fixed yet another bug discovered by her fuzzer.
• Andreas Kling updated many functions to return a reference instead of a pointer when the object returned cannot be null by design. This kind of changes make refactoring and reviews a lot easier.

Any questions? Suggestion for the blogs? Chirp our way to @awesomekling and @awfulben.