Intent to Ship: Unprefixed multicol CSS properties

[Morten Stenshorne]

Contact emails

mste...@opera.com

Spec

https://drafts.csswg.org/css-multicol-1/

Summary

Support unprefixed versions of the standardized multicol CSS
properties that are currently -webkit- prefixed in Blink. These are:

column-count
column-gap
column-rule
column-rule-color
column-rule-style
column-rule-width
column-span
column-width
columns

The prefixed properties will be kept as aliases. Note that one
property is missing from the list above, namely column-fill. That one
is shipped separately; see
https://groups.google.com/a/chromium.org/d/msg/blink-dev/WUUEUWha5cI/lnw0T_5XAgAJ

Also note that Blink supports the non-standard properties
-webkit-column-break-after, -webkit-column-break-before,
-webkit-column-break-inside. Those will be kept as-is and not become
unprefixed, since they don't exist in any spec. The multicol spec
instead refers to the break-after, break-before and break-inside
properties, which Blink doesn't yet support.

It should be reasonable to unprefix multicol without break-after,
break-before and break-inside, since those properties are generic
fragmentation properties not specific to multicol, so they should not
be considered being a part of multicol. Their canonical definition is
in https://www.w3.org/TR/css3-break/ , although a simplified defintion
does exist in the multicol spec.


Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/mNgHFWfe1HY/HSUf800BIAAJ
https://groups.google.com/a/chromium.org/d/msg/blink-dev/hhecvWUBJvg/vchhqTwOQKMJ


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

Yes


Demo link

https://no.wikipedia.org/wiki/Vestfossen#Referanser


Debuggability

All CSS properties will be debuggable as normal using DevTools.


Interoperability and Compatibility Risk

Low. Unprefixed multicol has been supported by MSIE / Edge and Presto
for about 5 years now. And we're keeping the prefixed properties for
now, anyway. Most sites typically provide both unprefixed, -moz-
prefixed and -webkit- prefixed declarations when they want to use
multicol, so it's not expected that unprefixing will have much impact
at all, compatibility-wise.


OWP launch tracking bug

http://crbug.com/334335


Entry on the feature dashboard

https://www.chromestatus.com/feature/6526151266664448

[PhistucK]

Since you are keeping -webkit-column-break-after, -webkit-column-break-before and -webkit-column-break-inside, does that mean using them affects the unprefixed implementation as well?

If so, this is a bit... disturbing. I think they should only be scoped to the prefixed implementation.

I understand you are trying to avoid two code paths and just alias everything prefixed to the unprefixed, but I am not sure this is the correct course of action.

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

[Morten Stenshorne]

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

> Since you are keeping -webkit-column-break-after,
> -webkit-column-break-before and -webkit-column-break-inside, does that mean
> using them affects the unprefixed implementation as well?

Yes, pure aliases.

> If so, this is a bit... disturbing. I think they should only be scoped to
> the prefixed implementation.
>
> I understand you are trying to avoid two code paths and just alias
> everything prefixed to the unprefixed, but I am not sure this is the
> correct course of action.

Can you explain why this is a problem?

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

[PhistucK]

The new implementation should not be affected by column-break-before and friends, since it is not in the specification anymore. Supporting that may grow the usage of this prefixed property due to the lack of the standard non-multiple-column-specific, break-before property.

☆PhistucK

[fri...@jeka.info]

Am Donnerstag, 14. Januar 2016 09:41:52 UTC+1 schrieb PhistucK:

The new implementation should not be affected by column-break-before and friends, since it is not in the specification anymore. Supporting that may grow the usage of this prefixed property due to the lack of the standard non-multiple-column-specific, break-before property.

... or vice versa: Not supporting that may hinder the usage of the unprefixed property due the lack of  column-break functionality.

I'd say: When In Doubt, Keep It Simple! (aliases)

[Morten Stenshorne]

OK, so I think we should put this intent on hold until we have
implemented and shipped break-after, break-before and break-inside. [1]
Without that, authors will have no means of controlling breaks without
using the prefixed -webkit-column-break-foo properties. I realize now
that it would be bad to combine those with non-prefixed multicol
properties.

Additionally, Timothy Loh made me aware of the fact that
-webkit-column-span supports the non-standard value of '1' (only 'none'
and 'all' are allowed in the spec). Better have that removed before
shipping too.

After fixing those two things, there should be no need for a fancier
solution than simply aliasing the -webkit-column* properties to
column*. Right?

[1] https://www.chromestatus.com/feature/5630943616303104

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

> The new implementation should not be affected by column-break-before and
> friends, since it is not in the specification anymore. Supporting that may
> grow the usage of this prefixed property due to the lack of the standard
> non-multiple-column-specific, break-before property.
>
>

> ☆*PhistucK*

[PhistucK]

Frankly, I would leave the prefixed implementation as is. However, you can say that that ship has sort of sailed, since shipping the region based multiple column actually fixed a lot of multiple column issues - in its prefixed version.

I am not sure what is the right path, but I always lean towards keeping it as is (along with its bugs, in order to create incentives for using the standard version) and then removing it when usage allows.

☆PhistucK

[Philip Jägenstedt]

I'm not at all sure that blocking unprefixing on first implement
break-* is necessary. The concern is that this would encourage use of
the prefixed -webkit-column-break-* properties, but we have to weigh
that against the many column-* and columns properties that would be
unprefixed.

Do you have any hunch about which proportion of sites using multicol
also need -webkit-column-break-* to get the intended results? If it's
anything like 20% or less, then the benefit of unprefixing the main
multicol implementation seems to far outweigh the risk of increasing
-webkit-column-break-* usage.

Whatever the outcome, having the prefixed properties as simple aliases
is certainly the preferred outcome. We can't assume that we'll ever be
successful in removing them, so to accept any divergence is to accept
a long-term maintenance of two code paths.

[Philip Jägenstedt]

On Tue, Jan 19, 2016 at 3:06 PM, PhistucK <phis...@gmail.com> wrote:
> Frankly, I would leave the prefixed implementation as is. However, you can
> say that that ship has sort of sailed, since shipping the region based
> multiple column actually fixed a lot of multiple column issues - in its
> prefixed version.
> I am not sure what is the right path, but I always lean towards keeping it
> as is (along with its bugs, in order to create incentives for using the
> standard version) and then removing it when usage allows.

This is not at all what I would advise. By now, I consider prefixed
APIs to be just like any other, just with bad names. If it looks safe
compat-wise and would reduce complexity, then making them aliases is
great. (This is true of unprefixed things too, e.g. document.charset
and document.characterSet.)

Any difference between prefixed and unprefixed implementation can
become a hindrance to unprefixing, because it means web developers
take a risk by switching to the unprefixed API.

Philip

[PhistucK]

On Tue, Jan 19, 2016 at 5:05 PM, Philip Jägenstedt <phi...@opera.com> wrote:

If it looks safe
compat-wise

​I agree.​

☆PhistucK

[Chris Harrelson]

Would it be possible to just remove support for those prefixed properties? How much would it break content?

--

[Morten Stenshorne]

The current support in Blink (that alters default behavior when
fragmenting into columns) can be summed up with the following 3
declarations:

-webkit-column-break-after: always;
-webkit-column-break-before: always;
-webkit-column-break-inside: avoid;

These declarations occur on 8000 of the 480500 sites (that's 1.66%) that
I got from httparchive, so it doesn't sound like a good idea to just
remove them.

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

> Would it be possible to just remove support for those prefixed properties?
> How much would it break content?
>
> On Tue, Jan 19, 2016 at 7:08 AM PhistucK <phis...@gmail.com> wrote:
>
>>
>> On Tue, Jan 19, 2016 at 5:05 PM, Philip Jägenstedt <phi...@opera.com>
>> wrote:
>>
>>> If it looks safe
>>> compat-wise
>>>
>>
>> ​I agree.​
>>
>>
>>

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

[Philip Jägenstedt]

On Wed, Jan 27, 2016 at 2:44 AM, Morten Stenshorne <mste...@opera.com> wrote:
>
> The current support in Blink (that alters default behavior when
> fragmenting into columns) can be summed up with the following 3
> declarations:
>
> -webkit-column-break-after: always;
> -webkit-column-break-before: always;
> -webkit-column-break-inside: avoid;
>
> These declarations occur on 8000 of the 480500 sites (that's 1.66%) that
> I got from httparchive, so it doesn't sound like a good idea to just
> remove them.

Right, dropping these outright doesn't seem like a good idea. 1.66% is
a big number, but do you know what proportion of sites matching
"-webkit-columns", "-webkit-column-count" or "-webkit-column-width"
also use one of the -webkit-column-break-* properties?

The risk is that unprefixing most of multicol would increase the
popularity of multicol, and that this would also proportionally
increase the use of "-webkit-column-break-", making it harder to
eventually remove. However, IMHO, it only makes sense to hold back on
unprefixing if we can see that multicol in the wild almost always
requires "-webkit-column-break-". If it's normally not required, then
as long as there's a plan to ship unprefixed counterparts within a
year or two, then I think unprefixing the current implementation is
the better trade-off.

Philip

[Morten Stenshorne]

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

> On Wed, Jan 27, 2016 at 2:44 AM, Morten Stenshorne <mste...@opera.com> wrote:
>>
>> The current support in Blink (that alters default behavior when
>> fragmenting into columns) can be summed up with the following 3
>> declarations:
>>
>> -webkit-column-break-after: always;
>> -webkit-column-break-before: always;
>> -webkit-column-break-inside: avoid;
>>
>> These declarations occur on 8000 of the 480500 sites (that's 1.66%) that
>> I got from httparchive, so it doesn't sound like a good idea to just
>> remove them.
>
> Right, dropping these outright doesn't seem like a good idea. 1.66% is
> a big number, but do you know what proportion of sites matching
> "-webkit-columns", "-webkit-column-count" or "-webkit-column-width"
> also use one of the -webkit-column-break-* properties?

TLDR; 26.66%

According to httparchive:

28801 of 481579 sites specify one or more of "-webkit-columns",
"-webkit-column-count" or "-webkit-column-width".

7677 of those 28801 sites specify one of the following declarations:

-webkit-column-break-after: always;
-webkit-column-break-before: always;
-webkit-column-break-inside: avoid;

(those are the only declarations that alter the default column breaking
behavior in Blink)

Among those three declarations, -webkit-column-break-inside:avoid is by
far the most popular one. Only 174 of the 7677 sites use
-webkit-column-break-(after,before):always.

> The risk is that unprefixing most of multicol would increase the
> popularity of multicol, and that this would also proportionally
> increase the use of "-webkit-column-break-", making it harder to
> eventually remove. However, IMHO, it only makes sense to hold back on
> unprefixing if we can see that multicol in the wild almost always
> requires "-webkit-column-break-". If it's normally not required, then
> as long as there's a plan to ship unprefixed counterparts within a
> year or two, then I think unprefixing the current implementation is
> the better trade-off.

FYI: Regardless of what we decide here, I'll send out an intent to
implement break-(after|before|inside) soon.

[Philip Jägenstedt]

So, 26.66% is more than the ideal 0%, but what we're talking about is
a risk that about a quarter of new uses of the unprefixed multicol
implementation would also add the prefixed break properties. It's not
a given that unprefixing will increase the overall
(prefixed+unprefixed) usage of multicol by much at all in the short
term, so IMHO this is all to speculative to block unprefixing on.

LGTM1, and it's great that we can expect to see an Intent to Implement
the missing unprefixed bits soon!

Philip

[PhistucK]

If the implementation for the standard break-before and friends is expected to take only a release or two, perhaps just ship them together? This way, we have a really standard implementation, without quirks or anything else (other than bugs, of course).

I do not think a delay of a release or two is so bad to the web community at large, while an incomplete and dependent-on-nonstandard-prefixed-properties implementation may cause some pain and confusion to developers ("if you implemented the standard, why is it not fully implemented?").

☆PhistucK

[Philip Jägenstedt]

To be pedantic, multicol doesn't depend on break-*, they're even in separate specs:

https://drafts.csswg.org/css-multicol-1/

https://drafts.csswg.org/css-break-3/

That Gecko supports only multicol (prefixed) and that a majority (73%) of webkit-prefixed multicol users get by without the break properties also suggests the usefulness of unprefixed multicol in isolation.

Shipping unprefixed multicol is the first step towards (possibly) removing prefixed multicol, and the impact on -webkit-column-break-* usage is too speculative for me to be willing to block this. My LGTM1 stands, but others may disagree.

[Philip Jägenstedt]

We discussed this at Tuesday's previous API owners meeting. With the discussion split across threads and a bit of back-and-forth on timeline, let's use this thread to decide what to ship together in a first iteration. The suggestion, which I've also briefly discussed with Morten, is:

• Unprefixed multicol CSS properties (this intent)
• column-fill, which was never prefixed
• New: break-after:auto|always, break-before:auto|always, and break-inside:auto|avoid

The last point can be considered an unprefixing of -webkit-columns-break-*, but is also covered by the Intent to Implement: CSS break-after, break-before, break-inside (Generic breaking control). The rationale is that this subset is clearly useful, and this outweighs the downsides to shipping partial support for these properties, namely the potential for web developer confusion. It's a move in the right direction.

Morten, can you confirm that this grouping makes sense, or clarify if there's some other timeline you'd prefer?

[Morten Stenshorne]

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

> We discussed this at Tuesday's previous API owners meeting. With the
> discussion split across threads and a bit of back-and-forth on timeline,
> let's use this thread to decide what to ship together in a first iteration.
> The suggestion, which I've also briefly discussed with Morten, is:
>

> - Unprefixed multicol CSS properties (this intent)
> - column-fill
> <https://groups.google.com/a/chromium.org/d/msg/blink-dev/WUUEUWha5cI/lnw0T_5XAgAJ>,
> which was never prefixed
> - *New:* break-after:auto|always, break-before:auto|always, and
> break-inside:auto|avoid

break-after and break-before take different values. "always" isn't
specified. You have to say things like "page" or "column" instead. But
that's just simple mapping.

> The last point can be considered an unprefixing of -webkit-columns-break-*,
> but is also covered by the Intent to Implement: CSS break-after,
> break-before, break-inside (Generic breaking control)

> <https://groups.google.com/a/chromium.org/d/msg/blink-dev/E6kHXWv4sJA/7fKGaApzCAAJ>.

> The rationale is that this subset is clearly useful, and this outweighs the
> downsides to shipping partial support for these properties, namely the
> potential for web developer confusion. It's a move in the right direction.
>
> Morten, can you confirm that this grouping makes sense, or clarify if
> there's some other timeline you'd prefer?

This is perfectly fine with me.

Then I first have to implement break-(after|before|inside) behind a
flag, or can I just ship it right away together with the rest (separate
CLs, by all means) with no runtime flag?

> On Fri, Jan 29, 2016 at 7:56 PM, Philip Jägenstedt <phi...@opera.com>
> wrote:
>
>> To be pedantic, multicol doesn't depend on break-*, they're even in
>> separate specs:
>> https://drafts.csswg.org/css-multicol-1/
>> https://drafts.csswg.org/css-break-3/
>>
>> That Gecko supports only multicol (prefixed) and that a majority (73%) of
>> webkit-prefixed multicol users get by without the break properties also
>> suggests the usefulness of unprefixed multicol in isolation.
>>
>> Shipping unprefixed multicol is the first step towards (possibly) removing
>> prefixed multicol, and the impact on -webkit-column-break-* usage is too
>> speculative for me to be willing to block this. My LGTM1 stands, but others
>> may disagree.
>>
>> On Fri, Jan 29, 2016 at 6:06 PM, PhistucK <phis...@gmail.com> wrote:
>>
>>> If the implementation for the standard break-before and friends is
>>> expected to take only a release or two, perhaps just ship them together?
>>> This way, we have a really standard implementation, without quirks or
>>> anything else (other than bugs, of course).
>>> I do not think a delay of a release or two is so bad to the web community
>>> at large, while an incomplete and
>>> dependent-on-nonstandard-prefixed-properties implementation may cause some
>>> pain and confusion to developers ("if you implemented the standard, why is
>>> it not fully implemented?").
>>>
>>>

>>> ☆*PhistucK*

[Philip Jägenstedt]

On Thu, Feb 4, 2016 at 12:33 PM, Morten Stenshorne <mste...@opera.com> wrote:
> Philip Jägenstedt <phi...@opera.com> writes:
>
>> We discussed this at Tuesday's previous API owners meeting. With the
>> discussion split across threads and a bit of back-and-forth on timeline,
>> let's use this thread to decide what to ship together in a first iteration.
>> The suggestion, which I've also briefly discussed with Morten, is:
>>
>> - Unprefixed multicol CSS properties (this intent)
>> - column-fill
>> <https://groups.google.com/a/chromium.org/d/msg/blink-dev/WUUEUWha5cI/lnw0T_5XAgAJ>,
>> which was never prefixed
>> - *New:* break-after:auto|always, break-before:auto|always, and
>> break-inside:auto|avoid
>
> break-after and break-before take different values. "always" isn't
> specified. You have to say things like "page" or "column" instead. But
> that's just simple mapping.

Ah, well as long as it's a simple mapping and you prefer including
break-after/before/inside in this round, that's fine.

>> The last point can be considered an unprefixing of -webkit-columns-break-*,
>> but is also covered by the Intent to Implement: CSS break-after,
>> break-before, break-inside (Generic breaking control)
>> <https://groups.google.com/a/chromium.org/d/msg/blink-dev/E6kHXWv4sJA/7fKGaApzCAAJ>.
>> The rationale is that this subset is clearly useful, and this outweighs the
>> downsides to shipping partial support for these properties, namely the
>> potential for web developer confusion. It's a move in the right direction.
>>
>> Morten, can you confirm that this grouping makes sense, or clarify if
>> there's some other timeline you'd prefer?
>
> This is perfectly fine with me.
>
> Then I first have to implement break-(after|before|inside) behind a
> flag, or can I just ship it right away together with the rest (separate
> CLs, by all means) with no runtime flag?

I'd say that the only reason to put it behind a flag is if regressions
are plausible and reverting would be conflict-prone without a flag.

A renewed LGTM1 to the above plan. Any other takers?

Philip

[Morten Stenshorne]

I don't expect regressions (but nobody expects regressions!!), but it's
trivial to revert it if it happens.

> A renewed LGTM1 to the above plan. Any other takers?
>
> Philip
>

[Chris Harrelson]

LGTM2

[Morten Stenshorne]

Thanks. One more LGTM still needed. :)

FWIW: WebKit is shipping with unprefixed multicol, including
column-fill, AND recently also with break-after, break-before and
break-inside, with the same limitations in the engine as Blink; i.e. in
particular no support for break-(after|before):avoid. It didn't take
David Hyatt very long to add those properties, once I contacted Apple as
part of surveying other vendors' views on those properties. In other
words, WebKit now does exactly what I propose that Blink do (this intent).

[Dimitri Glazkov]

LGTM51.