Share this story

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 does 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 doesn'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 is 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 is 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' 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.

It would be cool if Aurich or Peter could put together some example images showing what Fragmentation/Regions can achieve that traditional CSS3 cannot. Also is Google dumping Regions/Fragmentation for just Chrome on mobile devices, or for Chrome as a whole?

It would be cool if Aurich or Peter could put together some example images showing what Fragmentation/Regions can achieve that traditional CSS3 cannot. Also is Google dumping Regions/Fragmentation for just Chrome on mobile devices, or for Chrome as a whole?

My question also. Fragmentation/Regions sound like something that has very limited use but increases the complexity of the rendering engine.

I don't get it. Are regions part of the HTML standard or not? Isn't that the only question that should matter?

If yes, then how can Google just unilaterally throw them out? Or rather, how can they do that and still claim to be standards compliant? If they have a valid objection to it, let them take it up at the next standards setting committee meeting.

If regions aren't part of the HTML standard, then shouldn't they be thrown out anyway, like all the rest of the cruft that is a remnant of the pre-standards compliant web?

I don't get it. Are regions part of the HTML standard or not? Isn't that the only question that should matter?

If yes, then how can Google just unilaterally throw them out? Or rather, how can they do that and still claim to be standards compliant? If they have a valid objection to it, let them take it up at the next standards setting committee meeting.

If regions aren't part of the HTML standard, then shouldn't they be thrown out anyway, like all the rest of the cruft that is a remnant of the pre-standards compliant web?

It is supposedly necessary to remove CSS regions in order to improve performance on mobile, but CPU performance on mobile is in a period of rapid improvment, so ripping it out altogether seems like a drastic step.

I'd say if you plan on supporting it on the desktop, you should plan on supporting it on mobile.

Wow, when I said in the comments of the Ars article announcing Google's plan to optimize Blink, that I thought more Webkit/Blink compatibility problems were coming, I never thought it would be this quick and this big.

Google does seem to be circling the wagons to a certain extend on everything it does.

I don't get it. Are regions part of the HTML standard or not? Isn't that the only question that should matter?

If yes, then how can Google just unilaterally throw them out? Or rather, how can they do that and still claim to be standards compliant? If they have a valid objection to it, let them take it up at the next standards setting committee meeting.

If regions aren't part of the HTML standard, then shouldn't they be thrown out anyway, like all the rest of the cruft that is a remnant of the pre-standards compliant web?

I think it's more like 'If Regions compliance has to die in order to get Adobe's code out of our code base, so be it. We'll add it back with a faster, cleaner, more secure implementation later.'

But Google can't just publish an official statement clearly stating that Adobe's code is following the historical pattern of 'slow, over-complicated, vulnerable crap'. Similar to how one might avoid following "No honey, that blouse doesn't make you look fat" with "you just are", Google is trying to keep a relationship if not alive, then at least possible.

I would say that Google is trying to turn the web into it's own private playground.

Seriously, is there any part of the internet that Google doesn't want to control or be the final say over? They have a huge NIH syndrome: Dart instead of Javascript, Blink instead of webkit, now this.

Come now, it's understandable when you were founded by the two smartest people in the world and even your dumbest employee is smarter than anyone at any other company. Why would you want to even grudgingly accept the pathetically inadequate, broken solutions of your mental inferiors?

I don't get it. Are regions part of the HTML standard or not? Isn't that the only question that should matter?

If yes, then how can Google just unilaterally throw them out? Or rather, how can they do that and still claim to be standards compliant? If they have a valid objection to it, let them take it up at the next standards setting committee meeting.

If regions aren't part of the HTML standard, then shouldn't they be thrown out anyway, like all the rest of the cruft that is a remnant of the pre-standards compliant web?

I think it's more like 'If Regions compliance has to die in order to get Adobe's code out of our code base, so be it. We'll add it back with a faster, cleaner, more secure implementation later.'

But Google can't just publish an official statement clearly stating that Adobe's code is following the historical pattern of 'slow, over-complicated, vulnerable crap'. Similar to how one might avoid following "No honey, that blouse doesn't make you look fat" with "you just are", Google is trying to keep a relationship if not alive, then at least possible.

It kinda sounds like you want Google to post a straight forward "Thoughts on Regions" similar to what this other guy did back when he wrote Thoughts on Flash.

I don't get it. Are regions part of the HTML standard or not? Isn't that the only question that should matter?

If yes, then how can Google just unilaterally throw them out? Or rather, how can they do that and still claim to be standards compliant? If they have a valid objection to it, let them take it up at the next standards setting committee meeting.

If regions aren't part of the HTML standard, then shouldn't they be thrown out anyway, like all the rest of the cruft that is a remnant of the pre-standards compliant web?

W3C changed the way the HTML standards work. Instead of saying "this is HTML 5, these are the things you must have to be HTML 5 compliant", they switched to just a steady stream of "recommendations". There is currently a draft of the proposed CSS regions standard at http://dev.w3.org/csswg/css-regions/ so the standards body does at least recognize that it exists.

I don't get it. Are regions part of the HTML standard or not? Isn't that the only question that should matter?

If yes, then how can Google just unilaterally throw them out? Or rather, how can they do that and still claim to be standards compliant? If they have a valid objection to it, let them take it up at the next standards setting committee meeting.

If regions aren't part of the HTML standard, then shouldn't they be thrown out anyway, like all the rest of the cruft that is a remnant of the pre-standards compliant web?

W3C changed the way the HTML standards work. Instead of saying "this is HTML 5, these are the things you must have to be HTML 5 compliant", they switched to just a steady stream of "recommendations". There is currently a draft of the proposed CSS regions standard at http://dev.w3.org/csswg/css-regions/ so the standards body does at least recognize that it exists.

Yes, it's called "standards track", but it should be noted that not everything that is standards track will become a standard, and even then some standards may not ever be implemented. There's a reason that W3C specs are called "recommendations" in their final form. However, it should also also be noted that actual implementations are (almost always) required for a spec to advance to the final stage, as implementation experience often finds problems and solutions that theoretical specifications can miss, so it isn't IE6 all over again or whatever when browsers start implementing specs before they've reached Recommended status.

The steps for a web specification:

Quote:

Working Draft (WD)A Working Draft is a document that W3C has published for review by the community, including W3C Members, the public, and other technical organizations. Some, but not all, Working Drafts are meant to advance to Recommendation; see the document status section of a Working Draft for the group's expectations.Candidate Recommendation (CR)A Candidate Recommendation is a document that W3C believes has been widely reviewed and satisfies the Working Group's technical requirements. W3C publishes a Candidate Recommendation to gather implementation experience.Proposed Recommendation (PR)A Proposed Recommendation is a mature technical report that, after wide review for technical soundness and implementability, W3C has sent to the W3C Advisory Committee for final endorsement.W3C Recommendation (REC)A W3C Recommendation is a specification or set of guidelines that, after extensive consensus-building, has received the endorsement of W3C Members and the Director. W3C recommends the wide deployment of its Recommendations. Note: W3C Recommendations are similar to the standards published by other organizations.

For all the people talking about Google circling their wagons around their walled gardens or whatnot, it may help you to note that currently Mozilla has no plans to implement CSS Regions and has many objections to the spec in its current form (last I checked they'd proposed an alternative that met what they thought were the most important use cases covered by Regions, but that hasn't been updated since June, so I don't know the current status).

That's one of the problems with reporting on the standards-writing process. As the cliche goes, much like sausage making, people don't really think about what goes into it and can be kind of horrified when they get a glimpse. You can call it a catfight, or you can call it the daily norm, as different companies try to hash out what the best ways are to handle a million different aspects of the web. Sometimes it's harmonious, and sometimes people come in with very different priorities, and even the best compromises have significant tradeoffs.

I would say that Google is trying to turn the web into it's own private playground.

Seriously, is there any part of the internet that Google doesn't want to control or be the final say over? They have a huge NIH syndrome: Dart instead of Javascript, Blink instead of webkit, now this.

Come now, it's understandable when you were founded by the two smartest people in the world and even your dumbest employee is smarter than anyone at any other company. Why would you want to even grudgingly accept the pathetically inadequate, broken solutions of your mental inferiors?

I sure hope you're being funny, because otherwise that is the worst sort of fawning.

For all the people talking about Google circling their wagons around their walled gardens or whatnot, it may help you to note that currently Mozilla has no plans to implement CSS Regions and has many objections to the spec in its current form (last I checked they'd proposed an alternative that met what they thought were the most important use cases covered by Regions, but that hasn't been updated since June, so I don't know the current status).

That's one of the problems with reporting on the standards-writing process. As the cliche goes, much like sausage making, people don't really think about what goes into it and can be kind of horrified when they get a glimpse. You can call it a catfight, or you can call it the daily norm, as different companies try to hash out what the best ways are to handle a million different aspects of the web. Sometimes it's harmonious, and sometimes people come in with very different priorities, and even the best compromises have significant tradeoffs.

Overflow still relies on Fragmentation, though, so doesn't really help. The way Adobe is positioning it (and I don't think Opera disagrees on this point), you'll need something that's more or less equivalent to the Regions infrastructure, regardless of the way you expose that control to CSS developers.

I'm not sure who to cheer for here. I'm leaning towards Adobe, but I'm also in print...

Coming from a print background myself, I can understand, but at what cost does this come? Regardless of what people read into Google's motivations, using regions can significantly increase complexity.

I could be wrong, but I'm wondering if Adobe is pushing this technology in order to advance some of their tools that enable non-code savvy content creators to build complex Web experiences. As a designer, I can see how this would be good, if it worked, but so far, I haven't seen any non-coding tools that do this all too well...

If regions are just going to be used to place ads in the middle of articles, then I'm not really in favor of them anyway.

In the print world, there's nothing I despise worse than getting to the end of a page and seeing that the article is continued 20 pages later. I read most magazines cover to cover anyway so it's just an annoyance to have to flip to the end, then when finished with the article try to remember where I left off 20 pages earlier.

I don't get it. Are regions part of the HTML standard or not? Isn't that the only question that should matter?

If yes, then how can Google just unilaterally throw them out? Or rather, how can they do that and still claim to be standards compliant? If they have a valid objection to it, let them take it up at the next standards setting committee meeting.

If regions aren't part of the HTML standard, then shouldn't they be thrown out anyway, like all the rest of the cruft that is a remnant of the pre-standards compliant web?

I think it's more like 'If Regions compliance has to die in order to get Adobe's code out of our code base, so be it. We'll add it back with a faster, cleaner, more secure implementation later.'

But Google can't just publish an official statement clearly stating that Adobe's code is following the historical pattern of 'slow, over-complicated, vulnerable crap'. Similar to how one might avoid following "No honey, that blouse doesn't make you look fat" with "you just are", Google is trying to keep a relationship if not alive, then at least possible.

Adobe's more recent releases have been dramatically better on some of these fronts - particularly security (modern versions of acrobat reader for example are worlds ahead of what it used to be). Their reputation isn't unfair, but they're certainly trying to address a lot of this.

Perhaps this is best seen as a convergence issue. I loath Google, and loved Adobe for years, until they adopted the rental-only model for Creative Suite. I'm hard-core print, but I do both complex layouts and fine straight book text. I also do some Web. How much room is there on a mobile-sized screen for complex layouts? Are such layouts worth a high overhead on mobiles? It may be that making the most of both small and large screens requires divergence rather than convergence.

About one third of my site traffic is mobile. It would be a damned nuisance if fundamentally incompatible standards required that I do two separate Web sites, one for mid- to full-screens and one for mobile. But if divergence still allowed for a common set of shared code, so that I could make a single Web site for both, at the cost of using a simplified layout for larger screens, I'd do it. In those circumstances, everyone else would be doing it too.

Desire to run Android browsing on 25c Mediatek chips with all the performance of a 6502?

Some larger scheme Google has in mind (a proprietary [but "open"!] new CSS scheme, WebC, to complement WebM and WebP) is the real issue here, the "performance problems" are just an excuse?

Don't want to trip up your insightful posts, but it's the same code, hotshot. Adobe committed the lion's share before the webkit/blink fork, and adobe has worked to keep the ports in sync ever since. As I pointed out above, the spec is currently just a working draft, and Mozilla currently doesn't plan on implementing it.

With that in mind, you may now continue.

edit: you can actually run it in Chrome (including on mobile) right now if you turn on experimental web feature support in about:flags.

Desire to run Android browsing on 25c Mediatek chips with all the performance of a 6502?

Some larger scheme Google has in mind (a proprietary [but "open"!] new CSS scheme, WebC, to complement WebM and WebP) is the real issue here, the "performance problems" are just an excuse?

Don't want to trip up your insightful posts, but it's the same code, hotshot. Adobe committed the lion's share before the webkit/blink fork, and adobe has worked to keep the ports in sync ever since. As I pointed out above, the spec is currently just a working draft, and Mozilla currently doesn't plan on implementing it.

With that in mind, you may now continue.

???What are you disagreeing with me about? Yes, it is the same code. And it appears to run fine in mobile Safari. Which suggests that there is something strange about Google's complaint. Which leads to my three suggestions.