CSS Regions in Blink: status, future work

7,418 views
Skip to first unread message

Mihnea-Vlad Ovidenie

unread,
Nov 20, 2013, 12:29:51 PM11/20/13
to BlinkDev

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

unread,
Jan 16, 2014, 10:00:47 AM1/16/14
to Mihnea-Vlad Ovidenie, BlinkDev
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

unread,
Jan 22, 2014, 8:18:09 AM1/22/14
to blin...@chromium.org
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

unread,
Jan 22, 2014, 12:09:58 PM1/22/14
to Mihnea-Vlad Ovidenie, BlinkDev
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

unread,
Jan 22, 2014, 12:10:51 PM1/22/14
to johann...@gmail.com, blin...@chromium.org
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

unread,
Jan 22, 2014, 12:24:05 PM1/22/14
to Håkon Wium Lie, blin...@chromium.org
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

unread,
Jan 22, 2014, 12:31:26 PM1/22/14
to Håkon Wium Lie, Mihnea-Vlad Ovidenie, BlinkDev


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


tel: +1 (520) 399 8880

Håkon Wium Lie

unread,
Jan 22, 2014, 12:32:12 PM1/22/14
to Johannes Wilm, blin...@chromium.org
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

unread,
Jan 22, 2014, 12:39:51 PM1/22/14
to Håkon Wium Lie, blin...@chromium.org
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

unread,
Jan 22, 2014, 12:43:25 PM1/22/14
to Johannes Wilm, blin...@chromium.org
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

unread,
Jan 22, 2014, 12:51:34 PM1/22/14
to Håkon Wium Lie, blin...@chromium.org
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

unread,
Jan 22, 2014, 1:22:47 PM1/22/14
to Johannes Wilm, blin...@chromium.org
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

unread,
Jan 23, 2014, 6:43:42 AM1/23/14
to Håkon Wium Lie, blin...@chromium.org
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

unread,
Jan 23, 2014, 7:22:38 AM1/23/14
to Johannes Wilm, blin...@chromium.org
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

unread,
Jan 23, 2014, 7:32:45 AM1/23/14
to Håkon Wium Lie, blin...@chromium.org
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

unread,
Jan 23, 2014, 10:07:05 AM1/23/14
to blin...@chromium.org
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

unread,
Jan 23, 2014, 10:11:52 AM1/23/14
to zeljk...@gmail.com, blink-dev
Please refrain from ad hominem arguments and keep the discussion to the technical issues.

Kindly,
Adam

Eric Seidel

unread,
Jan 23, 2014, 2:41:42 PM1/23/14
to Mihnea-Vlad Ovidenie, BlinkDev
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

unread,
Jan 23, 2014, 3:02:55 PM1/23/14
to Eric Seidel, Mihnea-Vlad Ovidenie, BlinkDev
Does this mean that the new CSS columns work will be removed as well?

Bem Jones-Bey

unread,
Jan 23, 2014, 4:49:49 PM1/23/14
to Johannes Wilm, Eric Seidel, Mihnea-Vlad Ovidenie, BlinkDev
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

unread,
Jan 23, 2014, 6:35:02 PM1/23/14
to blin...@chromium.org, Mihnea-Vlad Ovidenie
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

unread,
Jan 24, 2014, 3:20:52 AM1/24/14
to blin...@chromium.org
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

unread,
Jan 24, 2014, 3:50:39 AM1/24/14
to Lars Erik Bolstad, blink-dev
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

unread,
Jan 24, 2014, 3:58:51 AM1/24/14
to PhistucK, Lars Erik Bolstad, blink-dev
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

unread,
Jan 24, 2014, 5:38:09 AM1/24/14
to Hajime Morrita, PhistucK, blink-dev
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

unread,
Jan 24, 2014, 6:05:59 AM1/24/14
to Lars Erik Bolstad, Hajime Morrita, PhistucK, blink-dev
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

unread,
Jan 24, 2014, 6:39:54 AM1/24/14
to Håkon Wium Lie, Lars Erik Bolstad, Hajime Morrita, PhistucK, blink-dev
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

unread,
Jan 24, 2014, 9:31:38 AM1/24/14
to Håkon Wium Lie, Lars Erik Bolstad, Hajime Morrita, PhistucK, blink-dev
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


Mihnea Ovidenie

unread,
Jan 24, 2014, 10:02:54 AM1/24/14
to blin...@chromium.org, Mihnea-Vlad 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

unread,
Jan 24, 2014, 11:22:42 AM1/24/14
to Mihnea Ovidenie, blink-dev, Mihnea-Vlad Ovidenie
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

Johannes Wilm

unread,
Jan 24, 2014, 11:40:28 AM1/24/14
to Adam Barth, Mihnea Ovidenie, blink-dev, Mihnea-Vlad Ovidenie
Hey,

as for these goals, are they published anywhere on beforehand? If someone else is to try to implement anything with fragmenting some time in the future, they will likely have to spend as long as the CSS Region team to get the code into production quality level -- meaning years. But if Chromium sets the goals for Blink on a yearly basis, throwing out anything that isn't a 100% fit for their short-term strategy, then it seems like it will be quite a huge risk to try to start projects of that magnitude for anyone else than those making decisions within the Chromium team. 

Now this will hit hard on Adobe and Opera, yet Håkon's complaints about CSS Regions were the initial argument for this action. It seemed his argument was build around the idea that his "CSS Generated Content for Paged Media Module"specification would be better, yet the decision to throw out items that are not part of the short-term plan seems to make it impossible to try to implement this in the future as well.

 So my question is: Will you release something like a preliminary five year plan of objectives for the next few years?

ste...@601t.com

unread,
Jan 24, 2014, 11:42:22 AM1/24/14
to blin...@chromium.org, Mihnea Ovidenie, Mihnea-Vlad Ovidenie
Adam,

That's a clarifying way to look at this thread, but I think things are a bit muddier than you present them. If fragmentation is too complex to maintain for mobile, does that mean Blink will be pulling out all of the multicolumn and printing code as well? That would be a bold move, and I expect would get you farther along towards your performance goal than merely taking out the regions code.

If not, I think you should consider cutting the old multicol and printing code instead of the regions code. From all I have heard, the new multicol and printing based on regions is much less buggy and should be easier to maintain.

Adam Barth

unread,
Jan 24, 2014, 11:47:51 AM1/24/14
to Johannes Wilm, Mihnea Ovidenie, blink-dev, Mihnea-Vlad Ovidenie
On Fri, Jan 24, 2014 at 8:40 AM, Johannes Wilm <ma...@johanneswilm.org> wrote:
as for these goals, are they published anywhere on beforehand?

 
If someone else is to try to implement anything with fragmenting some time in the future, they will likely have to spend as long as the CSS Region team to get the code into production quality level -- meaning years. But if Chromium sets the goals for Blink on a yearly basis, throwing out anything that isn't a 100% fit for their short-term strategy, then it seems like it will be quite a huge risk to try to start projects of that magnitude for anyone else than those making decisions within the Chromium team.

In the past, we haven't had as narrow a focus as we have this year.  Instead, we've taken the approach of encouraging innovation by letting a thousand flowers bloom.  I don't think that's a good approach this year because the world is changing rapidly and we need to adapt.

Now this will hit hard on Adobe and Opera, yet Håkon's complaints about CSS Regions were the initial argument for this action. It seemed his argument was build around the idea that his "CSS Generated Content for Paged Media Module"specification would be better, yet the decision to throw out items that are not part of the short-term plan seems to make it impossible to try to implement this in the future as well.

So my question is: Will you release something like a preliminary five year plan of objectives for the next few years?

I don't think we've written out objectives for five years in the future.  If we had written five-year objectives four years ago, I doubt they'd correctly anticipate which problems are important to solve today.

Johannes Wilm

unread,
Jan 24, 2014, 12:13:18 PM1/24/14
to Adam Barth, Mihnea Ovidenie, blink-dev, Mihnea-Vlad Ovidenie
On Fri, Jan 24, 2014 at 5:47 PM, Adam Barth <aba...@chromium.org> wrote:
On Fri, Jan 24, 2014 at 8:40 AM, Johannes Wilm <ma...@johanneswilm.org> wrote:
as for these goals, are they published anywhere on beforehand?

Eric linked to them in his post:


Yes, I had seen those. But those were published in 2014. You are Chromium, so you can afford doing that, but it also sends out a clear message that it's dangerous for others to work on anything big for Chromium. Right now you have a process through which one can apply to ship things in Blink. That process didn't exist at the time the CSS region work started (before the split from Webkit), and given that web development is speeding up up, no-one can say for sure if the process will be the same in the future. If someone starts working on a fragmentation implementation in early 2015 and has something ready to be shipped in late 2017, there is a good chance that the procedures from 2015 will have been exchanged for new ones.
 

 
If someone else is to try to implement anything with fragmenting some time in the future, they will likely have to spend as long as the CSS Region team to get the code into production quality level -- meaning years. But if Chromium sets the goals for Blink on a yearly basis, throwing out anything that isn't a 100% fit for their short-term strategy, then it seems like it will be quite a huge risk to try to start projects of that magnitude for anyone else than those making decisions within the Chromium team.

In the past, we haven't had as narrow a focus as we have this year.  Instead, we've taken the approach of encouraging innovation by letting a thousand flowers bloom.  I don't think that's a good approach this year because the world is changing rapidly and we need to adapt.

The world is changing ever faster at least since the industrial revolution, if not centuries before that. Of course mobile is important in 2014, as something else will be in the year after that and something else in the year after that. Since it's now only Chromium Blink (and not Apple) that's behind the decisions of prioritization, the focus can be made much narrower than what it used to be in the old model. But using that logic, what guarantee does a team starting on fragmentation in a year have that their work won't be thrown out when in 2017 it is determined that browsing from ascii terminals is the priority of the year and everything else has to go?
 

Now this will hit hard on Adobe and Opera, yet Håkon's complaints about CSS Regions were the initial argument for this action. It seemed his argument was build around the idea that his "CSS Generated Content for Paged Media Module"specification would be better, yet the decision to throw out items that are not part of the short-term plan seems to make it impossible to try to implement this in the future as well.

So my question is: Will you release something like a preliminary five year plan of objectives for the next few years?

I don't think we've written out objectives for five years in the future.  If we had written five-year objectives four years ago, I doubt they'd correctly anticipate which problems are important to solve today.

I agree, that would be difficult. But if there are no objectives several year before AND you have no scruples throwing out large contributions that have taken years of development due to one-year goals, then I have a hard time seeing how anyone can cooperate with you guys on projects of this magnitude.

Mihnea Ovidenie

unread,
Jan 24, 2014, 12:28:30 PM1/24/14
to blin...@chromium.org, Mihnea Ovidenie, Mihnea-Vlad Ovidenie
Hi Adam,

Thank you for your clean summary.


On Friday, January 24, 2014 6:22:42 PM UTC+2, Adam Barth wrote:
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.

We are trying to understand precisely how text fragmentation is impeding the mobile performance. We sincerely believe we can help achieve both mobile performance and fragmentation in Blink.
 
 You're arguing that Regions is a good solution to the text fragmentation problem.


Cheers,
M.

PhistucK

unread,
Jan 24, 2014, 1:06:17 PM1/24/14
to Johannes Wilm, Adam Barth, Mihnea Ovidenie, blink-dev, Mihnea-Vlad Ovidenie
I think one of the biggest issues with such implementations is the complexity factor. CSS Regions, specificially, complicates the core code much more than others (if I understand correctly).
If it were a big feature that is pretty modular and self contained, it would have probably not been a problem.


PhistucK


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

Ethan Malasky

unread,
Jan 24, 2014, 1:25:28 PM1/24/14
to Eric Seidel, Mihnea-Vlad Ovidenie, BlinkDev
Hi Eric —


On Jan 23, 2014, at 11:41 AM, Eric Seidel <ese...@chromium.org> wrote:

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

For a more complete picture, I’ll note that Microsoft shipped an earlier draft of the feature back in IE10, and Apple shipped a modern implementation, based on the same WebKit code that Blink inherited, on iOS7 (Sept 2013) and Mavericks.

Are you suggesting that the negative opinions of two individual working group members should outweigh the positive opinions of two other browser vendors, as indicated by their shipping software?

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

These are all fine justifications for technical requests to address the complaints that have been brought to your attention. But turning them into justifications to preemptively decide that a feature should not be shipped is an inappropriate leap. Have the core rendering engineers already asked for Regions code to be refactored to play better with existing optimizations and to enable ongoing core work? If not, why not?

Are there already specific simplification and optimization projects that the core rendering engineers are considering? Can you share the details? Without something concrete to consider, it’s not possible to make a clear, informed technical decision.

<snip>

thanks,
-Ethan

Håkon Wium Lie

unread,
Jan 24, 2014, 5:50:52 PM1/24/14
to Adam Barth, Lars Erik Bolstad, Hajime Morrita, PhistucK, blink-dev
Adam Barth wrote:

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

It should be possible to make compelling ebook readers in browsers. To
do so, multicol support is needed; in landscape mode tablets are too
wide for single-column reading. If you have Opera 12.16 (or
thereabouts) handy, try visiting this page to see how the book
automatically adapts the number of columns to the screen size:

http://www.wiumlie.no/2014/reader/aiw/

On-screen pagination is also important for ebooks -- try PgDn and PgUp
to move between pages.

> My understanding is that we don't need all the complexity of Regions to
> implement multicolumn.

Certainly, from the specification side of things, the two are
separate. I prefer the multicol model for a number of reasons [2].

[2] http://alistapart.com/blog/post/css-regions-considered-harmfulImplementation-wise

> For example, could we use something more like
> Fragments [1], where the implementation of the feature would be more
> self-contained?

How intrusive the fragmentation code needs to be is not for me to say.
But it makes sense to try reuse the fragmentation code instead of,
say, having two different implementations for multicol and pagination.

> To avoid confusion, I'd note that we've already shipped multicolumn, which
> means we're reticent to remove the feature.

That's good to hear. It needs some TLC, but I think its an important
feature if we want the web to include books and magazines.

Dirk Schulze

unread,
Jan 24, 2014, 8:50:21 PM1/24/14
to PhistucK, Johannes Wilm, Adam Barth, Mihnea Ovidenie, blink-dev, Mihnea-Vlad Ovidenie

On Jan 24, 2014, at 10:06 AM, PhistucK <phis...@gmail.com> wrote:

> I think one of the biggest issues with such implementations is the complexity factor. CSS Regions, specificially, complicates the core code much more than others (if I understand correctly).
> If it were a big feature that is pretty modular and self contained, it would have probably not been a problem.

As Mihnae mentioned before, ~80% of the 10k LOC are dealing with CSS Fragmentation. CSS Fragmentation is a different specification and is reused by many specifications including CSS Multi-Column, CSS-Regions and CSS-Pagination. Removing the 10k LOC would just mean that Fragmentation gets removed and needs to be reimplemented. That is a concern raised not only by the Web Platform team of Adobe.

Of course I do not count as neutral, but in my honest opinion the CSS Regions code (including the fragmentation code) seems to be very clear and well structured. And I have to admit that it was the first time that I actually looked closer into the regions code. For this reason I want to thank Eric very much for his efforts. It makes it much easier to understand the implementation and the implications that goes hand in hand with regions. I still come to the opposite conclusion to Eric’s.

Eric, unless you don’t want continue shipping a broken CSS Multi-column implementation in Chrome an Android, major efforts need to be invested to fix the code without the regions implementation. Removing code is one thing, spending the efforts to create a compelling alternative is an entirely different problem. If I interpret Adam correctly, there is no intention to improve the Android implementation of CSS Multi-column. I consider this a major problem for the web and *especially* the mobile web. If implementations are neither reliable nor interoperable, the mobile web based on open web technologies won't exist for long.

Greetings,
Dirk

Takeshi Kurosawa

unread,
Jan 25, 2014, 11:07:42 AM1/25/14
to BlinkDev
Hi,

Current CSS Regions implementation breaks accessibility object trees.
Because they basically traverse render trees and render trees are
slightly different from DOM trees.

This will cause problems for screen reader users.
Please fix this issue before shipping CSS Regions.

Order of Accessibility Objects is broken by CSS Regions
https://code.google.com/p/chromium/issues/detail?id=293023

Example: http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/regions/counters/extract-list-items-001.html

When CSS Regions is disabled, accessibility tree will be something like:

list
- list item
... snip ...
list
- list item
... snip ...
div
div

When CSS Regions is enabled, accessibility tree will be something like:

list
list
div
- list item
... snip ...
div
- list item
... snip ...

# In fact, accessibility objects corresponding div elements are
ignored (not exposed to screen readers) in this case.
.
Takeshi Kurosawa.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.



--
Takeshi Kurosawa <take...@gmail.com>

Dirk Schulze

unread,
Jan 25, 2014, 2:57:37 PM1/25/14
to Takeshi Kurosawa, BlinkDev

On Jan 25, 2014, at 8:07 AM, Takeshi Kurosawa <take...@gmail.com> wrote:

> Hi,
>
> Current CSS Regions implementation breaks accessibility object trees.

The opposite is the case!

> Because they basically traverse render trees and render trees are
> slightly different from DOM trees.

That is correct and that makes regions accessible! Because of that, you can actually structure your content, keep the content in a flow which makes it much more accessible. As a bonus you have the full freedom to design your page/magazine as you like! You have by far not these opportunities with normal floats.The only CSS layout that allows something in this direction is Flexbox. With Flexbox you can reorder your render tree, even if the DOM tree stays out of context. This allows a much better experience for screen reader users.

And of course there are ways to badly violate these possibilities. This is true for any CSS layout - independent if floats, Flexbox or Regions. You just attached one of these bad abuses of layout where you add the list items to the regions instead of the list itself.

But exactly what you criticize on regions is the way it is done with floats quite often today. For some web pages the design has a higher priority than the content flow. This is wrong! I expect Regions to be a huge improvement for accessibility and avoid exactly that.

Greetings,
Dirk

Eric Seidel

unread,
Jan 25, 2014, 7:13:56 PM1/25/14
to Dirk Schulze, PhistucK, Johannes Wilm, Adam Barth, Mihnea Ovidenie, blink-dev, Mihnea-Vlad Ovidenie
As noted in the previous goals discussion [1], we perceive an urgent
need to improve Blink on mobile, necessitating focus there. Focus
means not doing things.

For cross-cutting features like Regions, the cost to the project
scales quadratically -- each additional feature interacts with every
other feature and has a cost proportional to the number of other
features in Blink. A tiny example of this came up this week when Adam
removed <iframe seamless>. Removing seamless also removed several
call-sites which existed just to teach seamless and Regions to play
nice together [2].

I have spoken with the most active contributors/maintainers of
core/rendering and the sentiment was that they do not see Regions on
the critical path to mobile success or want its complexity in the
codebase. I’m sorry. I wish we had communicated better as Regions
developed (or the market changed) to avoid this surprise.


Dirk (and Mihnea and Morten) wrote:
> As Mihnae mentioned before, ~80% of the 10k LOC are dealing with CSS Fragmentation.

I suspect that you’re right that a large part of the complexity cost
of Regions comes from CSS Fragmentation.

I expect the rendering maintainers would like to remove multi-column
and fragmentation complexity as well. Multi-column’s 2% usage [3]
seems low to justify its cost. However, since we’ve shipped
-webkit-column* and 2% is above our removal threshold [4] I can’t see
us easily removing multi-column. I certainly would welcome
simplification of our multi-column down to a single implementation,
but that implementation should ideally cost us the same or less than
the low-usage one we’ve had for years.

If Opera sees multi-column as being on the critical path to success
for mobile, and has interest in maintaining more of the core/rendering
code and reducing multi-column’s complexity in Blink, I could get
behind that.


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

I’m very glad to hear that. Chrome and Opera’s goals seem rather
fantastically well aligned about making the mobile web awesome. I
believe where our opinions may differ is about what the complexity
cost of regions/fragmentation code is and if it’s close enough to
Blink’s critical path towards mobile awesomeness to justify its cost.


Ethan wrote:
> Are you suggesting that the negative opinions of two individual working group members should outweigh
> the positive opinions of two other browser vendors, as indicated by their shipping software?

I hold huge respect for the opinions of both Dave Baron and Hakom and
trust them to have a better understanding of CSS specs than I do. I
cite their opposition as examples that the dust has not settled on
text fragmentation. I don’t believe I have a lot of value to add in
choosing the right text fragmentation spec, and I don’t think Blink
should commit to shipping (and indefinitely maintaining) a text
fragmentation system at this time. We inherited this one from Apple’s
WebKit, we can write/port one at a later time if our users/developers
on the mobile web demand it.


Hakom wrote:
> It should be possible to make compelling ebook readers in browsers.

My goal is to make the mobile web platform successful. In so far as
ebook readers may be a popular class of mobile applications (that’s
not clear to me? [5]), I am interested in supporting their success on
the mobile web platform. We also have to be careful to weigh the
benefits to one class of applications with the cost the code to
support them imposes on the entire platform. Right now Blink is full
of many low-usage [6], high-cost features which we perhaps could
afford on Desktop but are hurting us with their compounding-complexity
on Mobile.


On a separate note: I do not believe Blink needs to build-in as
powerful a layout engine as may be possible for print media. I see
WebKit as often being embedded as a text-layout-engine, almost as a
competitor to LaTeX. However, I think Blink (and the web platform)
should empower developers to build powerful applications, but should
not necessarily favor one class of applications over another by
embedding special-case logic in its core. Browsers, as we’re all well
aware, stopped just being document viewers long ago.


To move forward, I propose:
- Work with Adobe to remove CSS Regions from the Blink on a timeframe
which is compatible with their branching needs, etc.
- Work with Opera to understand their short-term needs for
multi-column, if they believe CSS Fragmentation is necessary for
multi-column/blink-mobile-success and if they’re ready to assist in
better integrating and maintaining that code going forward. If not,
then work with Opera and Adobe to remove CSS Fragmentation as well.


There is also possibly more discussion to be had between the advocates
of these features and the the current maintainers of core/rendering.
I’m only one voice there, so perhaps I should stand out of the way and
let those folks talk. But as it stands, I do not see us shipping CSS
Regions or its dependent CSS Fragmentation and thus both should be
removed from Blink.


Sincerely,
Eric Seidel

1. https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Z5OzwYh3Wfk/IWooaY5FZowJ
2. https://codereview.chromium.org/138443013/patch/40001/50115
3. http://www.chromestatus.com/metrics/css/timeline/popularity/218
4. https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/bs3NIiqnc8Q/2kF7HNr4kSAJ
5. http://blog.flurry.com/bid/95723/Flurry-Five-Year-Report-It-s-an-App-World-The-Web-Just-Lives-in-It
6. http://www.chromestatus.com/metrics/css/popularity

Alan Stearns

unread,
Jan 26, 2014, 3:18:03 AM1/26/14
to blin...@chromium.org, Dirk Schulze, PhistucK, Johannes Wilm, Adam Barth, Mihnea Ovidenie, Mihnea-Vlad Ovidenie
Eric,

Your last message appears a little confused to me about the relationship between fragmentation, multicolumn and regions, at least on the specification side.

CSS Break is the fragmentation spec. It describes a consistent fragmentation model for everything - printing, multicolumn and regions. There is no debate about which fragmentation spec to use. CSS Break is the specification all browsers should be following for all fragmentation systems they ship.

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.

Thanks,

Alan

David Hyatt

unread,
Jan 26, 2014, 12:42:27 PM1/26/14
to blin...@chromium.org, Dirk Schulze, PhistucK, Johannes Wilm, Adam Barth, Mihnea Ovidenie, Mihnea-Vlad Ovidenie
As others have mentioned, the intent behind writing a new multi-column implementation on top of RenderRegion/RenderFlowThread was to use the capabilities of those classes to add some features to multi-column layout (namely the ability to have variable width columns, column styling, nested columns inside pages, better column spans, etc.). In other words RenderRegion at this point is really just a fragment container, and RenderFlowThread is just the renderer that flows through the fragments.

So there are three categories of code here:

(1) Renderers for fragmentation that are moving in a generic direction, i.e., that will ultimately be used for multi-column, paginated overflow, printing, and any other places where the engine would fragment flows. When considering the cost of this code, remember that when complete, you actually get to subtract the old multi-column code and a bunch of printing code.

(2) Multi-column code - New multi-column code built on top of (1).

(3) CSS Regions code - Code specific to named flows, CSS Regions spec., etc.

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.

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.

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.

Adam Barth

unread,
Jan 26, 2014, 1:38:55 PM1/26/14
to David Hyatt, blink-dev, Dirk Schulze, PhistucK, Johannes Wilm, Mihnea Ovidenie, Mihnea-Vlad Ovidenie, Alan Stearns
On Sun, Jan 26, 2014 at 12:18 AM, Alan Stearns <famu...@gmail.com> wrote:
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.

On Sun, Jan 26, 2014 at 9:42 AM, David Hyatt <daveh...@gmail.com> wrote:
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.

Adam

Dirk Schulze

unread,
Jan 26, 2014, 4:19:45 PM1/26/14
to Adam Barth, David Hyatt, blink-dev, PhistucK, Johannes Wilm, Mihnea Ovidenie, Mihnea-Vlad Ovidenie, Alan Stearns

On Jan 26, 2014, at 10:38 AM, Adam Barth <aba...@chromium.org> wrote:

> 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:
>
> https://code.google.com/p/chromium/issues/list?q=Hotlist%3DJank

The question that was asked multiple times before: How do you identify the regions code as a problem for performance? Eric created a patch that removed the Regions/Fragmentation code. So he should be able to provide performance data. Since your arguments are about performance you clearly must have done the necessary measurements.

Eric stated that the Google Blink team is neither interested in multicolumn, pages nor fragmentation. So it is especially interesting to know how the Regions/Fragmentation code actually affects performance of code paths negatively that are not even using it (as you imply).

Greetings,
Dirk

PhistucK

unread,
Jan 26, 2014, 4:19:35 PM1/26/14
to Adam Barth, David Hyatt, blink-dev, Dirk Schulze, Johannes Wilm, Mihnea Ovidenie, Mihnea-Vlad Ovidenie, Alan Stearns
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.


PhistucK

Elliott Sprehn

unread,
Jan 26, 2014, 5:52:19 PM1/26/14
to Adam Barth, David Hyatt, blink-dev, Dirk Schulze, PhistucK, Johannes Wilm, Mihnea Ovidenie, Mihnea-Vlad Ovidenie, Alan Stearns
On Fri, Jan 24, 2014 at 10:25 AM, Ethan Malasky <emal...@adobe.com> wrote:
[...]

On Jan 23, 2014, at 11:41 AM, Eric Seidel <ese...@chromium.org> wrote:

[...]

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

For a more complete picture, I’ll note that Microsoft shipped an earlier draft of the feature back in IE10, and Apple shipped a modern implementation, based on the same WebKit code that Blink inherited, on iOS7 (Sept 2013) and Mavericks.

MS shipped a subset of functionality that only works with iframes in IE10, and didn't make any improvements in IE11 even though it shipped a year and a half later. MS doesn't even support region styling, and webkit derived browsers that do support it still have the old (and since removed from the spec) @-webkit-region instead of ::region.

On Sun, Jan 26, 2014 at 10:38 AM, Adam Barth <aba...@chromium.org> wrote:
On Sun, Jan 26, 2014 at 12:18 AM, Alan Stearns <famu...@gmail.com> wrote:

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 would also like to argue that some of the features of CSS Fragmentation are not relevant for the vast majority of real world content and we should never support them. Specifically the ability to split arbitrary boxes across variable width containers is not something that I find magazines, document printing, or native frameworks actually do and it introduces lots of complexity. It also produces counter intuitive behavior like http://jsfiddle.net/6xXFg/ where the flex box is painted three times with three different widths, but the flex items are not. I think we should seek to have this feature removed from multi column as well, which would similarly reduce the complexity cost of the multi column code in blink.

In blink we're pushing for simpler primitives that empower developers to build frameworks and applications. In that spirit we do not believe that use cases like dynamically moving menu items when the window resizes using regions make sense. It's fine if developers need to write some script for that, we're building an application platform, not a document viewer.


On Sun, Jan 26, 2014 at 9:42 AM, David Hyatt <daveh...@gmail.com> wrote:
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.

A major difference is that printing is to all same sized fragments.

On Sat, Jan 25, 2014 at 4:13 PM, Eric Seidel <ese...@chromium.org> wrote:
[...]

On a separate note: I do not believe Blink needs to build-in as
powerful a layout engine as may be possible for print media.  I see
WebKit as often being embedded as a text-layout-engine, almost as a
competitor to LaTeX.  However, I think Blink (and the web platform)
should empower developers to build powerful applications, but should
not necessarily favor one class of applications over another by
embedding special-case logic in its core.  Browsers, as we’re all well
aware, stopped just being document viewers long ago.

I agree, we need to focus on building a high performance application platform and not just a document viewer. Doing so means providing primitives and expecting developers to use libraries instead of baking everything into the platform. Similarly it means making hard decisions about what's important. 
 

To move forward, I propose:
- Work with Adobe to remove CSS Regions from the Blink on a timeframe
which is compatible with their branching needs, etc.

I agree, at this time we need to focus on simplifying and improving the performance of the painting and layout system as much as possible.

I do not believe the complexity that RenderLayer has sprouted for painting region based multi column, the logic inside RenderTreeBuilder to deal with nested flow threads or the complexity introduced into paint so that blocks can be painted several times at different widths is something we want at this time. I do not think the complexity we would need to add to make regions work with Shadow DOM is worth it either. I also think supporting this complex painting model will make future plans to revamp the painting system with things like SkPicture per renderer, or display lists more difficult. Encouraging developers to use features like regions also goes against our goal of making sure features only have local effects, and that when changing the style of elements the resulting layouts are as small, fast and localized as possible.

- Work with Opera to understand their short-term needs for
multi-column, if they believe CSS Fragmentation is necessary for
multi-column/blink-mobile-success and if they’re ready to assist in
better integrating and maintaining that code going forward.  If not,
then work with Opera and Adobe to remove CSS Fragmentation as well.


I would like to see us choose a simpler path than the current CSS Break spec is requiring. In the short term I think we should move development of CSS Fragmentation to a branch if Opera wishes to continue developing it, unless we can find a path to making sure the system is self contained, which seems unlikely given the block splitting model the spec proposes. At a time when we change our focus toward advanced text layout features we can evaluate merging the branch into core.

I think such an exercise will also be enlightening. Just like with Oilpan where they experimented with many different tactics in a branch, we evaluated the complexity and the gains, and then decided to move forward on trunk.

Had we gone through this exercise for regions and fragmentation I'm not sure we would have accepted the complexity back into trunk, at least not given the current climate.


[...] But as it stands, I do not see us shipping CSS

Regions or its dependent CSS Fragmentation and thus both should be
removed from Blink.


Given the complexity the implementation brings to the project and its mismatch with our goals and priorities, I believe we should remove the code from trunk and revisit this issue in the future.

- E

David Hyatt

unread,
Jan 26, 2014, 6:18:53 PM1/26/14
to blin...@chromium.org, Adam Barth, David Hyatt, Dirk Schulze, PhistucK, Johannes Wilm, Mihnea Ovidenie, Mihnea-Vlad Ovidenie, Alan Stearns
On Sunday, January 26, 2014 4:52:19 PM UTC-6, Elliott Sprehn wrote:
I would also like to argue that some of the features of CSS Fragmentation are not relevant for the vast majority of real world content and we should never support them. Specifically the ability to split arbitrary boxes across variable width containers is not something that I find magazines, document printing, or native frameworks actually do and it introduces lots of complexity.

This occurs quite regularly. It's even a desired feature of printing (the ability to have landscape pages for figures, etc. mixed in with portrait pages). It occurs regularly in magazines as well with both spans and sidebars.

It also produces counter intuitive behavior like http://jsfiddle.net/6xXFg/ where the flex box is painted three times with three different widths, but the flex items are not. I think we should seek to have this feature removed from multi column as well, which would similarly reduce the complexity cost of the multi column code in blink.


Variable width columns aren't supported in the old or new multi-column code. The flow thread/region code makes it possible, but it isn't implemented in either the old or new code.
 
In blink we're pushing for simpler primitives that empower developers to build frameworks and applications. In that spirit we do not believe that use cases like dynamically moving menu items when the window resizes using regions make sense. It's fine if developers need to write some script for that, we're building an application platform, not a document viewer.


I guess that's where there's just a fundamental disconnect. You don't care about viewing books/magazines on a tablet I guess. That seems very short-sighted to me, but maybe you don't consider tablets to be mobile.
 

A major difference is that printing is to all same sized fragments.


Only right now. People would like to be able to specify different rules for individual pages.
 
I do not believe the complexity that RenderLayer has sprouted for painting region based multi column,

You realize the old multi-column code has a bunch of stuff in RenderLayer also? The new multi-column RenderLayer code is required just to have a painting/stacking-compliant multi-column model. All other browsers besides WebKit and Blink get that right. Obviously the old multi-column code could be removed from RenderLayer as well once the new code is ready.

The new multi-column code doesn't carry significantly more complexity or cost than the old code, yet you want to keep the old code but dump the new code. This doesn't make much sense to me. If the new code was vastly more complicated or something, than I could see that, but if anything, it's simpler and easier to understand than the old code, and it's much less intrusive into RenderBlock/BlockFlow than the old multi-column code.

It seems like you're basically saying that multi-column is so unimportant that you don't even want to let people fix bugs with it (e.g., the RenderLayer code necessary to get the painting/stacking right). If that's the case, then you should just remove the feature completely. Leaving it in but refusing to let anyone improve it is just bizarre.

Adam Barth

unread,
Jan 26, 2014, 8:33:44 PM1/26/14
to David Hyatt, blink-dev, Dirk Schulze, PhistucK, Johannes Wilm, Mihnea Ovidenie, Mihnea-Vlad Ovidenie, Alan Stearns
On Sun, Jan 26, 2014 at 3:18 PM, David Hyatt <daveh...@gmail.com> wrote:
On Sunday, January 26, 2014 4:52:19 PM UTC-6, Elliott Sprehn wrote:
In blink we're pushing for simpler primitives that empower developers to build frameworks and applications. In that spirit we do not believe that use cases like dynamically moving menu items when the window resizes using regions make sense. It's fine if developers need to write some script for that, we're building an application platform, not a document viewer.

I guess that's where there's just a fundamental disconnect. You don't care about viewing books/magazines on a tablet I guess. That seems very short-sighted to me, but maybe you don't consider tablets to be mobile.

It's important to understand that Blink has different goals than WebKit.  It's not that I don't care about viewing books or magazines, it's that I'm more interested in making the web a compelling platform for applications.

Obviously, not everyone agrees with that view.  Some people believe applications should be written in Cocoa and documents should be written in HTML.  That's a perfectly reasonably viewpoint.  It's just not one that I share.  Instead, I'd like to make the web a more compelling application platform than Cocoa.

We have a lot of work ahead of us to make that a reality.  If you share these goals, we'd more than welcome your help.

Adam

Ojan Vafai

unread,
Jan 27, 2014, 8:01:52 PM1/27/14
to David Hyatt, blink-dev, Adam Barth, Dirk Schulze, PhistucK, Johannes Wilm, Mihnea Ovidenie, Mihnea-Vlad Ovidenie, Alan Stearns
On Sun, Jan 26, 2014 at 3:18 PM, David Hyatt <daveh...@gmail.com> wrote:
On Sunday, January 26, 2014 4:52:19 PM UTC-6, Elliott Sprehn wrote:
I would also like to argue that some of the features of CSS Fragmentation are not relevant for the vast majority of real world content and we should never support them. Specifically the ability to split arbitrary boxes across variable width containers is not something that I find magazines, document printing, or native frameworks actually do and it introduces lots of complexity.

This occurs quite regularly. It's even a desired feature of printing (the ability to have landscape pages for figures, etc. mixed in with portrait pages). It occurs regularly in magazines as well with both spans and sidebars.

I'm not so concerned about the printing case. If we solve all the problems for books/magazines except print fidelity, I think we're in a good place.

The question is how often this occurs in books/magazines. I played with a ton of books and magazine apps on iOS today to try to get an intuition and I couldn't find any that couldn't be implemented with a combination of fixed-width pages/regions + exclusions (using exclusions for the side-bars). The thing this would disallow is having a block of text with a background color that spans multiple pages (e.g. we'd make any blocks with background-color, border, transform, etc not be breakable). While I can conceive of use-cases for that, maybe they don't justify the implementation complexity. 

I do not believe the complexity that RenderLayer has sprouted for painting region based multi column,

You realize the old multi-column code has a bunch of stuff in RenderLayer also? The new multi-column RenderLayer code is required just to have a painting/stacking-compliant multi-column model. All other browsers besides WebKit and Blink get that right. Obviously the old multi-column code could be removed from RenderLayer as well once the new code is ready.

The new multi-column code doesn't carry significantly more complexity or cost than the old code, yet you want to keep the old code but dump the new code. This doesn't make much sense to me. If the new code was vastly more complicated or something, than I could see that, but if anything, it's simpler and easier to understand than the old code, and it's much less intrusive into RenderBlock/BlockFlow than the old multi-column code.

It seems like you're basically saying that multi-column is so unimportant that you don't even want to let people fix bugs with it (e.g., the RenderLayer code necessary to get the painting/stacking right). If that's the case, then you should just remove the feature completely. Leaving it in but refusing to let anyone improve it is just bizarre.

In a world in which we were keeping Regions, it would of course make sense to try to complete the new multi-column implementation. Lacking that, I think if we got patches that improve the old multi-column code that we'd accept them. Although, it is certainly not anywhere on our list of priorities to improve it at the moment. 

Julien Chaffraix

unread,
Jan 28, 2014, 2:04:30 PM1/28/14
to PhistucK, Adam Barth, David Hyatt, blink-dev, Dirk Schulze, Johannes Wilm, Mihnea Ovidenie, Mihnea-Vlad Ovidenie, Alan Stearns
> 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.

Note that the complexity argument has been brought up several times on
the standard's mailing list so it's not anything new. The root cause
is that region allows a many-to-many mapping between content and
renderers.

While I don't follow the standard's body closely, there has been at
least a counter proposal with more simple primitives which seemed to
satisfy the different people more.

Now I will just talk about our implementation: the feature is invasive
because every renderer has to be made aware of region. Also most of
the complexity is in rendering/ which is an area where we already have
a lot of complexity to deal with (continuations, crazy anonymous
wrapping, RenderLayer, ...). That's why I consider the 1% estimate in
code size to be irrelevant as the complexity is in an area where we
would like to reduce it further. We also know this complexity is
causing some slowness (e.g. [1] or just layout is known to be super
slow) and is definitely a burden on contributors (just in terms of
cognitive loads, ask anyone who did a rendering change). Unfortunately
I don't think we have good metrics for complexity that would give us a
finer grained answer.

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

The talk about regions has been going on back-and-forth for a while
(at least a year). We met several times and raised some issues at the
time, which I don't think were solved (like what happened to fragment
on top of regions?)

Where I think we fell short is that we didn't pick a line of action
early on and thus let the expectations rise. What I mean is that most
of us were neutral to the feature, mostly because we didn't take the
time to understand the feature, what implementing it would entail, ...
I know I have been culprit of that and should have picked up a camp,
instead of letting the situation - and code - proceed further.

I think you are making a generalization out of this single event. We
inherited the code from WebKit and showed a bad record of handling it
for which we apologize - while I cannot speak for anyone on the team,
the ones I talked to definitely feel we could have done better.

Julien

[1] https://code.google.com/p/chromium/issues/detail?id=325486

Johannes Wilm

unread,
Jan 28, 2014, 2:14:22 PM1/28/14
to Julien Chaffraix, PhistucK, Adam Barth, David Hyatt, blink-dev, Dirk Schulze, Mihnea Ovidenie, Mihnea-Vlad Ovidenie, Alan Stearns
Hey again,

Ok, given that there won't be understanding on this issue, how about making it easier to do this in Javascript? The most obvious thing it seems would help would be a simple way for the Javascript to have access to information about how much of a text (or element with subnodes) fits into a container without causing overflow. A second, less essential, piece of information would be where line breaks occur. Without this information available, javascript developers (like me) will have to try letter by letter exactly how much they can put into a container without causing overflow.

Without knowing the specifics of the sources, I would imagine that this information is available internally anyway, so exposing it to the Javascript shouldn't hurt performance much.

Chris Harrelson

unread,
Jan 28, 2014, 2:46:40 PM1/28/14
to Johannes Wilm, Julien Chaffraix, PhistucK, Adam Barth, David Hyatt, blink-dev, Dirk Schulze, Mihnea Ovidenie, Mihnea-Vlad Ovidenie, Alan Stearns
On Tue, Jan 28, 2014 at 11:14 AM, Johannes Wilm <ma...@johanneswilm.org> wrote:
Hey again,

Ok, given that there won't be understanding on this issue, how about making it easier to do this in Javascript? The most obvious thing it seems would help would be a simple way for the Javascript to have access to information about how much of a text (or element with subnodes) fits into a container without causing overflow. A second, less essential, piece of information would be where line breaks occur. Without this information available, javascript developers (like me) will have to try letter by letter exactly how much they can put into a container without causing overflow.

Without knowing the specifics of the sources, I would imagine that this information is available internally anyway, so exposing it to the Javascript shouldn't hurt performance much.

I think this is a promising approach, and compatible with the extensible web philosophy as well. Given such primitives, it should be straightforward to implement javascript libraries that perform responsive layout for many if not all common cases.

I agree that CSS Regions in all its complexity is a significant risk and burden, and one that it looks like we can't afford right now. In particular, I agree with the arguments about the many-to-many mapping and its implications for the Blink code, as well as the fact that some pieces of the web API surface don't seem to have a well-defined interpretation in that world. (This latter point was raised last week on a standards list as well.)

However, I can definitely see the need for being able to flow text through multiple nodes, and it being an important use case for next-gen UIs of information-centric pages/apps like newspapers, blogs, magazines, encyclopedias and e-readers. This is important because a whole lot of the web's information content is in those kind of sites.

I'm not sure about the points raised about "region-based" multi-column. If that is close to done, it sounds like a targeted effort to finish it and delete the old code would be a win. I'd propose as a next step that someone write up a document outlining what steps remain, and why the code at the end would be better than today in terms of correctness and complexity.

Chris
 

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

Morten Stenshorne

unread,
Jan 29, 2014, 9:06:25 AM1/29/14
to Chris Harrelson, Johannes Wilm, Julien Chaffraix, PhistucK, Adam Barth, David Hyatt, blink-dev, Dirk Schulze, Mihnea Ovidenie, Mihnea-Vlad Ovidenie, Alan Stearns
I reported the following bug to get the "region-based" multicol
implementation shippable (by making at least as good as the currently
shipping implementation):
https://code.google.com/p/chromium/issues/detail?id=334335

To see what we could delete if we remove support for the currently
shipping ColumnInfo-based multicol implementation (keeping support for
the "region-based" one): https://codereview.chromium.org/148823002/

As you can see, about 1000 lines of code would disappear from
RenderBlock.cpp alone. Especially the continuation and anonymous
wrapper renderer insertion and removal code would be simplified a
lot. Special code for painting and hit testing would also be
gone. Quite a few chunks of code also disappear from RenderLayer.cpp.

The new implementation is much more self-contained. There's a
dedicated renderer for multicol elements -
RenderMultiColumnBlock. Most of the actual work isn't done even there,
though. Much of the fragmentation logic is offloaded to the flow
thread, and keeping track of the actual columns is done by
RenderMultiColumnSet.

In the future we could remove even more fragmentation code from
RenderBlock/RenderBlockFlow, provided that we BOTH get rid of the old
multicol implementation and start to do pagination for printing using
flow threads. Methods like adjustLinePositionForPagination(),
adjustBlockChildForPagination(), applyBeforeBreak(), applyAfterBreak()
and friends could be moved out.

As pointed out in the bug report mentioned above, the first thing to
do should be to make the "region-based" (or we could call it
"flowthread-based") multicol implementation at least as good as the
currently shipping one, so that we can get replace it. This means that
it shouldn't be a goal to improve correctness before we have been able
to replace the current implementation. In the future we should be able
to focus on more correctness. At the top of that list I'd like to put
this: support nested multicol containers, and especially multicol
container inside pagination (so that you can e.g. print multi-page
multicol content properly, or display multicol content inside a
overflow:paged container).

In terms of already added correctness, I can mention support for the
column-fill property. It's missing in the currently shipping
implementation. The column balancing algorithm is also better in the
new implementation.

Here's what's left to do, if we want to replace the current
ColumnInfo-based multicol implementation:

- Explicit column breaks (-webkit-column-break-{before,after}:always) -
Review already submitted: https://codereview.chromium.org/143383002/

- column-span:all - I've played with this for some time already, without
submitting any patches.

- multicol table cells - somewhat tricky, since there's a dedicated
renderer for multicol containers in the new implementation
(RenderMultiColumnBlock). We could either get rid of it (would require
a few hooks in RenderBlock instead, then), solve it via an anonymous
renderer, or subclass RenderTableCell.

- Line grid awareness

- CSSOM view (offsetTop, etc.)

- Paged overflow (overflow-y: -webkit-paged-[xy]). It's currently based
on the old multicol implementation. In the new implementation it would
be better off being based on regions directly. No need to base it on
region-based multicol, since the only thing pagination and multicol
have in common, is in fact fragmentation, which is conveniently
provided by the flow thread (regions) implementation.

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

Adam Barth

unread,
Jan 29, 2014, 12:13:33 PM1/29/14
to Morten Stenshorne, Chris Harrelson, Johannes Wilm, Julien Chaffraix, PhistucK, David Hyatt, blink-dev, Dirk Schulze, Mihnea Ovidenie, Mihnea-Vlad Ovidenie, Alan Stearns
I'm glad that we agree that being self-contained is a valuable attribute.  However, I'm not sure I agree that Region-based multicolumn is more self-contained that the existing multicolumn implementation.  For example, the Regions-based implementation bleeds into RenderFlexibleBox: 


RenderTable even has a comment saying "FIXME: Work with regions someday."


I'm certainly not an expert on rendering, but, reading the code, it looks like implementing Regions requires every other rendering feature to understand and interact with Regions, whereas the current multicolumn implementation doesn't.

Of course, the new multicolumn implementation can support more use cases than the old implementation (e.g., columns of different widths), but supporting those use cases results in N^2 complexity: every feature, both current and future, needs to understand and interact with Regions.

Compare that to the approach used for text fragmentation in TypeKit:


In that approach, you can only fragment runs of text not arbitrary UIViews.  IMHO, an approach like that would impose much less complexity on the engine because not every block layout primitive would need to deal with fragmentation.

Adam

Chris Harrelson

unread,
Jan 29, 2014, 12:36:07 PM1/29/14
to Adam Barth, Morten Stenshorne, Johannes Wilm, Julien Chaffraix, PhistucK, David Hyatt, blink-dev, Dirk Schulze, Mihnea Ovidenie, Mihnea-Vlad Ovidenie, Alan Stearns
@Morten: thanks for the detailed enumeration of remaining tasks for flow thread-based multi-column. It sounds like a significant list of tasks. Is that correct? How many person-months would you guess?


Is it correct to say that this added complexity is due to the ability to have different width columns? That's what the line in RenderFlexibleBox seems to indicate, as well as your other comment. If we get rid of that, and instead focus only on replacing functionality in the old multicol, maybe we can avoid a bunch of complexity.

And putting on my software engineering advice hat, IMO this kind of refactoring of existing functionality and deleting old code is the first thing that should be done as part of adding new functionality, regardless of whether we were thinking of removing Regions.
 

Compare that to the approach used for text fragmentation in TypeKit:


In that approach, you can only fragment runs of text not arbitrary UIViews.  IMHO, an approach like that would impose much less complexity on the engine because not every block layout primitive would need to deal with fragmentation.

Adam

Morten Stenshorne

unread,
Jan 29, 2014, 3:22:48 PM1/29/14
to Chris Harrelson, Adam Barth, Johannes Wilm, Julien Chaffraix, PhistucK, David Hyatt, blink-dev, Dirk Schulze, Mihnea Ovidenie, Mihnea-Vlad Ovidenie, Alan Stearns
Chris Harrelson <chri...@chromium.org> writes:

> @Morten: thanks for the detailed enumeration of remaining tasks for
> flow thread-based multi-column. It sounds like a significant list of
> tasks. Is that correct? How many person-months would you guess?

column-span:all is the biggest task, but as I wrote, I've been working
on this for some time already, without submitting any patches.

If I were to guess, I'd say that everything would take 2-3 person
months.

Please keep reading below; more replies to both you and Adam.
Multicol doesn't require variable fragment widths (unless contained by
some other fragmentation context with variable widths, such as regions),
but indeed, if you want to support fragmentation (regions, multicol,
pagination) inside a flexbox (you'd e.g. do it between flex rows [1]),
there's probably no way around adding support for this to flexbox
code. The old multicol code would have to do it too, if we want it to
support breaking inside flexboxes.

[1] http://www.w3.org/TR/css3-flexbox/#pagination

> RenderTable even has a comment saying "FIXME: Work with regions someday."
>
> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/rendering/RenderTable.cpp&l=310 

Looks like support for variable fragment widths again, which is not an
inherit requirement for multicol. Breaking inside a table, on the other
hand, is desired for any kind of fragmentation. There are break
oppurtunities between table rows and between table row groups. Looks
like the table layout code currently doesn't support this at all,
though.

> I'm certainly not an expert on rendering, but, reading the code,
> it looks like implementing Regions requires every other
> rendering feature to understand and interact with Regions,
> whereas the current multicolumn implementation doesn't.

The current multicol implementation has a lot of limitations. Like I
explained above, if you want to break inside tables or flexboxes (or
even grids, I suppose, but I don't really know that spec), you need to
add code there. Support for variable widths in addition will require
even more code.

> Of course, the new multicolumn implementation can support more
> use cases than the old implementation (e.g., columns of
> different widths), but supporting those use cases results in N^2
> complexity: every feature, both current and future, needs to
> understand and interact with Regions.

Supporting different widths certainly is more work and complexity. The
new multicol implementation still doesn't support this, BTW. But as I
wrote above, it's not an inherent requirement for multicol, but you'd
need it if you put a multicol inside e.g. regions of different
widths. To get perfect regions support, we need this. Variable widths is
not really a multicol thing, but it's something that multicol needs to
support (just like tables or flexboxes have to) if it is to live
comfortably inside another fragmentation context that has variable
widths (which regions may have, and I'm pretty sure it's specced for
regular printing/pagination too).

> Is it correct to say that this added complexity is due to the
> ability to have different width columns? That's what the line in
> RenderFlexibleBox seems to indicate, as well as your other
> comment. If we get rid of that, and instead focus only on replacing
> functionality in the old multicol, maybe we can avoid a bunch of
> complexity.

Indeed. To merely match the current multicol implementation, no
flexbox or table changes at all are required.

Morten Stenshorne

unread,
Feb 3, 2014, 6:43:17 PM2/3/14
to blink-dev
After some discussion on IRC with Eric and others a few days ago, it was
decided that I should experiment with removing CSS regions support,
while keeping "region-based" multicol support intact, just to see how
much was left. Here's what I've managed to remove so far:

https://codereview.chromium.org/153233002

Christian Biesinger

unread,
Feb 3, 2014, 6:46:29 PM2/3/14
to Morten Stenshorne, blink-dev
To clarify, would this also remove the old multicol support?

What about variable-width regions - in or out?

Looking forward to the results!

-christian

Morten Stenshorne

unread,
Feb 3, 2014, 6:55:56 PM2/3/14
to Christian Biesinger, blink-dev
Christian Biesinger <cbies...@chromium.org> writes:

> To clarify, would this also remove the old multicol support?

No, we first need to improve the "region-based" implementation, before
we can replace the old one.

> What about variable-width regions - in or out?

Out.

Håkon Wium Lie

unread,
Feb 4, 2014, 2:42:23 PM2/4/14
to Adam Barth, Håkon Wium Lie, Lars Erik Bolstad, Hajime Morrita, PhistucK, blink-dev
Adam Barth wrote:

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

The new Facebook Paper app [1] is an example worth studying. While it
does not use multicol (to my knowledge, I'm outside the its region)
the user experience is built on multicol's close cousin: pagination of
onscreen content. Most of what can be seen in the video can be created
in Opera Reader [2], which is a simple extension built on our multicol
code.

[1] http://www.youtube.com/watch?v=IhrbT9O6kW8
[2] http://people.opera.com/howcome/2012/reader/

Cheers,

Eric Seidel

unread,
Feb 4, 2014, 5:09:55 PM2/4/14
to Morten Stenshorne, blink-dev
I believe it's time for us to take action and learn from our
inevitable mistakes. To close this thread:


I would like Blink to proceed forward in removing CSS Regions code,
keeping enough fragmentation support to keep new-multi-column working.
Thank you to Morten for offering to help with this.

The question still remains open as to if new multi-column is the best
way for us to support the shipping multi-column features we inherited
from WebKit. Hopefully Morten and other rendering hackers will be
able to settle that question over the coming weeks.


As others have raised, there appears to be definite interest in
paginated layouts on mobile. I think as our core/rendering
maintainers burn down their list of immediate performance issues
blocking (even simple) mobile web apps we should discuss this in more
depth. Perhaps at BlinkOn 2.0? [5]


Finally, I don't think we (the core/rendering maintainers) did a great
job of discussing our concerns for Regions in the public. Hopefully
this was just a stumble as Blink assumes ownership/maintenance of all
of this formerly WebKit code. I and many others are actively working
to improve transparency of the Blink project this year [1, 2, 3, 4]
and I would encourage all to participate in these discussions and help
make sure that your own personal goals are reflected-in/supported by
the projects goals.

1. https://groups.google.com/a/chromium.org/d/msg/blink-dev/Z5OzwYh3Wfk/IWooaY5FZowJ
2. https://groups.google.com/a/chromium.org/d/msg/blink-dev/4jBAnIVwrt0/-KAmRQAGVY4J
3. https://groups.google.com/a/chromium.org/d/msg/blink-dev/PfuKcDbJ8xQ/thiZxfHiN44J
4. https://groups.google.com/a/chromium.org/d/msg/blink-dev/bxIPxpzLprQ/Ny3UY51hj-EJ
5. https://groups.google.com/a/chromium.org/d/msg/blink-dev/7Z3nRbtwz5E/vd-lucn9NQsJ
Reply all
Reply to author
Forward
0 new messages