Intent to Ship: New multicol implementation

[Morten Stenshorne]

Intent to Ship: New multicol implementation

Contact emails
mste...@opera.com

Spec
http://www.w3.org/TR/css3-multicol/

Summary
Advance the RegionBasedColumns runtime flag from "experimental" to
"stable", and then delete the old implementation shortly after.

This will replace the current multicol implementation with the new one
(the new implementation is often referred to as "region-based
multicol", but that's probably a confusing name these days, as there's
no support for CSS regions in Blink at the moment). The new
implementation has an improved column balancing algorithm (the old
implementation tends to cause too tall columns), and it also works
better together with compositing. One new CSS property is also added:
column-fill. This property lets the author decide whether to balance
the columns or not. Implementation-wise it's also way less intrusive,
in that it doesn't require large chunks of code in LayoutBlock /
LayoutBlockFlow / DeprecatedPaintLayer, including the need for block
continuations, etc. So once the new implementation is shipping, we can
go ahead and delete the old code that bogs down such central parts of
Blink.

Note that the scope has shrunk since the original intent-to-implement
post: Support for nested-multicol will be dealt with later, and
treated as a simple bugfix. This also means that we cannot do printing
until this is fixed, since that depends on support for nested
fragmentation contexts. We can unprefix when all this is in. No
noteworthy improvements will be made to the various 'break' properties
either, such as introducing support for the more modern 'break-after',
'break-before' and 'break-inside' properties.

Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/morten$20stenshorne$20intent$20to$20implement$20multicol/blink-dev/mNgHFWfe1HY/HSUf800BIAAJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes

Demo link
http://people.opera.com/mstensho/t/do-i-have-new-multicol.html

Debuggability
This feature only exposes straight-forward CSS properties as far as
DevTools is concerned.

Compatibility Risk
In the original intent-to-implement post, the plan was to unprefix the
multicol properties, and I raised compatibility concerns in that
regard. However, we shouldn't really unprefix before we have improved
the implementation further, most notably add support for nested
multicol, so that we can also paginate and print multicol. So there's
hardly any compatibility risk left, except that we now implement
column-fill, so that all multicol containers will be balanced unless
otherwise specified (with the old implementation we only balance if
height is auto). And there's always the risk of bugs or bug fixes, of
course.

OWP launch tracking bug?
https://code.google.com/p/chromium/issues/detail?id=334335

Link to entry on the feature dashboard
https://www.chromestatus.com/feature/6526151266664448

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

[Dimitri Glazkov]

LGTM.

[Chris Harrelson]

LGTM2!

LGTM.

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

[Julien Chaffraix]

Some noteworthy thoughts: the nested multicol issue existed in the old
implementation. The new implementation is at feature parity with the
old one (in case it wasn't clear).

Morten has taken a slow approach to enabling the new implementation
and that should help alleviate the potential risks.

Having been involved in both implementations for a while, this should
get us in a better world so hearty non-OWNER LGTM.

Thanks,
Julien

[Jochen Eisinger]

lgtm3

[PhistucK]

On Mon, May 18, 2015 at 11:48 PM, Morten Stenshorne <mste...@opera.com> wrote:

​

One new CSS property is also added:

column-fill.

​...​

​

We can unprefix when all this is in.

 

​So while the rest of the properties are prefixed, column-fill is implemented without ​a prefix?

That seems inconsistent and weird...

☆PhistucK

[Morten Stenshorne]

Indeed. :(

See https://codereview.chromium.org/25687002

I think the natural thing would have been to prefix that one too, which
was my original suggestion, but the reviewers pointed out that we don't
want to introduce any more prefixed properties. On the other hand,
prefixed multicol has been shipping for years, so we couldn't just move
the whole thing (all multicol properties) behind the flag, and unprefix
all properties. So we ended up with this "lovely" solution. The
RegionBasedColumns flag now enables the new multicol implementation +
support for the column-fill property. All other properties remain
prefixed, regardless of multicol implementation.

I look forward to the day where we can unprefix and never look back
again at this mess. It has been and still is a headache for me. The
problem is that this project of mine doesn't really fit well with the
feature development model in Blink. Usually you start implementing
something completely unprefixed and behind a flag, and ship when it's
ready. In my case there already was a live and prefixed
implementation. Of course I could have added support for unprefixed
properties behind the flag (keeping the shipping old implementation
prefixed), but that would have delayed shipping, since the general
opinion (I think) is that it's not ready to become unprefixed yet. The
least thing we need to do first is to support nested multicol (or
multicol inside pagination), so that we can print multicol documents.
And the whole world seems eager to kill the old implementation (it
really has a big I'm-the-center-of-the-universe ego inside central Blink
layout classes), so getting the new implementation out the door as early
(okay, it's not that early anymore - this has taken a lot of time!) as
possible has been my top priority.

[PhistucK]

I understand the unfortunate situation. :(

I am not sure this even makes sense, but perhaps delay shipping column-fill specifically until the prefix less version is shipped?

☆PhistucK

[Morten Stenshorne]

That could work. One flag to select which implementation to use (which
I'll ship shortly), and one flag to enable column-fill (which will ship
when we go unprefixed). What do you think, folks? Worthwhile, to avoid
confusing authors with a mix of prefixed or unprefixed properties, or
was my current plan acceptable?

PhistucK <phis...@gmail.com> writes:

> I understand the unfortunate situation. :(
>
> I am not sure this even makes sense, but perhaps delay shipping column-fill
> specifically until the prefix less version is shipped?
>
>

> ☆*PhistucK*

[Julien Chaffraix]

On Tue, May 19, 2015 at 1:01 AM, Morten Stenshorne <mste...@opera.com> wrote:
> That could work. One flag to select which implementation to use (which
> I'll ship shortly), and one flag to enable column-fill (which will ship
> when we go unprefixed). What do you think, folks? Worthwhile, to avoid
> confusing authors with a mix of prefixed or unprefixed properties, or
> was my current plan acceptable?

The plan seems reasonable to me.

Enabling the 'column-fill' flag will be tied to unprefixing multicol
to be consistent so we need to make sure we have a path forward with
this effort. Without that, this proposal puts us in a worse situation.

Julien

[Ojan Vafai]

I think either plan is fine. I would personally probably just ship column-fill without waiting, but I don't think it matters too much either way.

[Morten Stenshorne]

Making multicol good enough to unprefix is next on my list, but I don't
have any date (or year :-P). If you think it's worth the extra paperwork
(intent-to-ship column-fill separately (and add it to the feature
dashboard), and probably also write a new intent-to-ship for "new
multicol implementation" (reboot this thread), where column-fill is
removed), I'll do it.

[Morten Stenshorne]

After some feedback (in this thread), it became clear that shipping
column-fill along with this could confuse web developers, since there'd
be a mix of prefixed and unprefixed properties. Therefore, column-fill
will be omitted (and be hidden behind a dedicated flag, only enabled for
experimental). I'll land the remaining parts (i.e. enable the new
implementation by default, but without column-fill support) as soon as I
get around to it.

[Philip Jägenstedt]

This all sounds great, a belated LGTM4!