Building the Web of Tomorrow

A Case Study

About Me

Software engineer on the Web Engine team at Adobe

About You

Regions

article {
    flow-into: article_flow;
}
#region1, #region2,
#region3, #region4 {
    flow-from: article_flow;
}

Exclusions

.circle {
  wrap-flow: end;
  shape-outside: circle(50%, 50%, 50%);
  shape-margin: 10px;
  shape-inside: shape-outside;
  shape-padding: 10px;
}

Regions and Exclusions

illuminated manuscript example — http://www.historyhappenshere.org/node/6840

* You can think of regions and exclusions as complementing each other. * While regions define the positive areas content should fill, exclusions define the negative space content should avoid. * While these ideas may sound fancy and new, it turns out they've actually been around for a while. * For example, here is a 15th century illuminated manuscript. * You can see that there is one continuous stream of content, flowing into two regions and avoiding this one fish-shaped exclusion. * You can also go one step further, and say that a book's content flows across the pages of the book, which define content areas.

magazine layout example — http://www.flickr.com/photos/alexanderwolf/2452809327/

Regions Demo

A Princess of Mars

Exclusions Demo

A Princess of Mars

Before they were standards

http://www.alistapart.com/articles/sandbags

Let's make it a standard

Agreed upon behavior
Consistent browser implementations

* Now these workarounds might get the job done, but they are just that, workarounds. * Some folks at Adobe encountered these same problems when trying to do rich magazine-style layout on the web. * And, rather than fight with these problems with client-side technologies, they figured, why not implement them in the browser? * And to make that happen there are two important pieces of work that need to happen. * First, of course, everyone has to agree on what the standard should be. * The feature needs to be specified. * Second, of course, you need to be able to use it. * Which means it needs to be implemented consistently across browsers.

The Goal: A W3C Recommendation

Feature specification
Two different browser implementations
Test suite

* The W3C is a group responsible for guiding web specifications forward. * There is a well-defined review & development process, whose end result is a recommendation. * The recommendation defines the feature specification as a technical standard. * It's what browsers should implement if they want to support a feature. * But while the specification may sound theoretical, it also requires two browser implementations as a practical review. * A recommendation also requires a test suite to determine if a browser implementation qualifies as implementing the feature. * We'll continue to talk about this process, just keep note of this as our end goal.

Getting the ball rolling

Step 1: Idea

A complex layout may have several areas that are chained: when the first one fills up, the rest of the text flows to the second, etc. For example, a newspaper often has one small column of a story on the front page, and then the rest on other pages.

W3C List of Suggested Extensions to CSS - Dec 10, 1998

Step 2: Exploration

Well-defined problem
Web-appropriate solution
Vendor interest

Step 3: Proposal

Draft specification
Functional prototype

* In order to officially start the W3C review process, you need to have something that is ready for review. * Officially, this means a specification draft, outlining how the feature should behave. * Because both of these features are in CSS, they fall under the purview of the CSSWG. * Adobe also chose to create a functional prototype, in WebKit, to better demonstrate how the features would work and how useful they could be. * It is easier to demonstrate an idea to the working group, rather than describing it. * May go through several iterations before moving forward. For example, the regions and exclusions spec was split into two different specs. source: http://wiki.csswg.org/planning/japan-2011

Step 4: Acceptance as Working Draft

The Evolving Specification

Working Draft

Candidate Recommendation

Recommendation

* Regions and Exclusions are currently in the Working draft stage. * The goal of the working draft stage is to generate a specification that is ready for implementation and testing across multiple browsers. * Formally, when the specification is ready enough, it goes through a last call for comments, and then becomes a CR. * Moving is like handing a paper in for publication. It can be accepted, or returned for further work. But you don't get to change the actual submission. * A CR is when the spec is ready for implementation and testing. * After two working browser implementations, a spec may move from CR to R. * Theoretically, the WD stage does not require any implementation. * From our experience, however, the only way to know your specification can be implemented in browsers is to implement it.

Specification Implementation

Shape Inside Overflow

Overflow Proposals

* The exclusions specification did not originally detail what should happen to content if it is too large for its shape-inside. * The spec editors knew about the issue, and had filed a bug to resolve it (which included a suggested algorithm). * However, when we started working on shape inside, we realized we needed to implement it pretty early. * And, having implemented parts of shape-inside, we had some ideas about what might work best. * We proposed a couple solutions in the case of overflow: * Push all overflow outside the shape * This didn't seem optimal to us, because content would appear to vertically "jump" outside the shape on the last line. * Use the width at the top of the line. * This, again, didn't seem optimal. The line would overflow the shape horizontally. * Use the width remaining in the shape * We recommended option 3 because it made the text continuous, but still generally respect the bounds of shape-inside.

Regions OM

interface Region {
    readonly attribute DOMString regionOverset
        throws DOMException;
    readonly attribute DOMString flowFrom
        throws DOMException;
    sequence<Range>? getRegionFlowRanges()
        throws DOMException;
    CSSStyleDeclaration getComputedStyle(Element elt);
    CSSStyleDeclaration getComputedStyle(Element elt, 
        DOMString pseudoElt);
};
Element implements Region;

* Sometimes you find a couple surprises as well. * Regions included some OM work to make it accessible to JavaScript. * For a region, regionOverset lets you know if the content is overflowing the region chain. * Flow from gave you the named flow a region was pulling content from. * getRegionFlowRanges gave the offsets into the content that this region contained, and * getComputedStyle gave the computed style for content within the region. * Initially, these were added to all elements that could become regions. * But we thought there was no valid value for these if the elements were not regions, and * so we thought throwing an exception would be best.

var element = document.getElementById("region1");
try {
    /* handle region cases */
    switch(element.regionOverset) {
        case "overset":
        case "fit":
        case "empty": break;
    }
} catch (err) {
    /* handle non-region case */
}

var element = document.getElementById("region1");
/* handle all cases */
switch(element.regionOverset) {
    case "overset":
    case "fit":
    case "empty":
    default: break;
}

var element = document.createElementById("div");
for (var property in element) {
    console.log(property + ":" + element[property]);
}

Regions OM (Updated)

interface Region {
    readonly attribute DOMString regionOverset
        throws DOMException;
    readonly attribute DOMString flowFrom
        throws DOMException;
    sequence<Range>? getRegionFlowRanges()
        throws DOMException;
    CSSStyleDeclaration getComputedStyle(Element elt);
    CSSStyleDeclaration getComputedStyle(Element elt, 
        DOMString pseudoElt);
};
Element implements Region;

W3C Recommendation Requirements

Feature specification
Two different browser implementations
Test suite

Contributing to WebKit, Made Easy

Step 1: Get the code

http://www.webkit.org

Step 2: File a bug

shape inside bug — https://bugs.webkit.org/

Step 3: Build and test a fix

Step 3: Upload a patch

Step 4: Solicit feedback

#webkit on irc.freenode.net | webkit-dev@lists.webkit.org

* Feedback comes in multiple forms. * First, for large issues, you need to communicate with the webkit community in general. * They're available via IRC and the webkit mailing list. * So, for example, it's important to announce something like a new feature being implemented, and be responsive to general feedback. * Sometimes, folks take a little convincing. * Secondly, code has to be approved by a webkit expert, called a reviewer, before being accepted into WebKit. * These experts specialize in different areas of WebKit as well. * This patch introduced new architecture, and was therefore subject to a higher degree of scrutiny. * And that's a high bar, code going into Webkit is already handled very cautiously. * ~10 people with expertise in layout, and only 3 or 4 who were active and felt qualified to review the patch. * This patch is ~550 lines, ~200 lines of functional code, with the rest being comments and tests. * 10 rounds of review, 24 patch submissions, 6 weeks months from initial patch to submitted code. * Subsequent patches, just extending / fixing functionality can take a couple days to a week. * Small patches can be turned around same day.

Lessons Learned

Patch reviews take time
Make patches small and modular
Respect your reviewer's time & feedback

* First, be patient, reviews take time. * Because every line is scrutinized during review, it's important to keep code surface area low. * The simpler the patch is, the easier it is to review and get it through the process. * Reviewers are busy and have other duties. They're going to offer loooots of feedback (like "please make your comments full sentences and punctuate appropriately") * But, if they're giving you feedback, they're helping you towards getting the code submitted. * They also might think something should be different, and they're often right. They are, after all, experts. * Make sure a patch is always ready for review before asking it. For me, I always want a patch to be as ready for submission as possible. * For example, always write tests. If a patch doesn't have tests, it's going to be one of the first things a reviewer notices. * The goal should always be to submit a patch that's ready for acceptance, because getting reviews can require so much effort.

New Feature Rollout

Source Code

Nightly Builds

Experimental Channel

* All of that work may seem a little extravagant for submitting a simple patch. * After all, all it added was some very simple functionality for a new feature. * But, it actually does some pretty cool things. * Because the bar for the source code is so high, it speeds up the rate at which it is released to users. * First, the WebKit source code is built every 24 hours and released as a nightly build. * These builds, though, are still mainly for development testing. * A couple browsers, including Chrome, have different release channels, which demonstrate browser features at different levels of polish. * These channels are targeted more towards web developers, with the goal of balancing what's new against what's stable. * For Chrome, there is an experimental channel called Chrome Canary. * Chrome Canary updates daily, so when you use it, you know you really are using the bleeding edge. * The cool thing about these experimental builds is, pretty much as soon as code goes into WebKit, we can say * "You'll see it tomorrow in Canary". * The experimental channel also runs in parallel to Chrome, so you can use Canary to test out new features without messing with daily browsing in Chrome. * Firefox has the Aurora channel, and Opera has Opera Next.

Stable Channel

* From there, code eventually makes its way into the stable channel, your general public browser. * For Chrome, a major release cycle is about 6 weeks. * In Chrome, experimental code can still make it into one of these releases, as long as it is flagged as an experiment. * Meaning, you have to manually enable it as an "experimental feature" from Chrome flags. * This is really cool, because code we put into WebKit will be available in your everyday Chrome browser (albeit flagged), on a 6 week release cycle. * This may sound a little WebKit heavy, but that's because I'm giving one specific implementation example. * Whatever your browser, there's a pretty good chance it's doing some cool new tricks and it's showing them off at a faster clip. http://www.impressivewebs.com/release-history-major-browsers/

Standards, Browsers & You

When will they be ready for me to use?

How ready do you need them to be?

Regions in Chrome/IE
Exclusions in Chrome/IE
Regions polyfill coming soon!

* And my question for you is: how ready do you need them to be? * The specifications will take a while to get to recommendation, as the W3C process is designed to be exacting. * Something proposed as a standard should be rock solid. * But, the specifications and implementations are continuously moving forward, AND * Browsers are continuously rolling out new functionality. * Which gives you the opportunity to pick it up at the right point for your needs. * With polyfills and tools like Modernizr, it's possible to implement it now and slowly transition to native implementations. * If you remember how I opened the presentation, people have wanted these features badly enough that they work pretty hard to get them. * Regions and Exclusions are both partially implemented and available to the public. * Regions is ready for experimentation in release builds of Chrome. * Shape-inside is ready the adventurous in Canary builds of Chrome. * Both have to be enabled via chrome://flags. * Both also have partial functionality enabled in IE 9.

Get Involved

Build cool stuff
Grab an experimental build
( CR | FF | IE | O | S )
Test drive a new feature
Read & comment on a specification
( W3C | WhatWG | Ecma )
Join the conversation

The End

bear_travis