Intent to Implement: CSS break-after, break-before, break-inside (Generic breaking control)

[Morten Stenshorne]

Contact emails

mste...@opera.com


Spec

https://drafts.csswg.org/css-break-3/#breaking-controls


Summary

Add support for the modern fragmentainer break controlling properties
break-after, break-before and break-inside. Currently, Blink only
supports page-break-{after,before,inside} for printing and
-webkit-column-break-{after,before,inside} for multicol. Additionally,
the current state of the foo-break-after and foo-break-before properties
support in Blink is limited. Most importantly, there's no support for
the "avoid" value.

These new properties are meant to unify how breaks are controlled in any
type of fragmentation context - paged media (printing), multicol, and
CSS regions (which Blink doesn't support).

The CSS fragmentation spec says that the CSS 2.1 properties
page-break-after, page-break-before and page-break-inside are shorthands
for their corresponding generic break-after, break-before and
break-inside counterparts. I indend to do the same for the
-webkit-column-break* properties.


Motivation

The web deserves clean and fully functional generic fragment break
controlling properties!

Currently, the only thing that works in an rather interoperable way,
without vendor prefixes, is the properties for page breaking
(page-break-after, page-break-before, page-break-inside). Useful for
printing.

For multicol, the situation is much worse. It's a prefix soup. We have
desperate attempts like this on the web:

"break-inside:avoid-column; -moz-break-inside:avoid-column;
column-break-inside:avoid; -webkit-column-break-inside:avoid;
-moz-column-break-inside:avoid; -o-column-break-inside:avoid;"

-moz-break-inside, -moz-column-break-inside, -o-column-break-inside:avoid
have never been supported by anyone, AFAIK.

The various layout engines also generally have limited support for the
properties that they recognize. Mozilla has very limited support (it
seems to only support page-break-inside:avoid in a multicol
context!). Apart from that, only automatic breaking in Mozilla. MSIE has
partial support for the modern properties (break-after, break-before and
break-inside), while Blink and WebKit have partial support for prefixed
properties. Only the following declarations are currently supported:

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

(note that the column-break-foo properties are not defined in any spec,
but I suppose they must have been at some point in history)

There's no way in Blink to specify that breaks should be avoided before
or after a block, for instance. One would think that authors generally
would very much like to avoid breaking between a header block and the
first paragraph of the chapter, for instance.


Interoperability and Compatibility Risk

Low risk.

These properties are currently partially supported by IE (and to a
fuller extent, by Presto).

Since this change is about funneling everything into break-after,
break-before and break-inside, and treating everything else as
shorthands for those, declaration sequences like this:

"-webkit-column-break-inside:avoid; page-break-inside:auto;"

will work differently compared to how it works now.
-webkit-column-break-inside:avoid will map to break-inside:avoid, but it
will be overwritten by the page-break-inside:auto, which will map to
break-inside:auto. I don't expect that to me much of an issue, though.

According to httparchive, break properties in any form (*break-after,
*break-before, *break-inside) are used on 25.99% of the sites. A
majority of the sites only use page-break-* properties. Filtering out
those, we're left with 2.17% of all sites that use the other break
properties (vendor-prefixed + the generic ones (break-after,
break-before and break-inside)).

The generic break-after, break-before and break-inside properties are
used on 1.38% of all sites. They typically occur alongside with prefixed
properties for column breaking; e.g.:

"-webkit-column-break-inside:avoid; -moz-column-break-inside:avoid;
break-inside:avoid-column;"


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://crbug.com/223068


Link to entry on the feature dashboard

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


Requesting approval to ship?

No.

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

[PhistucK]

I have mixed feelings about break-foo: bar affecting -webkit-column-break-foo: baz, but other than that - this is great!

☆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 Mon, Feb 1, 2016 at 4:45 PM, Morten Stenshorne <mste...@opera.com> wrote:
> Since this change is about funneling everything into break-after,
> break-before and break-inside, and treating everything else as
> shorthands for those, declaration sequences like this:
>
> "-webkit-column-break-inside:avoid; page-break-inside:auto;"
>
> will work differently compared to how it works now.
> -webkit-column-break-inside:avoid will map to break-inside:avoid, but it
> will be overwritten by the page-break-inside:auto, which will map to
> break-inside:auto. I don't expect that to me much of an issue, though.

Have you seen combinations of auto and avoid using different (now to
be aliased) property names in the wild, or is the hypothetical? If
there's no reason to suspect it to occur in the wild, then the risk
seems very small.

Also, the subset already supported by Blink with prefixes sounds very
useful. Is that subset more or less in line with the spec? If it is,
then unprefixing only that subset first doesn't seem crazy, but it's
up to you :)

Philip

[Morten Stenshorne]

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

> On Mon, Feb 1, 2016 at 4:45 PM, Morten Stenshorne <mste...@opera.com> wrote:
>> Since this change is about funneling everything into break-after,
>> break-before and break-inside, and treating everything else as
>> shorthands for those, declaration sequences like this:
>>
>> "-webkit-column-break-inside:avoid; page-break-inside:auto;"
>>
>> will work differently compared to how it works now.
>> -webkit-column-break-inside:avoid will map to break-inside:avoid, but it
>> will be overwritten by the page-break-inside:auto, which will map to
>> break-inside:auto. I don't expect that to me much of an issue, though.
>
> Have you seen combinations of auto and avoid using different (now to
> be aliased) property names in the wild, or is the hypothetical? If
> there's no reason to suspect it to occur in the wild, then the risk
> seems very small.

I haven't seen it. Yes, I believe the risk for this being a problem is

very small.

> Also, the subset already supported by Blink with prefixes sounds very
> useful. Is that subset more or less in line with the spec? If it is,
> then unprefixing only that subset first doesn't seem crazy, but it's
> up to you :)

Is it acceptable to lack support for the avoid* values in break-before
and break-after? That's what MSIE does, FWIW. But Blink also lacks
support for "left" and "right", and the ability to supports page breaks
inside multicol containers properly. MSIE supports this. But then again,
we're already shipping page-break-after and page-break-before with all
these shortcomings...

Blink also has issues with margins adjoining forced breaks (margins
sometimes collapse with page or column boundaries when they
shouldn't). But we can of course say they are just bugs and carry on. :)

[PhistucK]

Why would a new property be implemented without support for all of its values?

Why should it be done incompletely?

A complete implementation is preferred, even if Blink is the first. Partially supporting things is very hard to justify to a web developer and leads to great frustration.

☆PhistucK

[Philip Jägenstedt]

Could the lack of support be entirely understood as a lack of support
for certain property values? If so, and assuming that it can be
detected using CSS.supports('break-after', 'avoid') and similar, then
IMHO it'd be fine to ship the limited subset. Put another way,
ignoring the aliasing issues, do you expect that implementing the
other property values would change the behavior of the already
implemented subset, other than fixing bugs that you happen to stumble
upon?

Philip

[Daniel Bratell]

On Mon, 01 Feb 2016 14:05:32 +0100, PhistucK <phis...@gmail.com> wrote:

Why would a new property be implemented without support for all of its values?

Why should it be done incompletely?

A complete implementation is preferred, even if Blink is the first. Partially supporting things is very hard to justify to a web developer and leads to great frustration.

As a semi-interested observer this chain of standards seems to extend into infinity.

There are column-fill, improved multi-column and break properties as three different (but intertwined) shipping/implementation requests and in each of them it seems like we get stuck because it would be possible to support even more properties or functionality. It seems to me that at some point we have to say "ok, in this iteration we'll complete these things and we'll leave the rest to the next iteration" or we'll never ship anything.

Maybe this is that point.

In one of the threads there was a worry that some prefixed properties would become used more because people would use columns more after they become unprefixed. To me that seems less likely than that people using prefixed properties more because we don't ship unprefixed column properties at all so shipping columns unprefixed would improve the overall situation. We should not lose the overall picture.

/Daniel

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Morten Stenshorne]

No.

[PhistucK]

I do not think the chain is that infinite. Those three features (unprefixed multiple column, column-fill and break-foo, including all of their values) are used together in the same context - multiple columns. Again, if developing all of these takes a release or two, I think it is worth it. If it is expected to take much more, then shipping a partial implementation might make more sense.

☆PhistucK

[Domenic Denicola]

From: blin...@chromium.org [mailto:blin...@chromium.org] On Behalf Of Daniel Bratell

>> On Mon, 01 Feb 2016 14:05:32 +0100, PhistucK <mailto:phis...@gmail.com> wrote:
>> Why would a new property be implemented without support for all of its values?
>> Why should it be done incompletely?
>> A complete implementation is preferred, even if Blink is the first. Partially supporting things is very hard to justify to a web developer and leads to great frustration.
>>
> As a semi-interested observer this chain of standards seems to extend into infinity.
>
> There are column-fill, improved multi-column and break properties as three different (but intertwined) shipping/implementation requests and in each of them it seems like we get stuck because it would be possible to support even more properties or functionality. It seems to me that at some point we have to say "ok, in this iteration we'll complete these things and we'll leave the rest to the next iteration" or we'll never ship anything.

I agree. This kind of entitled cry for more is not a very good way of evolving the web. Or, as Jake says in https://jakearchibald.com/2015/thats-so-fetch/#fetch-isnt-done-yet:

> Bit of a rant: it bothers me that as [web] developers, we preach iterative development and release, but when we're the customers of that approach the reaction is all too often "HOW DARE YOU PRESENT ME WITH SUCH INCOMPLETE IMPERFECTION".
>
> The alternative would have been to sit on the feature for months (or years?) instead of getting large parts of it into developers' hands today. Iterative release also means we've been able to get feedback from real-world usage, and that steers future iterations in terms of design and priority.

I think the pushback here against incremental development is entirely unwarranted and does a disservice to web developers.

[PhistucK]

I think there is a difference when the feature is already pretty much complete, but prefixed. Shipping partial implementation that involves intertwined usage of prefixed and standard properties is a recipe for badness.

Also, as I wrote before, a release or two (which means, twelve weeks - less than three months) is not that long of a pushback.

(It is true that column-fill specifically is held for much more than a few months already, but I do think it is warranted)

And yes - it is about drawing the line, obviously and the length of the period matters here.

☆PhistucK

[Philip Jägenstedt]

Well, in that case I would definitely support shipping the implemented
subset together with unprefixing multicol and shipping column-fill. If
you'd like that, perhaps you can amend your "Intent to Ship:
Unprefixed multicol CSS properties" to also cover the three
-webkit-column-break-* properties? I'll take this Intent to Implement
to cover the remaining bits, and it doesn't need any LGTM.

(I have read the later messages in this thread and largely do not
share PhistucK's concerns.)

Philip

[PhistucK]

Unless I am misunderstanding something, the patch removed all of the prefixed properties from CSSOM.

https://crrev.com/c78e9708e49aa13bd5bd9382983f4aa060680dfd

That was not discussed.

☆PhistucK

[Philip Jägenstedt]

You can test the changes in Chrome Canary. AFAICT from black box testing, it's only the enumerability that has changed, actually accessing the properties using their old (now shorthand) names works:

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3920

Making the shorthand names non-enumerable seems incredibly low risk. In computed-style-listing.js there's a short list of non-enumerable properties that are manually added to the output, but that seems like overkill for this.

[PhistucK]

It does seem low risk. It is still good to mention that, as it is a web facing change.

Thank you for the clarification.

☆PhistucK

[me...@figjamit.com.au]

Hi Morten, Is the specification for how breaks have been implemented in Blink publicly available? I need to prevent a page break between two divs, one contains the section title and the next contains the section content, and I’m beginning to think it’s not possible...

[Morten Stenshorne]

Unfortunately, the major thing missing in Blink is break-before:avoid* and break-after:avoid*. In other words exactly what you'd use to prevent breaks between two DIVs. :-/

On 29 November 2017 at 20:34, <me...@figjamit.com.au> wrote:

Hi Morten, Is the specification for how breaks have been implemented in Blink publicly available? I need to prevent a page break between two divs, one contains the section title and the next contains the section content, and I’m beginning to think it’s not possible...

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/deca1030-b182-4ac5-90bf-1bb4ff02deee%40chromium.org.

[Amelia Axford]

Thank you for the clarification.