break inside

[bjarteskogoy]

We depend on the isBreakInside to layout text. In some cases the text will be to large to fit on the designated area. In that case we would want it to not be monolithic. How could this be addressed?

[bjarteskogoy]

I tried to fix this. I changed isMonolithic to also get the region as an argument and adding a check after var isBreakInsideAvoid = this.is +++

    //Should only avoid break inside if possible
    if(isBreakInsideAvoid) {
        var elementHeight = parseFloat(elementStyle.height, 10);

        if(elementHeight >= region.cssRegionHost.offsetHeight)
            isBreakInsideAvoid = false;
    }

Is this an OK solution?

[bjarteskogoy]

No that won't work properly. The region may already be partly filled up with other content. Have to check if there's a parent up to the region with a smaller height than the current element maybe.

[FremyCompany]

I guess you may need to add a check once the region is filled to check if it somehow overflows.

If it does, you can start over its layout and pass an argument telling to ignore isBreakInsideAvoid. That may require some important rewrite, though.

[bjarteskogoy]

Second thought. I think the first approach is correct. If the element alone is to large for a region then it is allowed to break it.

[FremyCompany]

So, what you want is to relax the "non-null fragmentation" rule so that it accepts to break inside an element in which you should avoid to break if it's the first element of the region and it still doesn't fit, right? It may easier to tweak it from there, in such case: https://github.com/FremyCompany/css-regions-polyfill/blob/master/src/css-regions.js#L487

[FremyCompany]

The advantage is that, if it's done from there and not upfront, is that I could make the change for everyone without making it too computationnally expensive.

[bjarteskogoy]

The spec says that the break-inside for regions should be treated just like break-inside for pages: http://www.w3.org/TR/css-regions-1/#region-flow-break ("The behavior of region breaks with regards to regions is identical to the behavior of page breaks with regards to pages")

The spec for break-inside for pages says that a break should be avoided, if possible.

So the theory should anyway be that if an element with break-inside: avoid or avoid-region can't fit inside the region, it can be broken up. As far as I understand. And this would also be what we need. The code I proposed is doing that, it seems to me. But haven't tested it very much. Any code producing the expected result is fine with me :)

[FremyCompany]

On second thought, my code won't do exactly what you need because it would try to break inside the "avoid-break element" as soon as possible, and not where appropriate. Your code may actually work better in this case.

However, I'm afraid it's kinda inefficient. It would be better to improve the second pass layout and make it do the same as the first pass but by ignoring some monolithic rules like avoid-break-inside.

[FremyCompany]

I'm pretty sure your code will face issues in some edge cases like:

region-host (height: 100px)
{ 
     wrapper (padding: 10px) {
          element (height: 100px; margin: 10px; break-inside: avoid);
     }
}

The advantage of a real second pass is that we get a well-tested layout algorithm do the job.

[bjarteskogoy]

Ok. How would I go about to do this in a second pass?

[FremyCompany]

The basic idea would be: put everything before the linked line of "extractOverflowContent" in a function "performExtractionPass(acceptBreakInside)" then call it once with the value false. Then, if the condition of "no-content-did-fit" is true (see the linked line), call it once again with the value true (and propagate this value further down so that isMonolithic accepts to break Inside such elements). Then, if the "no-content-dit-fit" condition is still met (the issue wasn't a break-Inside-avoid), you can keep the current code as a third pass (it will eat the content up to the first possible breaking opportunity).

[bjarteskogoy]

I assume you mean "extractOverflowingContent"?
Does this mean to edit the "layoutContentInNextRegionsWhenReady" function?

[FremyCompany]

Right, I meant "extractOverflowingContent". Doing the change I proposed should not affect any method calling "extractOverflowingContent" so there's no need to update "layoutContentInNextRegionsWhenReady".