You and Eric (and the rest of the team, I take it?) seem overly determined to remove the CSS Regions (and new multi column, and fragmentation or CSS Break) code and it truly looks like you are not interested in other opinions.
You keep providing the same reasons (not your current focus, high complexity) and you seem very eager not to provide others with the specific complaints by the core/rendering team.
While this is a Google open source project now, it is an open source project as well as a Google project. You host conferences for Chromium and Blink, you try to share the goals, the last week/this week snippets and create a nice environment where contributions to the projects are more than welcome.
Adobe (or whoever) has made a major effort, contributing code to Blink (and WebKit) for CSS Regions (or CSS Break) and Opera does that as well (for the new multi column code). While Adobe has its interest in pushing CSS Regions, I remember Googlers pushing for CSS Regions as well, perhaps using HTML5Rocks and in other ventures.
Right now, it just looks like you have your mind set on discouraging this kind of efforts from large contributors without providing them any way to defend their code, or help make it less complex. Frankly, it looks like a kick in the ass.
Please, talk to one another and try to communicate the specific issues CSS Regions are causing instead of just saying, "hey, this is complex, so it will be removed. Bye".
It looks very much Adobe is willing to put efforts into simplifying the code so it does not hamper any innovation or optimization. Maybe set up a meeting or whatever and go through the issues. I am sure Adobe would be willing to resolve these issues. At least it seems that way.
Bear in mind that Adobe is developing this code, not Google, so your goals should not be affected by their code (especially if they simplify the parts that hamper your development/optimization, which they are willing to do).
You have turned somewhat draconian in the discussion. Pay attention, relax your stance a bit and make an effort (even if only a mental one) to listen and help drive this into a more balanced, community cooperation.
The new multicolumn implementation is much more conformant with the CSS Break spec than the old implementation. It would be a big step back for web compatibility to throw out the new code in favor of the old, non-conformant code.
That's unfortunate, but it's a cost we're willing to accept in order to focus on achieving other goals. As Eric wrote, focusing on mobile performance means not doing other things, and we're choosing to improve mobile performance instead of improving CSS Break spec conformance.
I think complaints that (1) is complex in that every layout system has to think about how to do fragmentation are valid, but I think you signed up for that the minute you shipped a browser with the ability to print Web pages. My own opinion is that if you choose to ship a feature, you should want that feature to be as high quality as possible. If you're going to ship with printing and multi-column layout, then you have fragmentation in your engine, and the implementation of both should be high quality.
I agree with you that when we choose to implement a feature, we should provide a high quality implementation. However, at present there are many features of the engine that are not as high quality as we would like. Specifically, in Blink, it's difficult to create web applications that react to touch input and produce 60 frames per second on mobile devices. We've decided to focus on improving the quality of that aspect of the engine rather than improving the quality of content with intricate text layout.
It seems to me that the real issue that is putting (1) and (2) at risk is that you need an owner of the code in Blink, and that the fact that it is unowned seems to be the real issue here.
The underlying reason for that is because we've prioritized improving mobile performance over improving text layout. That means the folks who would own that code are instead focused in fixing issues on this list:
One last point: I think it's a bit silly for fragmentation advocates to be bashing the current multi-column code as being "buggy" or "low quality." The multi-column code that ships in WebKit and Blink is perfectly fine. The primary intent behind the re-write is to enable new functionality, and the new code has ported the bulk of its logic from the old. While some long standing bugs have been fixed during the re-write (e.g., painting/stacking) those bugs could have been fixed in the old code as well.
Yes, our plan is to continue shipping the code we're shipping and perhaps return to improving this area in the future when we're not so narrow focused on mobile performance. I'm hopeful that WebKit will continue to work on this area, and we'll benefit from WebKit's work when we text fragmentation eventually bubbles up in priority.