Intent to Implement and Ship: improved multicol support

[Morten Stenshorne]

Primary eng (and PM) emails

mste...@opera.com


Spec

http://www.w3.org/TR/2011/CR-css3-multicol-20110412/


Summary

Improve Blink's multicol implementation and remove -webkit-
prefixes. A big part of the task is to support nested multicols, where
the usecase with a multicol container inside a paged container [1] is
especially interesting. There are other things as well. One CSS
property - namely 'column-fill' - is missing in the current
implementation (it more or less pretends that its computed value is
'auto', which makes column balancing impossible if height is set). The
column balancing support also needs an overhaul; it tends to create
slightly too tall containers.

[1] The multicol implementation improvements will also affect support
for paged containers (overflow:-webkit-paged-x|-webkit-paged-y)
somewhat, since it heavily depends on the multicol implementation.

Pagination (and printing) support of multicol elements will also be
taken care of. Multicol is currently forcefully switched off when
printing.

The support for various 'break' properties also needs to be cleaned
up. Blink supports page-break-after, page-break-before and
page-break-inside from CSS2. Those are fine, but additionally it
supports -webkit-column-break-after, -webkit-column-break-before,
-webkit-column-break-inside. Don't know where these stem from (and old
multicol spec?). They should be removed. Will add support for
break-after, break-before and break-inside instead, as defined in the
multicol spec. No huge attempts will be made at improving the engine's
actual handling of breaks, though.

For now it is probably better if all this work be based on the current
multicol implementation (i.e. the one using ColumnInfo, not the
unfinished implementation based on regions (hidden behind the
regionBasedColumnsEnabled setting)). The reason why I think this is
best is that it is not known when the region based multicol
implementation will be finished. Furthermore, that work will be done
in WebKit. How feasible it will be to import that into Blink depends
on when it's going to be finished.


Motivation

The multicol implementation in Blink has some shortcomings, and other
engines (Gecko, Presto, Trident) are ahead of us. Getting more
standard-compliant multicol support into yet another engine makes
multicol more attractive among authors. Being able to print beautiful
multicol layout is another good thing.


Compatibility Risk

Removing the -webkit- prefixes could break sites that use those and
don't provide a non-prefixed version. Apart from that, this work is
expected to bring the Blink implementation closer to the others and
make it MORE compatible.


OWP launch tracking bug?

There isn't one.


Row on feature dashboard?

Missing.


Requesting simultaneous permission to ship?

Yes.

--
---- Morten Stenshorne, developer, Opera Software ASA ----
---- Office: +47 23692400 ------ Mobile: +47 93440112 ----
------------------ http://www.opera.com/ -----------------

[Kenneth Rohde Christiansen]

Why not keep the prefixed versions keeping current behavior but warn about their usage? Then implement the unprefixed versions (behind runtime flag at first) with the proper behavior

Kenneth

--
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4294 9458 / E-mail kenneth at webkit.org

﹆﹆﹆

[Morten Stenshorne]

Kenneth Rohde Christiansen <kenneth.ch...@gmail.com> writes:

> Why not keep the prefixed versions keeping current behavior but warn about
> their usage? Then implement the unprefixed versions (behind runtime flag at
> first) with the proper behavior

That's a possibility too. And then at some point remove the old
implementation?

[Kenneth Rohde Christiansen]

Yes, when usage is low. I believe that Google are measuring the usage. Someone could probably confirm.

[Masataka Yakura]

Looking at UseCounter.h, I don't see anything about prefixed multicol layout.

https://chromium.googlesource.com/chromium/blink/+/master/Source/core/page/UseCounter.h

[Mike West]

Please feel encouraged to submit a patch that adds such measurement. :)

-mike

[Alexandru Chiculita]

On Apr 18, 2013, at 2:05 PM, Morten Stenshorne <mste...@opera.com> wrote:
>
> For now it is probably better if all this work be based on the current
> multicol implementation (i.e. the one using ColumnInfo, not the
> unfinished implementation based on regions (hidden behind the
> regionBasedColumnsEnabled setting)). The reason why I think this is
> best is that it is not known when the region based multicol
> implementation will be finished. Furthermore, that work will be done
> in WebKit. How feasible it will be to import that into Blink depends
> on when it's going to be finished.
>

I really liked how the regions implementation could become the foundation for every sort of fragmented container. Pages/Regions and Columns could reuse the regions implementation. Once we remove the ColumnInfo it would also reduce the amount of code we have for the line-breaks/line-layout in RenderBlock.cpp.

Is there any estimate on what's remaining for the regions based multi-column implementation?

Our team has been working on the CSS Regions implementation and I think I can help with the multi-column going forward.

-Alex

[Eric Seidel]

I think this is very interesting.

It's unclear to me how much (if any) of this we're already shipping?

http://www.w3.org/TR/2011/CR-css3-multicol-20110412/ is at CR, so this qualifies under guideline #3:

http://www.chromium.org/blink#compatibility

Since this likely will take a while to implement correctly, I would recommend implementing this behind a flag so that we can ship a cohesive implementation when it's ready instead of it trickling out in pieces on the Stable channel.  (I wouldn't want consumers of Content to get this by accident when it't not yet done.)

LGTM to implement.  It's not clear yet if this is ready to ship.  I recommend posting an intent-to-ship when this work is further along.

Happy to review patches in this area!  Please feel encouraged to track me down if you're having any trouble getting reviews.

[Darin Fisher]

+1

-Darin

[Ojan Vafai]

+1 to adding new APIs and/or removing old APIs behind a runtime flag. As with any other feature, we need to add a UseCounter to make sure we won't break too much content before we can safely remove it.

I don't think we need to put bug fixes behind a flag though.

I also was pretty optimistic about this. The old multi-column code in Blink/WebKit is pretty poor and supporting both that code and Regions seems like unnecessary complexity. That said, I don't have any conception of how far along the rewrite on top of Regions is. If we could have everyone working on completing this transition and then fixing multi-column issues on top of the new code, that would be ideal in my view.

Importantly, none of this needs to block on shipping the Regions APIs. So the two are still decoupled in terms of shipping timelines. This is really just about code-sharing and long-term codebase maintenance.

In either case, this is all implementation detail and we should probably discuss a long-term design for how this code should look on a fresh thread.

[Morten Stenshorne]

After some thinking and discussion with David Hyatt, I think it's
feasible to do this work in the region based multicol code after all,
rather than adding Yet Another Multicol Implementation (that would be a
dead end in the long run anyway). I've already submitted the first
region based multicol patch [1]. Since David obviously wants it in
WebKit and I want it in Blink (and probably in WebKit too, actually),
I'm submitting all my patches to WebKit first to get it reviewed and
landed there, and then I port it to Blink and submit new patches
there. I also need to port whatever David or others do in WebKit over to
Blink.

[1] https://bugs.webkit.org/show_bug.cgi?id=116033

I'm also retracting my intent to ship this for now. Let's talk about
that some other year. :)


Eric Seidel <ese...@chromium.org> writes (Tue, 23 Apr 2013 13:50:26 -0700 (PDT)):