Should not "page-break-before: always;" work inside a DIV?

[Phlawm53]

------
For Flare 10.2.1, PDF Target.

IF a CSS class includes the element page-break-before: always;, should not that class cause a page break even if the class is assigned to, say, a heading contained within a DIV?

I have a CSS class as follows:

Code: Select all

.pageBreakBefore
{
  margin-top:0em;
  page-break-before: always;
  color: cornflowerblue;
}

IF I assign that class to a topic's heading ala h1.pageBreakBefore, THEN Flare places that heading on a new PDF page. That is as expected.

I also have a DIV that I use to position a topic's main content flow relative to the topic's BODY element:

Code: Select all

div.bodyAlignment	/*Use to position main body flow plus outdented headings for each media*/
{
  margin: 0em 0em 0em 2em;
  border: solid 1px magenta;
  padding: none;
  page-break-inside: avoid;
}

IF I wrap a topic's content in that DIV, THEN Flare does NOT place the heading of class .pageBreakBefore on a new PDF page. That is, the use of the DIV seems to cancel the page-break-before: always; attribute.

(NOTE that in that DIV the page-break-inside: avoid; attribute is an attempt to circumvent the original problem, described in the last paragraph of this post. The point I want to make here is that removing page-break-inside: avoid; from the DIV does NOT change the behavior as described: Assigning .pageBreakBefore to an XHTML element that is then wrapped in div.bodyAlignment will cause Flare to NOT place that XHTML element at the top of a new PDF page.)

The following screenshot illustrates the two behaviors (the fontcolor: cornflowerblue; and border: magenta; are there to help me verify that the CSS elements are in fact being applied):

PDFPageBreakAndDivProblem.png

Is this the expected, or if you will the "legal" behavior of page-break-before: always; if contained within a DIV? Or is this a bug?

My original problem, the reason I added page-break-inside: avoid; to the DIV, was to get sub-topics to start on a new PDF page. I had thought that using TOC —> Properties —> Printed Output —> Break Type —> Page Layout Break, then choosing Page Type = Normal would be the easiest way to do that. But that setting doesn't work as expected either — I get page breaks but each page is gen'ed as type First rather than Normal. So I then tried page-break-before: always; which led me to my current problem…

Cheers & thanks for your help,
Riley
SFO

[Phlawm53]

------
A bit of an update that further confuses the "proper" behavior of page-break-before within a DIV.

As part of crafting a circumvention, I tried wrapping everything EXCEPT a topic's initial H1 in div.bodyAlignment. So now Flare puts the un-wrapped H1.pageBreakBefore at the top of a new PDF page. So far, so good.

What's interesting is that IF a topic that contained a subordinate H2.pageBreakBefore, THEN Flare put that H2 at the top of a new page. So Flare honored page-break-before for headings that are not the first H1 in a topic.

So whatever "logic" exists regarding page-break-before within a DIV, it's inconsistent…

Cheers, thanks, & hope this helps,
Riley
SFO

[Phlawm53]

------
Aha — I was just informed by Madcap Support that "The behavior regarding the div overriding the page-break-before property is a bug."

Good to know from both a Flare perspective and a CSS perspective.

Bug number 90875 for those playing along at home…

Cheers & hope this helps,
Riley
SFO

[Phlawm53]

------
I also received an interesting comment about this problem on another forum:

Is it possible that the page break is not honoured for the h1 because it comes at the beginning of the div, and there is no space between the div and the heading? The css3 fragmentation rules (at http://www.w3.org/TR/css3-break/#breaking-controls) say that one of the three possible break points within a container is:

"Class C: Between the content edge of a block container box and the outer edges of its child content (margin edges of block-level children or line box edges for inline-level children) IF there is a (non-zero) gap between them."

Then the later h2 breaks might be honoured because they fit one of the other cases:

"Class B: Between line boxes inside a block container box."

Based on that comment I find myself inclined to believe that the behavior I'm seeing is in accordance with "CSS Law" rather than a bug(?)

Either way I've developed a couple of circumventions that can easily be Find/Replaced out of the project's XHTML when I finally get The One True Solution…

Cheers & hope this helps,
Riley
SFO

[mhd]

I experiment quite the same limitation in page-break application.

I have defined in my css:
.NoBreakInside{page-break-inside: avoid;}
And, at some places in my topics, I surround paragraphs with a div.NoBreakInside, just to be sure they're kept together in the output. It works perfectly.
But those div.NoBreakInside have absolutely no effect when inserted in dropdown texts (which are actually divs, at the end).

Let's hope the bug fix (if any) corrects this all.

[Phlawm53]

But those div.NoBreakInside have absolutely no effect when inserted in dropdown texts (which are actually divs, at the end).

Let's hope the bug fix (if any) corrects this all.

That sounds like a separate issue. I'd recommend documenting it and creating a separate bug report.

Cheers & hope this helps,
Riley
SFO

[jasonsmith]

I actually use this behavior as a Feature to prevent page-breaks before headings that usually break when I want more than one heading on a page...

[oceanclub]

But those div.NoBreakInside have absolutely no effect when inserted in dropdown texts (which are actually divs, at the end).

Let's hope the bug fix (if any) corrects this all.

That sounds like a separate issue. I'd recommend documenting it and creating a separate bug report.

Cheers & hope this helps,
Riley
SFO

I hit this issue now - 6 year later this bug is still not fixed. :/

P.