Forum Bugs

page-break-after and inline elements

cletus
It seems that page-break-after only works on block (and possibly inline-block) elements. I have some non-ideal HTML like this:

<li><b>RESULTS</b>
<table>
...


Now I'd like to make a rule such that there was no page break after this "heading" but it's hard. I had limited success with:

li > b:first-child {
  page-break-after: avoid;
}


It didn't stop the page break but I could style things like color with this selector. Unfortunately it would also pick up things like:

<li>You have <b>no</b> results...


(ie the bolded "no" would be selected).

I can't really change this bold tag to display: block so I"m a bit stuck.

Suggestions? Is this a bug?
mikeday
Page break properties only apply to block elements. It's hard to handle this case for the markup that you've posted, given that the <li> elements with the heading are not differentiated by a class name or anything like that. One option could be:
li > b:first-child:contains("RESULTS") { ... }

This should work in Prince at least.
cletus
Actually.. would this work?

li > b:first-child + table,
li > b:first-child + div,
li > b:first-child + table {
  page-break-before: avoid;
}


That would cover my important cases. I'm not sure how this would be affected thogh:

<li><b>Note:</b> Some text
<table> ...


There's text in the way. Would this still "pass" the + selector?
mikeday
Unfortunately "a + b" selects "b" not "a". At the moment in CSS there is no way to select an element that precedes another element or contains another element, you can only select elements that follow another element or are contained by another element. There are various proposals under consideration to extend CSS selectors to allow this, though.
cletus
Yes I realize a + b selects b but if I have:

<li><b>Heading</b>

<table>
...


then:

li > b:first-child + table {
  page-break-before: avoid;
}


will achieve what I want (maybe)?

I'll just need to test this and what happens in cases like this:

<li><b>Note:</b> something important.

<table>
...


with the same selector.
mikeday
Oh right, yes, that might help. Sorry for missing the point. :)