Almost a year ago, Adobe began an effort to allow high quality, magazine style content to be displayed on the Web using the Open Web Platform (HTML5, CSS). Many of the necessary features were present in CSS, but not all necessary features were there. Adobe proposed CSS Regions as a draft specification of some advanced CSS layout features and a proof-of-concept implementation based on WebKit to the CSS Working Group during a face-to-face meeting (see the minutes).
At the time what we called CSS Regions included a fairly large set of features. Since then, we’ve taken this initial set of features through the first steps of the standardization process at the W3C. And we’ve made progress moving our demo code into WebKit proper. This blog post reviews what has happened in the last year and discusses our plans for the next few months.
CSS WG efforts
Separating features into modules
The first thing we found was that separating out some of the proposed features into smaller, more focused modules was easier to edit and seemed preferred by the CSS WG. So we separated the CSS Regions features from the CSS Exclusions features and produced two new specifications. In addition, we found that some of the issues around breaking content into Regions are also relevant to CSS Multicolumn Layout and CSS Paged Media. So these common issues have been placed in a new module called CSS Fragmentation.
To summarize, the original proposed features are now found in these three modules:
- CSS Regions includes named flows and region chains that allow for complex, magazine-style layouts.
- CSS Exclusions defines ways to flow inline content around and inside shapes that are either defined in CSS or extracted from content.
- CSS Fragmentation defines how content breaks between pages, columns or regions.
Working with co-editors
One of the greatest things that happened with this effort is the partnerships that built around this proposal. For example, Microsoft has worked as a co-editor for both CSS Regions and CSS Exclusions. In addition, they have taken the lead on the CSS Fragmentation work which they co-edit with Mozilla. We find working with co-editors extremely valuable because it improves the specification editing process and the preparation for the working group meetings and conference calls. For example, we work with the co-editors to keep the list of specification issues on CSS Regions up-to-date.
Of course, it is not just the editors who contribute to the specification, as the list of people in the acknowledgment section attests.
Both CSS Regions and CSS Exclusions have gone through many rounds of comments and improvements. Most of the feedback we’ve received has come from the www-style mailing list where all CSS specifications are discussed (people who want to comment on these specification drafts prefix their emails with “[css3-regions]” or “[css3-exclusions]“). We have also made extensive use of the CSS WG wiki and Bugzilla data base for working through and documenting proposed changes.
At TPAC 2011, the CSS working group had a discussion about the scope of regions and exclusions. The questions raised were about whether or not these modules had enough features to stand by themselves, or if more features were needed. In particular, some issues were seen as problematic:
- could regions be generated automatically to accommodate for more content or is it required for users to create regions before content is flowed (using scripts on declarative HMTL elements)?
- could regions automatically adapt to their content in the block direction (height for latin text)?
- is the model for exclusions creating circular dependencies? Should the exclusions model be clarified?
This led to an agreement at the follow-on CSS WG meeting in February (Paris) to:
- create a page template proposal to show how regions can be automatically created and used for pagination purposes.
- work on a proposed solution for height:auto region sizing.
- clarify the model for CSS Exclusions for each of the CSS positioning schemes.
In addition to the standards work above, we have been busy implementing these features in WebKit. Microsoft has also been implementing these features in IE10. While there has been a lot of progress (in both browser engines) these features are still cutting-edge and are protected both by vendor prefixes and run-time flags. Also, we are still working on interoperability between the WebKit version and IE. So while you can turn on CSS Regions in canary builds of Chrome, nightly builds of Safari, or try things out in the IE 10 Preview, don’t rely on what’s currently available for production yet: the syntax and feature set is still being discussed in the CSS Working Group. But it is a great time to start experimenting with the feature as Paul Irish did recently.
While Adobe had been using its own private branch of WebKit for a while, we are now contributing upstream to the main branch which has been new for us. We decided to start with CSS Regions and learn how to work properly with the WebKit community of coders and testers. By now we have almost all of the current working draft of CSS Regions implemented, and have started adding parsing code for CSS Exclusions.
Summary of where you can use CSS Regions today:
- Canary: CSS Regions implemented but disabled by default
- Chrome 19: CSS Regions implemented but disabled by default
- Chrome 17, 18: CSS Regions implemented and enabled by default
- WebKit Nightlies: CSS Regions implemented and enabled by default
- IE 10 Developer Preview: Implemented and enabled by default
Note that in Canary or Chrome, you can use the about://flags url to list all the optional features and turn regions support on or off (you need to restart the browser for the change to take effect).
Finally, we were very happy to see that Mozilla has added magazine-style layouts (and saying they may implement CSS Regions and CSS Exclusions) to their roadmap.
As new working drafts are officially published we will be updating the implementation to match. So what is going to change in upcoming working drafts? The next CSS WG meeting is in May, and we plan on having the following done in time for that meeting:
- Resolve all of the current issues logged for CSS Regions (or document competing proposals if the WG can’t resolve).
- Solve height:auto for regions. We have a proposal that we’re discussing with our co-editors and David Hyatt (the main contributor in the area of CSS layout in the WebKit project – David has been very helpful in our efforts to get started with WebKit: providing architecture and design guidance, implementing some parts himself and reviewing patches we submitted), and we are working on code to validate the proposal.
- work with our co-editor to improve the description of the CSS exclusions processing model and provide a specific step-by-step example.
Working with the Web community
The past year has been very enriching for our team. We have grown not only in size, but also in our ability to contribute to both the standard efforts and in the WebKit project.
Our goal with this effort is to help move the web forward, and to improve the CSS layout features available to content authors and web developers.
Having a specification subjected to the scrutiny of a group of experts and the community at large has been a healthy exercise. This process raises the hard questions and in the end makes the proposals better. We are also very intent on running our specification efforts and our implementation efforts in parallel, because we feel it improves the quality of the specifications as they have to sustain the test of implementability. We also want to work on the specification test effort early. We have not done as much as we would like there (even though we have started and have contributed to the CSS test suite), but we are planning to ramp up. Finally, we also want to continue building demos and proof of concepts to demonstrate the use of the new features we propose. Doing so provides a great test bed for both the usability of the specification and the quality of the implementation work.
So looking back over the past year of working on CSS Regions, it has been a fun road to drive. We are thankful for the feedback we have received from the community and our partners (in particular our co-editors) and we are thankful for the WebKit community support. We will post updates on these efforts after the next CSS Working Group face-to-face meeting in Hamburg in May 2012.
Vincent Hardy & Alan Stearns
CSS Working Group Members, Adobe Systems.