Intent to Implement and Ship: CSS column-fill property

[Morten Stenshorne]

Contact emails

mste...@opera.com


Spec

https://drafts.csswg.org/css-multicol-1/#filling-columns


Summary

column-fill is the one missing CSS property from the multicol spec
(not counting break-after, break-before or break-inside, which really
belong in a more generic spec for fragmentation [1]). This property is
used to tell the engine whether columns should be balanced or not. If
they are balanced, each column gets similar amounts of content
inside. If they are not balanced, each column will be filled to the
height of the multicol container, until we run out of content.

[1] And they even exist in a more generic spec for fragmentation:
https://drafts.csswg.org/css-break-3/#break-between


Motivation

column-fill is really the one missing CSS property from the multicol
spec, and if we ship this, we can go ahead and unprefix the other
multicol properties right afterwards.

column-fill is already implemented [1], but protected by an
experimental runtime flag. It was meant to ship together with the new
multicol implementation [2][3], but after some discussion, it fell off
the wagon [4].

[1] (so this should really be an intent to ship only, but since
there's no existing mail thread for intent to implement to point to, I
had to make it an intent to implement and ship)
[2] https://codereview.chromium.org/1152423003
[3] https://www.chromestatus.com/feature/6526151266664448
[4] https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/hhecvWUBJvg/Fxb2jKfLjlYJ


Interoperability risk

Firefox: In development (-moz-column-fill)
Edge: Shipped
Safari: Shipped
Web developers: No signals


Compatibility risk

Probably low. Note though, that currently (without column-fill
support), Blink behaves as if column-fill were "auto", which means
that balancing will only occur when multicol height is unconstrained,
and for column rows before spanners (this is in accordance with the
spec). However, the initial value of column-fill in the spec is
"balance", so when we introduce this property, multicol containers
with constrained height and no column-fill property specified will
suddenly be balanced (instead of having columns be filled completely
until we run out of content). That said, there have been
implementations around for 5 years that support column-fill (MSIE, for
instance), so this really shouldn't be much of an issue on the world
wild web.


Ongoing technical constraints

None


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

Yes


OWP launch tracking bug

https://code.google.com/p/chromium/issues/detail?id=492297


Link to entry on the Chrome Platform Status

https://www.chromestatus.com/features/6298909664083968


Requesting approval to ship?

Yes

[PhistucK]

Wait, are you seeking to ship only column-fill without the rest of the unprefixed properties?

Meaning, the only standard multiple column feature implemented in Blink would be column-fill, which, as a standalone property, does nothing. Right...?

I mean, this code will not show columns in Blink when only column-fill ships -

div

{

 columns: 4;

 column-fill: auto;

}

Or am I misunderstanding? :(

Anyway, I do not think it should affect the prefixed implementation and I do not think the default of the prefixed implementation should change (the standard implementation should have balance as the default while the prefixed one has auto as the default, you mentioned), as there is an unknown compatibility risk (that cannot really be measured, because it is a visual, aesthetical bug).

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rick Byers]

The plan in the earlier intent to ship thread was to ship this along with unprefixing the rest of multicol support, right?  Has your thinking changed here?

[Morten Stenshorne]

Rick Byers <rby...@chromium.org> writes:

> The plan in the earlier intent to ship thread was to ship this along with
> unprefixing the rest of multicol support, right? Has your thinking changed
> here?

That is still the plan, but can I do all of that with one Intent? I was
planning to use two separate Intents, but if I don't have to do that,
fine. I just though I needed this to get the paperwork right. I might
even slam everything together in one commit then, since the situation
where we support column-fill with all the other multicol properties
prefixed is a rather confusing and unhealthy situation anyway (although
I was planning to push the two commits shortly after oneanother, so
nobody should really need to worry about that).

Shipping column-fill is a one-liner in RuntimeEnabledFeatures.in , while
unprefixing is a heavier change (lots of renaming throughout the
codebase). The old prefixed properties will be kept as aliases.

Morten

> On Tue, Jan 12, 2016 at 9:43 AM, PhistucK <phis...@gmail.com> wrote:
>
>> Wait, are you seeking to ship only column-fill without the rest of the
>> unprefixed properties?
>> Meaning, the only standard multiple column feature implemented in Blink
>> would be column-fill, which, as a standalone property, does nothing.
>> Right...?
>> I mean, this code will not show columns in Blink when only column-fill
>> ships -
>> div
>> {
>> columns: 4;
>> column-fill: auto;
>> }
>>
>> Or am I misunderstanding? :(
>>
>> Anyway, I do not think it should affect the prefixed implementation and I
>> do not think the default of the prefixed implementation should change (the
>> standard implementation should have balance as the default while the
>> prefixed one has auto as the default, you mentioned), as there is an
>> unknown compatibility risk (that cannot really be measured, because it is a
>> visual, aesthetical bug).
>>
>>

>> ☆*PhistucK*

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

[PhistucK]

Sorry - it sounded like there would be a release where only this is shipped and the unprefixed implementation is not. I am glad this is not the plan.

Regarding the aliasing - is the code complexity of maintaining the old default for the prefixed implementation while implementing the new default for the unprefixed implementation so high?

☆PhistucK

[Rick Byers]

On Tue, Jan 12, 2016 at 2:37 PM, Morten Stenshorne <mste...@opera.com> wrote:

Rick Byers <rby...@chromium.org> writes:

> The plan in the earlier intent to ship thread was to ship this along with
> unprefixing the rest of multicol support, right?  Has your thinking changed
> here?

That is still the plan, but can I do all of that with one Intent? I was
planning to use two separate Intents, but if I don't have to do that,
fine. I just though I needed this to get the paperwork right. I might
even slam everything together in one commit then, since the situation
where we support column-fill with all the other multicol properties
prefixed is a rather confusing and unhealthy situation anyway (although
I was planning to push the two commits shortly after oneanother, so
nobody should really need to worry about that).

Shipping column-fill is a one-liner in RuntimeEnabledFeatures.in , while
unprefixing is a heavier change (lots of renaming throughout the
codebase). The old prefixed properties will be kept as aliases.

Ah, thanks for the clarification, sounds great to me.  Doing this as separate intents is fine with me (as long as the plan is to ship them both together).

LGTM1 to ship.  From the previous intent-to-ship it sounds like there was already consensus that column-fill was ready to ship (outside this prefixed/unprefixed question) so I think this is just a rubber stamp.

[Morten Stenshorne]

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

> Regarding the aliasing - is the code complexity of maintaining the old
> default for the prefixed implementation while implementing the new default
> for the unprefixed implementation so high?

That sounds ugly. I'd rather see a bug report that proves that this is a
problem on a real site before even considering doing something like
that.

[Chris Harrelson]

What are some of the "top" sites that use columns? Do they change their visual output, and if so does it look as good as before?

What do you think of the idea of a console warning advising on the change to column balancing behavior?

Chris

[Morten Stenshorne]

Chris Harrelson <chri...@chromium.org> writes:

> What are some of the "top" sites that use columns? Do they change their
> visual output, and if so does it look as good as before?

The situation before shipping column-fill:

To display a block container in two columns, according to the spec, one
would just add a "columns:2;" declaration. However, that's not going to
work in Blink and Gecko (and until recently: WebKit), since they need
prefixes. So sites would typically also add "-moz-columns:2;
-webkit-columns:2;". As long as height is auto, column-fill doesn't
matter, since we'll balance anyway (everyone agrees on this, including
the spec). Now, if we add "height:10em;", column-fill *will* make a
difference. The initial value is "balance", so all browsers will now
balance, except for Blink, which will pretend that column-fill is
"auto". So we have a compatibility issue right there, with the current
situation. Shipping column-fill would fix it.

The only case where shipping column-fill would be a problem would be on
sites that only intend to support Blink / WebKit, so that they only
specify "-webkit-columns:2; height:10em;" for instance. I don't know if
we want to worry about them, or even if they exist.

> What do you think of the idea of a console warning advising on the change
> to column balancing behavior?

So, if -webkit-columns and height are non-auto, and an unprefixed
"columns" property isn't specified, we should warn that column-fill is
now supported? Not sure how trivial it is to implement, and if we go
ahead and do that, we might just as well do what PhistucK suggests
below; to not support column-fill if only -webkit- prefixed properties
are used to enable multicol. I really hope we need to bother about
this.

Morten

[Morten Stenshorne]

(Re-adding blink-dev@)

Chris Harrelson <chri...@chromium.org> writes:

> On Wed, Jan 13, 2016 at 12:54 PM Morten Stenshorne <mste...@opera.com>
> wrote:
>
>> Chris Harrelson <chri...@chromium.org> writes:
>>
>> > What are some of the "top" sites that use columns? Do they change their
>> > visual output, and if so does it look as good as before?
>>
>> The situation before shipping column-fill:
>>
>> To display a block container in two columns, according to the spec, one
>> would just add a "columns:2;" declaration. However, that's not going to
>> work in Blink and Gecko (and until recently: WebKit), since they need
>> prefixes. So sites would typically also add "-moz-columns:2;
>> -webkit-columns:2;". As long as height is auto, column-fill doesn't
>> matter, since we'll balance anyway (everyone agrees on this, including
>> the spec). Now, if we add "height:10em;", column-fill *will* make a
>> difference. The initial value is "balance", so all browsers will now
>> balance, except for Blink, which will pretend that column-fill is
>> "auto". So we have a compatibility issue right there, with the current
>> situation. Shipping column-fill would fix it.
>>
>> The only case where shipping column-fill would be a problem would be on
>> sites that only intend to support Blink / WebKit, so that they only
>> specify "-webkit-columns:2; height:10em;" for instance. I don't know if
>> we want to worry about them, or even if they exist.
>>
>

> I don't understand this comment. All sites which use columns and support
> Blink use -webkit-columns...and all of thse which also specify a height
> will get different behavior after shipping than before, right?

But all sites that wish to support other engines than Blink / WebKit
typically also supply "columns" (IE / Edge / Presto) and "-moz-columns"
(Gecko). All those engines support column-fill properly already, so if
they really didn't want columns to be balanced, they must already have
specified column-fill:auto (and -moz-column-fill:auto). If they actually
wanted the columns to balance (and either omitted column-fill or set it
to "balance"), it's currently failing in Blink, until this gets shipped.

Morten

[Håkon Wium Lie]

Chris Harrelson wrote:

> What are some of the "top" sites that use columns? Do they change their
> visual output, and if so does it look as good as before?

Wikipedia uses multi-column layout extensively, e.g. with rules like
this for lists of references:

column-width: 30em;

Morten Stenshorne wrote:

> As long as height is auto, column-fill doesn't
> matter, since we'll balance anyway (everyone agrees on this, including
> the spec).

Right. Wikipedia does not restrict the height of multi-column
elements, so Morten's proposed change should not have any visual
impact on Wikipedia's pages. Restricting the height is more sensible
in paged layouts, and we're not quite there (yet).

Cheers,

-h&kon

Håkon Wium Lie how...@opera.com http://people.opera.com/howcome

[一丝]

The spec add 'balance-all' value. https://drafts.csswg.org/css-multicol-1/#valdef-column-fill-balance-all

以上

一丝

[Morten Stenshorne]

一丝 <yio...@gmail.com> writes:

> The spec add 'balance-all' value.
> https://drafts.csswg.org/css-multicol-1/#valdef-column-fill-balance-all

We only implement what's in the CR version of the spec, i.e. "auto" and "balance".

[Chris Harrelson]

I see now, thanks for explaining. And you've surveyed these sites to verify they are doing this?

[Morten Stenshorne]

I don't know how I would find these sites. :) All I know about is
wikipedia, which uses auto-height multicol containers, which means that
column-fill doesn't matter there.

[Philip Jägenstedt]

It sounds quite tricky indeed to estimate the risk. Searching for combinations of CSS properties in httparchive is very noisy, and use counters would add a lot of time.

That Edge, with a Chrome UA string, has shipped column-fill with the initial value balance is reason to think that the compat risk here is low. Gecko's behavior also gives us some cover.

Since shipping this changes the default behavior and thus would improve interop, I say LGTM2 to ship this in the same milestone that unprefixes multicol. We're right after a branch point, so there's plenty of time to catch any major breakage.

Philip

[Chris Harrelson]

Can't you use httparchive to find some other sites that use muticol and manually check that they are not broken?

 

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

[Morten Stenshorne]

So, to repeat: The only potentially problematic scenario is when a site
specifies multicol by ONLY using -webkit- prefixes AND at the same time
specifies a height on the multicol container. Currently this doesn't
impose balancing in Blink (which is a spec violation). Shipping
column-fill will change that, and potentially display content in a
different way than what the author had intended (it's highly unlikely
that it would look broken, though). This should be the only problematic
scenario, since, if unprefixed or -moz- prefixed properties are
specified, it must mean that the site is already displayed with multicol
by column-fill supporting engines (IE, Edge, Presto, Gecko).

So, with that in mind, I downloaded data for one random day in December
from httparchive, like this:

gsutil.py -m rsync gs://httparchive/desktop-Dec_15_2015 <destination_folder>

That's about 480000 sites (one har.gz file for each site), 200GB of
compressed data.

I then removed all har.gz files not matching any of "-webkit-columns",
"-webkit-column-count" or "-webkit-column-width".

Then I removed all HARs matching "moz-column" (as mentioned earlier,
Gecko supports column-fill, so if the site cares about Gecko, it should
already work (and it was easier to filter out based on "-moz-column",
than just "column")).

Then I had 150 HAR files left, which I went through manually.

I found about 35 sites that use multicol with ONLY -webkit- prefixes. I
couldn't see that any of those specified a height, so introducing
column-fill isn't likely to cause any changes to those sites (since they
are already balanced), let alone cause breakage.

The only change I stumbled across was on http://www.melty.com/ (and a
lot of other melty*.* sites, such as meltyfood.fr). These sites use a
multicol container near the bottom of the page, which links to all the
French Melty sites. The height of this multicol container is specified,
and multicol is enabled via -webkit-columns and columns ("height:280px;
column-count:2; -webkit-column-count:2"), so it'll use columns in IE
(unprefixed), Presto (unprefixed), Blink (prefixed) and WebKit (supports
both prefixed and unprefixed). So, column-fill isn't specified, which
means that it should balance the contents (since "balance" is the
initial value) when column-fill is shipped. This will make Blink render
like the others (i.e. balance). This may be a good example of the
changes we can expect by shipping column-fill, and, if you compare the
rendering in current Blink with that of Edge, I'd say that both
renderings look acceptable, albeit different (and balancing the content
DOES look slightly better, if you ask me).

These findings, plus the fact that WebKit has already shipped
column-fill (which means that they would already be suffering from the
same problems), suggests that shipping column-fill is safe.

[PhistucK]

On Thu, Jan 21, 2016 at 11:43 AM, Morten Stenshorne <mste...@opera.com> wrote:

plus the fact that WebKit has already shipped
column-fill (which means that they would already be suffering from the
same problems)

Just to clarify - it is not a question of whether they shipped column-fill, rather, of how it interacts with the prefixed properties​ (meaning, whether the prefixed properties have a different default now and whether setting it affects the prefixed properties, if only they are specified).

But I do agree that the findings show the this is probably web compatible, at least for most of the websites.

☆PhistucK

[Rick Byers]

Thanks for the additional research Morten!  I agree that it sounds reasonable safe to ship this (along with unprefixing multicol support).  Still LGTM1 to ship.

Chris / Philip, WDYT?

Rick

[Philip Jägenstedt]

Still LGTM2

[Chris Harrelson]

The data does seem to show that shipping column-fill would not be too web-incompatible.

To summarize, are you proposing just unprefixed column fill? Or prefixed for now, until the other intent is resolved w.r.t. column break CSS? (Sorry, getting a little confused by these discussions.)

Chris

[Morten Stenshorne]

Chris Harrelson <chri...@chromium.org> writes:

> The data does seem to show that shipping column-fill would not be too
> web-incompatible.
>
> To summarize, are you proposing just unprefixed column fill? Or prefixed
> for now, until the other intent is resolved w.r.t. column break CSS?
> (Sorry, getting a little confused by these discussions.)

No prefixed column-fill planned. It actually *was* my plan to support
-webkit-column-fill back in the days for Blink (Webkit has it), but I
got a no (this was not long after the fork), and was told it was more or
less verboten to add new -webkit- prefixed properties. There's a lot to
be said for that policy, but it certainly put us in a messy situation
here.

However, since we've got this far without -webkit-column-fill, I see no
point in introducing it now. It will just be history churn and I'd also
have to change a lot of layout tests (they use "column-fill", not
"-webkit-column-fill", since that's all we support).

[Chris Harrelson]

On Tue, Jan 26, 2016 at 11:28 AM Morten Stenshorne <mste...@opera.com> wrote:

Chris Harrelson <chri...@chromium.org> writes:

> The data does seem to show that shipping column-fill would not be too
> web-incompatible.
>
> To summarize, are you proposing just unprefixed column fill? Or prefixed
> for now, until the other intent is resolved w.r.t. column break CSS?
> (Sorry, getting a little confused by these discussions.)

No prefixed column-fill planned. It actually *was* my plan to support
-webkit-column-fill back in the days for Blink (Webkit has it), but I
got a no (this was not long after the fork), and was told it was more or
less verboten to add new -webkit- prefixed properties. There's a lot to
be said for that policy, but it certainly put us in a messy situation
here.

Ok...then you're now proposing to ship unprefixed column-fill before unprefixing the rest of multicolumn?

[Philip Jägenstedt]

On Wed, Jan 27, 2016 at 4:31 AM, Chris Harrelson <chri...@chromium.org> wrote:

On Tue, Jan 26, 2016 at 11:28 AM Morten Stenshorne <mste...@opera.com> wrote:

Chris Harrelson <chri...@chromium.org> writes:

> The data does seem to show that shipping column-fill would not be too
> web-incompatible.
>
> To summarize, are you proposing just unprefixed column fill? Or prefixed
> for now, until the other intent is resolved w.r.t. column break CSS?
> (Sorry, getting a little confused by these discussions.)

No prefixed column-fill planned. It actually *was* my plan to support
-webkit-column-fill back in the days for Blink (Webkit has it), but I
got a no (this was not long after the fork), and was told it was more or
less verboten to add new -webkit- prefixed properties. There's a lot to
be said for that policy, but it certainly put us in a messy situation
here.

Ok...then you're now proposing to ship unprefixed column-fill before unprefixing the rest of multicolumn?

See also the Intent to Ship: Unprefixed multicol CSS properties. I think we need to consider these two together, and the only remaining doubt (for me) is the risk of having no unprefixed counterpart to -webkit-column-break-*, but let's discuss that on the other thread.

Philip

[Morten Stenshorne]

Philip Jägenstedt <phi...@opera.com> writes:

> On Wed, Jan 27, 2016 at 4:31 AM, Chris Harrelson <chri...@chromium.org>
> wrote:
>
>>
>>
>> On Tue, Jan 26, 2016 at 11:28 AM Morten Stenshorne <mste...@opera.com>
>> wrote:
>>
>>> Chris Harrelson <chri...@chromium.org> writes:
>>>
>>> > The data does seem to show that shipping column-fill would not be too
>>> > web-incompatible.
>>> >
>>> > To summarize, are you proposing just unprefixed column fill? Or prefixed
>>> > for now, until the other intent is resolved w.r.t. column break CSS?
>>> > (Sorry, getting a little confused by these discussions.)
>>>
>>> No prefixed column-fill planned. It actually *was* my plan to support
>>> -webkit-column-fill back in the days for Blink (Webkit has it), but I
>>> got a no (this was not long after the fork), and was told it was more or
>>> less verboten to add new -webkit- prefixed properties. There's a lot to
>>> be said for that policy, but it certainly put us in a messy situation
>>> here.
>>>
>>
>> Ok...then you're now proposing to ship unprefixed column-fill before
>> unprefixing the rest of multicolumn?

That has already been established as a bad idea. We'd end up in a
situation with everything prefixed except column-fill, which surely will
confuse authors.

> See also the Intent to Ship: Unprefixed multicol CSS properties

> <https://groups.google.com/a/chromium.org/d/msg/blink-dev/8P5RWP_nRTk/7QNvJVrmAgAJ>.

> I think we need to consider these two together, and the only remaining
> doubt (for me) is the risk of having no unprefixed counterpart to
> -webkit-column-break-*,
> but let's discuss that on the other thread.

Yes, these two need to go together. But even if it turns out that we
cannot unprefix yet, it would be nice to have this intent sufficiently
LGTMed, so that we can ship it once we're ready to unprefix.

Sorry about the confusing paperwork. Maybe I should have merged the two
intents together instead, since one cannot be shipped without the other?
Then again, they ARE two separate things.

[Chris Harrelson]

On Wed, Jan 27, 2016 at 2:06 AM Morten Stenshorne <mste...@opera.com> wrote:

Philip Jägenstedt <phi...@opera.com> writes:

> On Wed, Jan 27, 2016 at 4:31 AM, Chris Harrelson <chri...@chromium.org>
> wrote:
>
>>
>>
>> On Tue, Jan 26, 2016 at 11:28 AM Morten Stenshorne <mste...@opera.com>
>> wrote:
>>
>>> Chris Harrelson <chri...@chromium.org> writes:
>>>
>>> > The data does seem to show that shipping column-fill would not be too
>>> > web-incompatible.
>>> >
>>> > To summarize, are you proposing just unprefixed column fill? Or prefixed
>>> > for now, until the other intent is resolved w.r.t. column break CSS?
>>> > (Sorry, getting a little confused by these discussions.)
>>>
>>> No prefixed column-fill planned. It actually *was* my plan to support
>>> -webkit-column-fill back in the days for Blink (Webkit has it), but I
>>> got a no (this was not long after the fork), and was told it was more or
>>> less verboten to add new -webkit- prefixed properties. There's a lot to
>>> be said for that policy, but it certainly put us in a messy situation
>>> here.
>>>
>>
>> Ok...then you're now proposing to ship unprefixed column-fill before
>> unprefixing the rest of multicolumn?

That has already been established as a bad idea. We'd end up in a
situation with everything prefixed except column-fill, which surely will
confuse authors.

Right. My uncertainty was because the other thread resolve as "not yet".

 

> See also the Intent to Ship: Unprefixed multicol CSS properties
> <https://groups.google.com/a/chromium.org/d/msg/blink-dev/8P5RWP_nRTk/7QNvJVrmAgAJ>.
> I think we need to consider these two together, and the only remaining
> doubt (for me) is the risk of having no unprefixed counterpart to
> -webkit-column-break-*,
> but let's discuss that on the other thread.

Yes, these two need to go together. But even if it turns out that we
cannot unprefix yet, it would be nice to have this intent sufficiently
LGTMed, so that we can ship it once we're ready to unprefix.

Sorry about the confusing paperwork. Maybe I should have merged the two
intents together instead, since one cannot be shipped without the other?
Then again, they ARE two separate things.

LGTM to ship this unprefixed along with unprefixing the rest of multicolumn when that happens. I would also support shipping it prefixed now, in order to make incremental progress, similar to what WebRTC is doing.

 

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

[Morten Stenshorne]

Chris Harrelson <chri...@chromium.org> writes:

> LGTM to ship this unprefixed along with unprefixing the rest of multicolumn
> when that happens.

That's an "LGTM3", right? :)

[Rick Byers]

Yep, you've got your 3  :-)

[Joe Medley]

Any idea which version will get this by default?

Joe Medley | Technical Writer, DevPlat | jme...@google.com | 816-678-7195

[Morten Stenshorne]

That would be version 50, if we manage to land it before it gets
branched.