Google plans to dump Adobe CSS tech to make Blink fast, not rich | Ars Technica

CSS Regions, integrated in the WebKit era, now up for removal.

Two of the 'net's big cats aren't getting along purrfectly right now.

flickr user: Gossamer103

Google's mission for 2014 is to make its Blink rendering engine faster and lighter on mobile platforms . To do this, it's planning not simply to improve the Blink code. The company is investigating the removal of its current (albeit disabled-by-default) support for CSS Regions , a specification that enables rich, magazine-like text layouts, and Google developers are now arguing that CSS Regions should not ship.

Google's position is that the Regions code is complicated, with some 10,000 of Blink's 350,000 lines of code being in some sense Region-related. Additionally, the code is not particularly self-contained. Google developer Eric Seidel argues that it's hard to reconcile this with Google's plans to improve performance, especially on mobile.

Seidel recognizes that Regions do address deficits in CSS's text layout capabilities, and he expresses the hope that Adobe can help find some simpler way to address these omissions.

Google's position is also supported by Blink contributor Opera, with Opera CTO Håkon Wium Lie arguing that Regions don't fit well with other aspects of HTML and CSS, such as responsive design. If a layout is too complex for simpler layout mechanisms (specifically, multicolumn), Lie believes designers should reconsider it anyway.

This decision has met with an unhappy reaction from Adobe, the company that did much of the coding and specification work for CSS Regions. Other supporters of the Regions spec are calling Google's behavior "draconian ".

Adobe argues that much of the complexity of CSS Regions is in fact necessary regardless of whether Regions are supported.

The Regions implementation brings together a couple of separate but related concepts. In the earliest days of HTML and CSS, the textual content within any element on a webpage would always be continuous and contained within that element. A box with text in it, for example, could not split into two boxes. CSS control over printed media changed this situation somewhat; one piece of text could be split across multiple pages and into separate boxes. Newer features have made this more complex. CSS Columns, for example, mean that text can be split across a number of discrete columns.

A pair of specifications, Fragmentation and Regions, generalized this further still. The Fragmentation spec describes how text runs can be broken up into multiple portions (split by pages, columns, or arbitrarily), and how developers and designers can control this. Regions give designers the means to define boxes and the text flows between those boxes, enabling them to create not just columns, but custom text layouts.

It is this Fragmentation capability that, Adobe argues, causes the substantial complexity of Regions. It's also a capability that's not readily removed. The Fragmentation spec defines the rules for both printing and CSS Columns, and Blink's Column implementation has been updated accordingly. As such, even if Regions are not readily exposed to developers, much of the implementation complexity is essential if Google wants Blink to provide standard compliant printing and columns.

Google, however, is willing to give even this up. Developer Adam Barth says that removing Fragmentation and reverting to an older version of the Column code—one that doesn't conform with current specs—in order to simplify and improve mobile performance is "a cost [Google] is willing to accept ."

Adobe's original CSS Regions code was contributed to WebKit, prior to Google's decision last April to fork WebKit and develop its own rendering engine, Blink.Adobe representatives note that Apple is now shipping the Regions code in the latest version of its browser, and Microsoft is shipping a similar capability based on an earlier iteration of the specification in Internet Explorer.

The disagreement between the companies points to different underlying priorities. Adobe, with a rich history in design and page layout tools for both print and Web, wants an HTML and CSS that can rival the capabilities of traditional page layout engines. Google's interest and priority is in making the Web a better platform for mobile application. If that means limiting CSS's capabilities as a design language in order to enhance performance, then that's a trade-off that Google thinks is worth making—at least in 2014.