It’s been a while since the Adobe WebPlatform team started contributing to the CSS Regions implementation in WebKit, and then also in Blink after the split. During this period, CSS Regions got enabled by default, albeit with prefixes, in Safari on iOS and OS X. Moving forward, we think that web developers would benefit from having CSS Regions enabled by default in Blink/Chrome too.
The existing CSS Regions implementation in Blink matches what Safari shipped on iOS/OS X. Since our goal is to ensure a solid CSS Regions implementation before shipping in Blink, we would like to reach an agreement with the Blink community about the things that need to be solved before enabling this feature by default.
In order to keep track of things, we created a list of master bugs for the engineering items:
* master bug for CSSRegions in Blink: https://code.google.com/p/chromium/issues/detail?id=236427
* master bug for the engineering items that should be done before unflagging/enabling by default:
Below i will highlight the main areas we will focus our engineering contributions on in the next months, towards our goal of enabling regions by default in Blink.
1. CSS Regions and accelerated compositing
* Goal: enable accelerated compositing for content that is fragmented in regions
* Blink: started discussion on graphics-dev https://groups.google.com/a/chromium.org/forum/#!topic/graphics-dev/8Jp8aZ2Qji4
(Note: implementation close to finish in WebKit)
2. CSS Regions and overflow content
* Goal: make sure that content that overflows regions is correctly handled, without painting artefacts and hit testing in overflow content is working properly
* Meta bug: https://code.google.com/p/chromium/issues/detail?id=319306 (includes overflow among other things)
* Blink: layout overflow work started, visual overflow to be done after
(Note: layout overflow handling landed in WebKit, visual overflow handling close to land in WebKit)
3. CSS Regions and CSSOM
* Goal: make sure that CSSOM API for regions is implementable and updated to the latest WD.
* Blink: the most important change is the use of Map for modelling the document named flows collection
4. CSS Regions and selection
* Goal: make sure that selection/editable content is working properly (and spec compliant) in regions and that cut/copy/paste do something reasonable
* Blink: added selection tests, started work on fixing issues in partnership with Igalia (http://code.google.com/p/chromium/issues/detail?id=319305)
5. CSS Regions interoperability with transforms
* Goal: make sure that the content flowed in regions and the regions themselves work properly when transformed
* Blink: requires work for 1. and 2. to be completed
6. CSS Regions interoperability with new layout modules
* Goal: make sure that CSS Regions work properly with flexbox, grid and multi-column
* Blink: we already fixed couple of issues related to regions and flex box, bug fixing remaining
7. Unprefix CSS Regions properties/APIs
In addition to the above items, there are a couple of engineering items that should not impact the decision of shipping regions, but are needed to fully implement the CSS Regions spec. We think that these items should be worked on after regions are enabled by default/shipped in Blink:
* CSSOM Region interface: we validated with Adam Barth that the Region interface can be implemented as described in the current version of the spec (https://codereview.chromium.org/38943008/)
* CSSOM regionFragmentChange event (http://dev.w3.org/csswg/css-regions/#named-flow-events)
* Region styling (http://dev.w3.org/csswg/css-regions/#the-region-pseudo-element)
** basic support (colour and background-color) available already in Blink
* CSS Regions support in WebInspector
* flow-into: ‘content’ (http://dev.w3.org/csswg/css-regions/#the-flow-into-property)
* Multi-column regions (http://dev.w3.org/csswg/css-regions/#multi-column-regions)
** Goal: add support for making a region from a multicolumn element
* Pseudo-elements processing model (http://dev.w3.org/csswg/css-regions/#processing-model)
* CSS Regions and Shadow DOM
Mihnea-Vlad Ovidenie wrote:
> It’s been a while since the Adobe WebPlatform team started
> contributing to the CSS Regions implementation in WebKit, and then
> also in Blink after the split. During this period, CSS Regions got
> enabled by default, albeit with prefixes, in Safari on iOS and OS
> X. Moving forward, we think that web developers would benefit from
> having CSS Regions enabled by default in Blink/Chrome too.
I don't agree. The current approach taken in CSS Regions is, I
believe, harmful to the web. It mixes document style and structure,
abuses HTML tags for presentational purposes, requires code that is
vastly more complex and verbose than is needed to achieve common
layouts, and leads to per-document style sheets that are
non-responsive to the users' environment. I've expanded on these views
If Regions are turned on, it will be very hard to turn them off again.
Caution should therefore be taken.
That being said, I believe in reusing code for fragmentation so that
pagination and multi-column layout can be done using the same code. I
believe Adobe has contributed good code for this purpose.
Håkon Wium Lie CTO °þe®ª
Regions brings a large amount of both future and current complexity to
Blink. Both complexity inherent in the spec as well as complexity of
the current implementation. All features have some complexity cost,
but looking closely at Regions I have come to believe the cost/benefit
to be very imbalanced, especially in the context of Blink’s current
As you and others have excellently stated, Regions addresses some very
real deficiencies of the web platform. But I believe Blink (hopefully
with Adobe’s help) will need to find other simpler/smaller ways to
address these deficiencies. Perhaps we can find solutions via other
proposals (Mozilla’s Fragments  or Opera’s Figures ?) or (yet
unproposed) exposure of basic text layout primitives (like iOS? )
to allow frameworks to implement region-like layouts for the web in
All the other solutions are only changing the CSS API surface and not the actual result. Basically, they are all trying to achieve almost the same thing with a different degree of flexibility. Any CSS API we choose to implement will have the same amount of complexity because it actually needs to split paragraphs across arbitrarily sized boxes.
I hope that despite this bump in the road you and your team at Adobe
will be interested in continuing to work with Blink. After the
short-term performance needs are addressed, I too believe the mobile
web will come to demand advanced text layouts like some of what
Regions enables. I just believe that at the time we add those, we
have to do so in a 60hz-smooth simple-to-maintain fashion and I hope
you and Adobe will be a part of that.
Lars Erik Bolstad wrote:Indeed. In order to compete with native apps, the Web needs both high
> From Opera's side we agree with the prioritization of performance
> optimizations in Blink, and we'd be happy to help identify issues and
> improve that aspect of the Regions code.
performance, and the ability to create paged & multicol presentations
(without invoking JS).
Our Blink-based implementation of this functionality currently relies
on fragmentation being done by the Regions code. It makes sense to use
the same code for all fragmentation, including pagination and multicol
support. The question of code reuse is separate from whether Regions
should be exposed through CSS or HTML.
How many of those 10000 lines would need to be kept in order for the multi column support to still work, but removing anything that is only needed for providing CSS Regions to the end user? Would the lines that are kept be "all over the place" or would they be in only a limited area?
Looking at your patch, ~10000 lines out of ~586000 (we