Google Groups

Re: [blink-dev] CSS Regions in Blink: status, future work


Eric Seidel Jan 23, 2014 11:41 AM
Posted in group: blink-dev
Mihnea:

After much discussion with the most active core/rendering
contributors, I no longer believe that CSS Regions is something Blink
should ship.

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
goals [6].

CSS experts from both Mozilla [1, 2] and Opera [3] have stated
publicly their opposition to implementing CSS Regions and have
commented at length on the Regions’ spec complexity.

My personal objections to Regions are more focused on the complexity
in Blink’s implementation.  I recently attempted to understand exactly
what code Blink uses to support Regions by locally removing (most of)
Regions-related code from my local checkout [4].  I was very surprised
to find that patch was over 10,000 lines!  For reference, all of
Blink’s C++ totals only ~350,000 code lines [5].  Moreover, around
half of the Regions code I found is sprinkled across 140+ files most
of which one might naively assume should need to know nothing about
Regions. Compared to other modern CSS additions like CSS Grid or CSS
Flexbox which are largely self contained, CSS Regions is surprisingly
sprawling.

As discussed in our proposed 2014 Goals for Blink [6] I believe
Blink’s focus this year must be on mobile and specifically mobile
performance.  Speaking with other rendering experts, I have come to
understand that Regions both does not play well with existing
performance optimizations as well as (through its pervasive
complexity) impedes ongoing simplification and optimization work to
our core rendering code.  Complaints from core rendering engineers, my
readings of the Regions spec, and then finally my preparing this diff
(only to find these huge complexity costs) are what eventually
reversed my opinion on Regions.

I believe if Blink were offered a patch to add CSS Regions today
(inverse of [4]), it would not be accepted.  Considering this
complexity and the objections from other browsers, I do not see how
it’s possible for Blink to ship Regions.

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 [7] or Opera’s Figures [8]?) or (yet
unproposed) exposure of basic text layout primitives (like iOS? [9])
to allow frameworks to implement region-like layouts for the web in
JavaScript.

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.

Sincerely,
Eric Seidel

1. http://lists.w3.org/Archives/Public/www-style/2013Oct/0597.html
2. http://lists.w3.org/Archives/Public/www-style/2013Oct/0689.html
3. http://alistapart.com/blog/post/css-regions-considered-harmful
4. https://codereview.chromium.org/143323014/
5. http://www.ohloh.net/p/chromium-blink/analyses/latest/languages_summary
6. https://groups.google.com/a/chromium.org/d/msg/blink-dev/Z5OzwYh3Wfk/IWooaY5FZowJ
7. http://dev.w3.org/csswg/css-break/
8. http://figures.spec.whatwg.org/
9. https://developer.apple.com/library/ios/documentation/UIKit/Reference/NSTextContainer_Class_TextKit/Reference/Reference.html#//apple_ref/occ/cl/NSTextContainer

On Wed, Nov 20, 2013 at 9:29 AM, Mihnea-Vlad Ovidenie <mih...@adobe.com> wrote:
> Hi all,
>
> 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:
>
> https://code.google.com/p/chromium/issues/detail?id=319872
>
>
> 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
>
> * Meta bug:  https://code.google.com/p/chromium/issues/detail?id=319299
>
> * 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.
>
> * Meta bug:  https://code.google.com/p/chromium/issues/detail?id=319326
>
> * 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
>
> * Meta bug:  https://code.google.com/p/chromium/issues/detail?id=319310
>
> * 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
>
> * Meta bug:  https://code.google.com/p/chromium/issues/detail?id=319317
>
> * 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
>
> * Meta bug:  https://code.google.com/p/chromium/issues/detail?id=319319
>
> * Blink: we already fixed couple of issues related to regions and flex box,
> bug fixing remaining
>
>
> 7. Unprefix CSS Regions properties/APIs
>
> * Meta bug:  https://code.google.com/p/chromium/issues/detail?id=320543
>
>
>
> 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
>
> ** Meta bug:  https://code.google.com/p/chromium/issues/detail?id=319383
>
>
> * CSS Regions support in WebInspector
>
> ** Meta bug:  https://code.google.com/p/chromium/issues/detail?id=319370
>
> * 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
>
> ** Meta bug:  https://code.google.com/p/chromium/issues/detail?id=320552
>
> * Pseudo-elements processing model
> (http://dev.w3.org/csswg/css-regions/#processing-model)
>
>
> * CSS Regions and Shadow DOM
>
> ** Meta bug:  https://code.google.com/p/chromium/issues/detail?id=319878
>
>
> We hope that this email will start a productive conversation inside the
> Blink community about the things that need to be done in order to ship CSS
> Regions in Blink and about the remaining items to be done after that
> happens.
>
> Thank you,
> Mihnea Ovidenie