CSS Regions in Blink: status, future work

[Mihnea-Vlad Ovidenie]

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

[Morten Stenshorne]

Mihnea-Vlad Ovidenie <mih...@adobe.com> writes:

> 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 agree. While CSS Regions in itself is something we want, at Opera we
additionally depend on the regions implementation to finish "region
based multicol" [1][2], which in due course will give Blink full and
proper multicol support, which will be able to interact nicely with
other fragmentation contexts, such as regions, paged media / paged
overflow, or an nested multicol containers. We'll also be able to
balance columns properly. Eventually we can remove the old
ColumnInfo-based multicol implementation (but we'll need a solution
for paged overflow as well before we can do so; it currently relies on
ColumnInfo). Removing ColumnInfo will rid RenderBlock and
RenderBlockFlow of significant amounts of code.

[1] http://www.chromestatus.com/features/6526151266664448
[2] https://code.google.com/p/chromium/issues/detail?id=334335

Awesome! I hope it will find its way into Blink soon too. :)

> 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

I should be able to help out on the (region-based) multicol side
here. I suppose you don't intend to spend time on making the
old/current multicol implementation (the one using the ColumnInfo
class) behave inside regions?

Thanks for your efforts! I will follow the CSS regions implementation
progress with great interest, and contribute where I can, if you're
interested.

And sorry about the delay, BTW. Although I read through this post
several weeks ago, I've been mostly inactive here lately, because I've
been busy with another project.

There's one additional issue I'd like to bring up, which is about
breaking policies. This really isn't specific to regions, but rather
to all types of fragmentation (regions, multicol, paged media /
overflow). Blink's support for break-after, break-before and
break-inside is really limited. First of all, the properties I just
mentioned aren't actually supported at all; instead there's
page-break-foo (CSS 2.1), -webkit-region-break-foo (region spec with
-webkit- prefix) and -webkit-column-break-foo (no idea where this
comes from; some old multicol spec perhaps?). But worse than lacking
support for the modern property names is the lack of proper support
for anything except for forced breaks
(*-break-{after,before}:always). There is also some support for
*-break-inside:avoid, but it's incorrectly implemented (it makes a
container completely unbreakable). *-break-{before,after}:avoid isn't
implemented at all.

Fixing this isn't trivial, but I'd like to see it done. It surely
doesn't need to be (probably shouldn't be) part of the regions
work. Maybe it's better off as a separate task.

OK, looks like I'm starting to digress, so I'll stop for now. :)

--
---- Morten Stenshorne, developer, Opera Software ASA ----
------------------ http://www.opera.com/ -----------------

[johann...@gmail.com]

Hey,

we have been using the CSS Regions implementation on Chorme through the flag for the past 1.5 years through BookJS ( http://sourcefabric.github.io/BookJS/ ), about a year in combination with Flexboxes. In our experience it is quite stable, so removing the flag would seem like a good idea at this stage.

[Håkon Wium Lie]

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
here:

http://alistapart.com/blog/post/css-regions-considered-harmful

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.

Cheers,

-h&kon
Håkon Wium Lie CTO °þe®ª
how...@opera.com http://people.opera.com/howcome

[Håkon Wium Lie]

Also sprach johann...@gmail.com:

> we have been using the CSS Regions implementation on Chorme through the
> flag for the past 1.5 years through BookJS (
> http://sourcefabric.github.io/BookJS/ ), about a year in combination with
> Flexboxes. In our experience it is quite stable, so removing the flag would
> seem like a good idea at this stage.

The problem with this approach is escalating complexity; to create the
pages and columns you rely on a complex script. As an example, I coded
up your test document "The Malay Archipelago" without using Regions
and scripts. Instead, the HTML document has only 43 lines of CSS which
achieve the same layout:

http://people.opera.com/howcome/2013/tests/malay/archipelago.html
http://people.opera.com/howcome/2013/tests/malay/archipelago.pdf

The PDF is generated with Prince [3]; Opera has also implemented
pagination/multicol/floating in WebKit, screenshots are available [4].

At the time (April 2013), your script consisted of 1643 lines. Today,
"book.js" (downloaded from [5]) has 2197 lines. Some lines are
comments that can be removed. However, the complexity is still
baffling and I don't think Blink should turn on a feature which
invites complex solutions to problems that can be solved with much
simpler means.

In fact, I believe the current approach taken by CSS Regions is
harmful to the web [6].

[1] http://lists.w3.org/Archives/Public/www-style/2013Apr/0631.html
[2] http://lists.w3.org/Archives/Public/www-style/2013Oct/0623.html
[3] http://www.princexml.com/
[4] http://people.opera.com/howcome/2013/10-figures/
[5] http://sourcefabric.github.io/BookJS/book.js
[6] http://alistapart.com/blog/post/css-regions-considered-harmful

[Johannes Wilm]

Hey Håkon, 

your example is interesting, but as I gather it, it would only work for printing out -- not for combining with other elements on a screen to create something like a text editor environment the way we use it. It would therefore not fit our requirements.

Did I misunderstand that?

Also, as far as I understood, the standard you were basing this on has not been accepted by any of the browsers other than Opera, correct? If it's not there, and won't ever be there, then it's not really an alternative for us.

We currently use CSS Regions without any flags in Webkit based browsers and instruct Chrome users to turn on the flag so that they can use CSS Regions. 

--
Johannes Wilm
http://www.johanneswilm.org
tel US: +1 (520) 399 8880
tel NO: +47 94109013
tel DE: +49 176 370 18082

[Johannes Wilm]

On Wednesday, January 22, 2014, Håkon Wium Lie wrote:

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
here:

With all due respect, I have not seen any proposal that will allow the presentation of page like elements on the screen in addition to editorlike menus in any simpler way. If CSS Regions aren't turned on, I would imagine that our code would have to increase to at least ten times what it is now. it wouldn't matter if your own standard would be adapted, as it's not addressing our needs.

At the same time, we try to do something extraordinarily complex, which under all circumstances will fill a lot of code. Most usage of regions will with all likelihood be much much simpler and therefore also hardly require any code at all.

I am here merely commenting on the fact that we have used CSS Regions in both Chrome and Webkit for quite a while, in a production environment, pushing it to its limits, and can report back that we think it is ready to be unflagged. 

 

  http://alistapart.com/blog/post/css-regions-considered-harmful

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.

Cheers,

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
how...@opera.com                  http://people.opera.com/howcome

--
Johannes Wilm
http://www.johanneswilm.org

tel: +1 (520) 399 8880

[Håkon Wium Lie]

Also sprach Johannes Wilm:

> your example is interesting, but as I gather it, it would only work for
> printing out -- not for combining with other elements on a screen to create
> something like a text editor environment the way we use it. It would
> therefore not fit our requirements.
>
> Did I misunderstand that?

Yes, you misunderstood. These features can just as easily be
implemented on-screen and Opera have implemented most of them in
WebKit. Here are some screenshots from our implementation:

http://people.opera.com/howcome/2013/10-figures/

All of the examples there were done in 10 lines or less of CSS.

Cheers,

[Johannes Wilm]

Hey Håkon,

I had seen those examples. But this is still just for everything or nothing on the page, right? So people will then use it for print. I cannot create an editor with 'fake' pages with editor controls above it (similar to Google Docs), can I?

I think your own standard looks interesting. If through the usage of CSS Region with time it becomes more popular to create such elements, you could possibly gain support for getting browsers to accept it. But we are never going to get there if CSS Regions continue to be turned off.

On Wednesday, January 22, 2014, Håkon Wium Lie wrote:

[Håkon Wium Lie]

Also sprach Johannes Wilm:

> I had seen those examples. But this is still just for everything or nothing
> on the page, right?

No. Pagination/multicol/floating can be set on a per-element basis.

[Johannes Wilm]

So I can add a graph and saa "please put it on the top of this or one of the following 2-3 pages (depending on how it fits)" without using any Javascript? and have footnotes automatically move from page 2 to page 3 when the reference to the footnote moves to the next page? And show individual pages with a space of x  pixel of grey between them, with white pages surrounded by a black border and page numbers in the lower right (unless page is a  chapter start)?

If it can that, that's great, and we'll definitely look at it once it becomes an implemented standard. But that doesn't change the fact that CSS Region is production ready now, and it's working quite well after years of testing. I also doubt that most uses of CSS Regions will be our particular use case, which seems quite specific to me. 

[Håkon Wium Lie]

Johannes Wilm wrote:

> So I can add a graph and saa "please put it on the top of this or one of
> the following 2-3 pages (depending on how it fits)" without using any
> Javascript?

Yes.

http://figures.spec.whatwg.org/#deferring-floats:-float-defer-column-float-defer-page

> and have footnotes automatically move from page 2 to page 3
> when the reference to the footnote moves to the next page?

Yes.

http://books.spec.whatwg.org/#footnotes

> And show individual pages with a space of x pixel of grey between
> them, with white pages surrounded by a black border and page
> numbers in the lower right (unless page is a chapter start)?

Yes.

http://books.spec.whatwg.org/#page-selectors

[Johannes Wilm]

Håkon, your specification is quite well developed. it may work for a lot of cases. But by taking away the kind of control web developers can have if they do things through CSS Regions + Javascript, you really limit them to the use cases you have thought out on beforehand. granted, this may cover quite a lot. But for example: I see you assign headers by copying contents strings of certain HTML elements, to take your example:

 @page { @top-center { content: string(header) }}
  h1 { string-set: header }

This will work well in 99% of cases. But what if I want to do more operations with it? For example, I may want to cut the header string if it is longer than 15 characters. Or I may want to add a Mathjax generated formula that is formatted in quite different ways depending on the surroundings. Or I may say that if the headline contains bold OR italic, I want that to be copied, but if it contains both, then I want to remove the text formatting entirely. Or I may decide that I don't want it to be centered, but instead "center + 0.75 inch to the right".  

[Håkon Wium Lie]

This discussion is now outside the realm of blink-dev, I believe, so I'll
answer Johannes in private. Let me know if you want to be Cc'd.

[Johannes Wilm]

Hey,

I think this is very much important for the decision whether CSS Regions should be included. The point is not how you can achieve every single of the points I mentioned using your specification (I will investigate the specifics of that once your specification is implemented in  the browsers), but that the very specific definitions you have have the advantage that it is easier to create simple book layouts, but the disadvantage that because it is so precise, you will have to run into use cases that you haven't thought of that will not be covered.

[zeljk...@gmail.com]

Wouldn't bookjs combined with CSS Regions in Chrome be a substitute for the 500 USD/computer license PrinceXML of which you are the director, Håkon?

On Wednesday, November 20, 2013 6:29:51 PM UTC+1, Mihnea Ovidenie wrote:

[Adam Barth]

Please refrain from ad hominem arguments and keep the discussion to the technical issues.

Kindly,

Adam

[Eric Seidel]

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

[Johannes Wilm]

Does this mean that the new CSS columns work will be removed as well?

--
Johannes Wilm
http://www.johanneswilm.org

tel: +1 (520) 399 8880

[Bem Jones-Bey]

FWIW, it looks like it is included in Eric's speculative regions removal patch (https://codereview.chromium.org/143323014/). Eric, was that intentional?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Alexandru Chiculita]

On Thursday, January 23, 2014 11:41:42 AM UTC-8, Eric Seidel wrote:

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].

I totally understand how Regions can appear as a complex beast to some. It is one of the few features that has been tested to behave well with all the other things in the platform. Our early discussions with the Blink team about shipping Regions included a requirement to fix all of the integration points with existing features. We needed to tweak the whole platform in order to have that magic happen. 

Also, the implementation of Regions is a super-set of multi-columns and most of the code that you looked at would still be necessary to support new-multi-column and pagination.

I’m all in favor of pagination (for printing pages) and new-multi-column based on Regions code. It will not just remove old Multi-Column code, but it will also improve the rendering & layout quality of these features. For example:

1. Regions can render transforms without artifacts. Columns (and tables!) still have trouble doing that.

2. Regions can handle nested cases. Currently, multi-column is using the pagination code, so multi-column will not show up when you try to print a page with multi-columns. 

3. Regions can move DOM content to a different place on screen. This can come in handy for additional pagination / printing features like headers and footers. This is similar to ShadowDOM and SVG’s “use” tag, just that it is done at the RenderObject level instead. That’s just because line-layout needs to split paragraphs in the middle and there’s no representation of that in the DOM.

I will try to demystify the Regions implementation, as it is not as complex as it looks. Our Regions team at Adobe would happily work with the Blink layout experts to further simplify the implementation. We welcome constructive feedback and we are always open to improving the codebase.

** Code shared with the new-multi-column/pagination implementation:

This covers the most of the 10,000 lines you are mentioning.

1. Off-screen container to handle fragmentation. This one has a bit of line-layout code to properly handle fragmentation. However, this is largely a duplicate of the multi-column code. The difference is that the new code works with arbitrarily sized fragments (needed for both pagination and Regions).

2. Content displays through regions, so we have rendering and mouse/touch event delegation from the regions to the off-screen container.

3. Lots of fixes all over the place to make rendering behave in the context of “fragmented” content. These fixes are needed for multi-column/pagination/any-other-proposal as well.

** Code specific to CSS Regions:

1. Basic CSS property parsing, we only have a few properties, so it cannot be a lot of code there. Hopefully, parsing a string in CSS is not adding too much complexity.

2. The off-screen container of the flow needs to do its own layout, so there’s some code in RenderView that will invoke the layout for the off-screen container.

3. RenderObjects need to be placed in the right off-screen container based on the "-webkit-flow-into" property, so there are a few hooks when the RenderObjects are created and destroyed.

** Complex code specific to Regions:

1. Auto-height regions. Auto-height regions can require two passes on the content, so there’s some code for that too. As some might be aware, two passes for layout is not a new concept. Other parts of the code do two layouts: overflow: auto, flex-box, tables, grid. This is complicated because it has optimizations in place to avoid layouts when not necessary.

The basic functionality for auto-height regions can be described in 3 steps:

- We need to run the “layout” function twice. 

- We use a boolean flag to slightly change behavior in the first pass compared to the second one. 

- The only computed results in the first pass are the sizes of the regions that have “height: auto” specified. The second pass is just a normal layout that just replaces “height: auto” with the computed heights from the first pass.

2. Region styling. This allows different text colors for content that flows through a specific region. I agree, this adds a quite a bit of special CSS parsing code. CSS Style recalculation also needs to go through the rules of the parent region, so that adds another for-loop somewhere in the CSS style recalculation.

3. Web Inspector code. There’s some functionality in the Inspector to help highlight regions and flows in a page.

As soon as CSS Regions becomes the implementation behind multi-column and pagination, the code for multi-column can go away. That will reduce a lot of the duplicated code. Moreover, it will remove lots of existing complexity in the LineLayout code.

 

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.

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.

I hope Adobe can continue working with the Blink community. I definitely think that part of that collaboration could be to work with the layout experts at Google to figure out how Regions can live on within the improved Blink architecture. If you can share the details of the work that Regions is impeding, we’d be more than happy to work with you to find a solution and implement it.

 

Sincerely,
Eric Seidel

Cheers,

-Alex Chiculita,

Adobe 

[Lars Erik Bolstad]

Hi Eric,

Den 23.01.14 20:41, skrev Eric Seidel:

> 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.
>

<snip>

>
> 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.

If you ignore Morten's reply [1] to Mihnea's email you may get the
impression that Opera would support a decision to remove the Regions
implementation from Blink. As Alexandru now also pointed out, the new
multicol implementation that we've been working on has dependencies on
the Regions code.
I trust you take this into consideration before rushing to delete code
we've contributed to Blink.

Cheers,
Lars Erik

[1]
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/kTktlHPJn4Q/2XdrvHhLG-sJ

[PhistucK]

Does Håkon not represent Opera? He is very much against CSS Regions in their current state.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Hajime Morrita]

Lars isn't talking about the spec but is taking about underlying implementation.

It seems his teams's work depends on a part of Regions infrastructure.

[Lars Erik Bolstad]

Yes, I think the ongoing discussions about the CSS Regions spec can be kept separate from the issue of whether or not this code needs to be removed from Blink (as Håkon also points out in his email, btw).

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.

Lars Erik


Den 24.01.14 09:58, skrev Hajime Morrita:

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Håkon Wium Lie]

Lars Erik Bolstad wrote:

> 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.

Indeed. In order to compete with native apps, the Web needs both high
performance, and the ability to create paged & multicol presentations
(without invoking JS). This is why we're "paging the web":

http://people.opera.com/howcome/2011/reader/

(To try this, download Opera 12.16, set "Scroll is pan" in
opera:config and use the mouse to drag from one page to the next)

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.

Cheers,

[Johannes Wilm]

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? 

[Adam Barth]

On Fri, Jan 24, 2014 at 3:05 AM, Håkon Wium Lie <how...@opera.com> wrote:

Lars Erik Bolstad wrote:

 > 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.

Indeed. In order to compete with native apps, the Web needs both high
performance, and the ability to create paged & multicol presentations
(without invoking JS).

Can you help me understand why multicol presentations are necessary for the web to compete with native frameworks.  For example, I think everyone would agree that Android is a competitive native framework, but I don't believe the Android framework support multicolumn text layout.

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.

My understanding is that we don't need all the complexity of Regions to implement multicolumn.  For example, could we use something more like Fragments [1], where the implementation of the feature would be more self-contained?

To avoid confusion, I'd note that we've already shipped multicolumn, which means we're reticent to remove the feature.  Regions has not gone through the intent-to-ship process, which means we haven't make a commitment to supporting the feature.

On Fri, Jan 24, 2014 at 12:20 AM, Lars Erik Bolstad <lbol...@opera.com> wrote:

I trust you take this into consideration before rushing to delete code we've contributed to Blink.

I don't think it's relevant who contributed the code.  For example, I contributed a big chunk of the code for iframe@seamless, but that's not influencing my opinion about whether or not we should remove that feature.  Instead, we should base these decisions on the future.  All the data I've seen indicates that the future will be predominately mobile.  The web is quite far behind in mobile, which is why we're applying a greater amount of focus to solving the problems we have on mobile, even at the expense of nice-to-have features.

On Fri, Jan 24, 2014 at 3:39 AM, Johannes Wilm <ma...@johanneswilm.org> wrote:

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?

We already have an implementation of multicolumn that's independent of region.  The issue is that the implementation is not of particularly high quality, but that's the implementation that we're currently shipping.

Adam

[1] http://dev.w3.org/csswg/css-break/

[Mihnea Ovidenie]

Eric,

Looking at your patch, ~10000 lines out of ~586000 (we counted also the comments and blank lines from your provided link) account for 1.7% of the total C++ code in Blink.  We also counted 31 files of contained CSSRegions functionality with about 6300 lines. The css regions related functionality in WebInspector touches 11 files with about 1500 lines.

Thus remain ~ 2200 lines of C++ (code, comments, blanks) functionality including parsing, css properties exposure, js exposure and layout and rendering (we assume that whatever you need to parse, expose in css and js will also touch a good amount of files).

We suspect your are mainly concerned about layout and rendering code. If so, we pledge to work together, address these concerns and make sure that the regions code does not hamper your Blink 2014 goals.

As others in this thread - Opera’s Morten, Lars and Hakon - have already pointed out, multicolumn based on regions offers a superior approach to the old multicolumn code.

At this point, we feel it is important to discuss a bit about why fragmentation is a hard problem to solve. This is the first question one needs to ask when seeing the numbers that came out of your patch. The answer has its root in the layout model of the engine: one element - one renderer - one box paradigm. Fragmentation brings more complexity to the table: one element - one renderer - multiple boxes (fragments).

The difference between the other layout modules you mention (flexbox and grid) and fragmentation based layout modules is the complexity of having multiple fragments for an element. An implementation handling fragmentation needs to:

- handle fragments of varying width for elements

- determine what content goes in what fragment

- paint those fragments on the screen, isolated from each other

- handle hit-testing in each fragment (it’s no longer enough to know the hit target element, you have to know the hit target fragment as well)

- make existing Web APIs fragmentation aware (e.g. getBoundingClientRects(), events etc.)

- handling weird dependencies between fragment containers caused by the content in one fragment container affecting the content in previous fragment containers

Looking at this list, we think that having about 1.7% of the code size dedicated to fragmentation is actually good news for a layout engine.

Regarding flow threads, they appeared after multiple failed solutions for the fragmentation problem. For example, the multi-column implementation followed a rough path:

- the old implementation - at paint time only, filled with bugs and limitations.

- the current implementation - at layout time and paint time, fixed a lot of issues but the code is intrusive and had some security bugs (https://bugs.webkit.org/show_bug.cgi?id=38402 - see the complexity of the patch)

- the new implementation - it came up as a relatively thin layer on top of RenderFlowThread. Most of the fragmentation complexity of multi-columns is handled by the generic flow thread class.

Flow threads are the most complete and bug free existing solution to fragmentation due to extensive testing, mostly happening while developing regions (which also lead to a lot of code interference).

Therefore, it is our opinion that RenderFlowThreads && co. offer an elegant, unifying solution to fragmentation. There’s surely place for optimisations and code isolation even more than it is today. After reading Blink’s 2014 goals from your email, we’ve started thinking about how we can align Regions to those goals. For starters, we noticed that the compiled code built on top of the CSS Regions foundations, that includes the new multi-column implementation, accounts for only ~300KB of the total 110MB, the size of the Content Shell (on a Mac machine).

We’d be happy to gather more data and continue to see how we can make regions align with Blink’s goals in 2014. The next steps would be to work together to reduce invasiveness and help the core/rendering engineers with their optimisation plans.

 

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.

It would be a real benefit to hear more about the performance optimisations - ongoing and future - that are impacted by regions code.

Specifically about the impact on existing performance optimisations, could you be more specific? We have run the existing performance tests with and without regions and we did not notice any performance regressions.

 

 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.

In the past, we tried our best through blog posts, code samples and presentations (BlinkOn included), to introduce the regions concepts. The problems regions address are complex and we wanted to make sure that regions concepts are understood correctly not only by a few CSS experts but rather by the web communities. Again, I believe that dialog and cooperation are key here to make sure everybody has an informed opinion that is critically important as a base for any future decision.

 

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.

Time will tell whether the proposals you quote are the solution for the problems regions are trying to solve. Implementing fragmentation natively is hard and each proposal will have to deal with its complexity. Again, I pledge to work together for better containment of the code and reduce invasiveness.

Our experiments using a CSS Regions polyfill written in JavaScript showed that on mobile, the polyfill is not a viable alternative for now to the native implementation. 

 

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

We believe that content fragmentation is an important step forward for the web, and that CSS Regions are the building blocks for exposing content fragmentation to web developers. We are happy to work with the Google Blink team to make that possible in Blink without compromising Chrome's performance targets on mobile platforms.

Mihnea Ovidenie and Andrei Bucur,

on behalf of Adobe CSSRegions team

[Adam Barth]

Hi Mihnea,

I think you and Eric are talking past each other to a certain extent.  My understanding of the discussion thus far is as follow:

1) Eric's argument is that Blink's current goals are focused on mobile, particularly mobile performance.  The reason we have a tight focus this year is that the web is behind on mobile and needs to improve substantially in the coming year in order to become a compelling platform on which to write mobile applications.  Regions (and text fragmentation in general) doesn't help support this goal and, because of the complexity it introduces in the codebase, it actually makes it harder for the web to succeed on mobile.

2) If I understand your argument correctly, you're saying that fragmentation is an important part of text layout and that the implementation complexity in Regions is arising because text fragmentation is a complicated problem.  You're arguing that Regions is a good approach to implementing text fragmentation because it's simpler than other approaches and can provide a foundation upon which to build other text fragmentation features, such as multi-column.  Alternatives to Regions aren't sufficient to solve the text fragmentation problem because they are either not sophisticated enough (e.g., Mozilla's Fragments proposal) or they don't perform well enough (e.g., a JavaScript implementation).

Do you see the disconnect between these two arguments?  Eric is arguing that we don't need to solve text fragmentation problem and that our efforts to do so are impeding our overriding goal of improving mobile performance.  You're arguing that Regions is a good solution to the text fragmentation problem.

I understand that you might not have the same goals for Blink in the coming year that Eric does, but my reading of this thread is that's the core of the debate.

Adam