[css-break-4] control space before element depending on page position

[SebastianZ]

On 29 June 2016 at 09:25, Christin Götz | pagina GmbH wrote:

Hei,

I’m working in book industry and my daily business is to set up CSS for
paged media. I have come across some shortcomings with the CSS paged media
specs recently and want to let you know about this:

In the CSS Paged Media Specification I'm missing a property to control the
"space before" an element (like a heading) depending on the current
rendering position on the page.

For example: in CSS I define a "margin-top" for headings:

heading {
    margin-top: 2em;
    }

However, the "margin-top" should NOT be applied when the heading is rendered
as the first(!) element on the page to assure that there's no additional
spacing rendered at the beginning of the text box.

This use case is an important and daily requirement in publishing industry.
Thus, it would be great if a CSS property to control the space before an
element will be added to the CSS spec in future.

Kind regards,
Christin

This was first posted to www-style.

Sebastian

[SebastianZ]

While I agree that this is a valid use case, this can already be achieved using the :first-of-type pseudo-class.

So, picking up the example (using a valid heading selector), you may want to use this:

h2:first-of-type {
  margin-top: 2em;
}

Sebastian

[astearns]

Sebastian - I don't think that's the case. Christin is talking about pages, so it's content in a fragmentation context. He likely has several headings in the document and wants the margin to apply to all of them except those whose start edge happen to be placed at the top of the fragmentation container. The :first-of-type pseudo-class knows only about parent elements and nothing about fragmentation.

[tofi86]

Hi Sebastian,

thanks for pointing us to the issue tracker and for your first answer.

I don't think that :first-of-type is a solution for @christin-goetz's requirement as it does not take into account the current position on the page (which may be unequal to the current position in the DOM).

Say weh have the following structure:

<h1>
<p>
<p>
...
<p>
<h2>
<p>
<p>
<h2>
<p>
<p>

and the following css snippet

heading {
    margin-top: 2em;
    }

The h2 element should display WITH margin top when rendered somewhere on the page, surrounded by paragraphs. But it should render WITHOUT margin top when it is the first item on the new page.

The :first-of-type selector would only match the first occurance of h2 regardless of whether or not it is rendered at the bottom or as the first item on the page. And it wouldn't even match the 2nd occurance.

Did this example made our point clearer?

Regards,
Tobias

[frivoal]

There's precedent for this in Antenna House Formater, and we are considering supporting it or something similar in Vivliostyle:

https://www.antennahouse.com/product/ahf60/docs/ahf-ext.html#axf.margin-break

margin-break

Specifies how to treat the margin when the page/column breaks.
Value: [ auto | discard | keep ] keep?
Initial: auto
Applies to: block elements
Inherited: no
Percentages: N/A

Values have the following meanings.

auto
Retains the margin on the before side of the block
placed at the start of the document or right after
the forced page/column break. Except for that, it
is the same as discard.

discard
Discards the margin.

keep
Retains the margin on the before side. When the
second keep is specified, the margin on the after
side is also retained.

[fantasai]

Yes, we should definitely add margin-break to css-break L2. :)

Wrt the original use posted use case: the margin should disappear, unless there's a forced break specified. If there's a forced break specified, likely it's possible to select that element and also set its margin-top to zero!

[christin-goetz]

@frivoal Thanks for your post. I already know the ah-property -ah-margin-break. But unfortunately it doesn’t work in all case. Meaning, the setting works when heading is a "normal" (non floating) block element. But there are problems in rendering if the heading is a container for other structures like hcounter and hcontent and this elements are floating elements. In this case the setting doesn’t work correct. (I already sent a support mail to AH and they will fix it)

<heading>
   <hcounter/>
   <hcontent/>
</heading>

heading {
    display: block;
    page-break-inside:avoid;
    page-break-after:avoid;
    }
heading > hcounter,
heading > hcontent {
    margin-top:1in;
    margin-bottom:1em;
    -ah-margin-break:discard;
    display:block;
    float:left;
    }

Yeah, it's nice to have proprietary css-settings. But, in my opinion it isn't a solution (in the long time view). Thus, it would be great to add a property (like margin-break) to W3C CSS spec (because the most renderer support the recommended CSS properties). This is the reason why I sent the request ...

[frivoal]

@christin-goetz I completely agree that this should be added to standard CSS, and that proprietary extensions are only a stop-gap measure. I was pointing at -ah-margin-break as inspiration for what we should have in the standard, not as a reason not to do this.

But there are problems in rendering if the heading is a container for other structures like hcounter and hcontent and this elements are floating elements. In this case the setting doesn’t work correct. (I already sent a support mail to AH and they will fix it)

Could you give more details about what problems you've run into with -ah-margin-break, and what you think should be done instead?

[christin-goetz]

@frivoal The problem at the moment is that I get this rendering result if the heading is a container element (and I use AHFormatter)

<root>
   <content>
    <heading>
        <hcounter>heading 1</hcounter> 
        <hcontent>at start of page</hcontent>
    </heading>
    <body>body 1</body>
        ...
    <heading>
        <hcounter>heading 2</hcounter> 
        <hcontent>after page break (depends on rendering)</hcontent>
    </heading>
    <body>body 2</body>
    ...
       <heading>
        <hcounter>heading 3</hcounter> 
        <hcontent>Text</hcontent>
    </heading>
    <body>body 3</body>
    ...
        <heading style="page-break-before: always">
        <hcounter>heading 4</hcounter> 
        <hcontent>after page break (depends on CSS)</hcontent>
    </heading>
    <body>body 4</body>
    ...
   </content>
</root>

@page {
    background-color:lightblue;
    margin: 1in;
    }
content {
    display: block;
    background-color:lightgreen;
    }
heading {
    display: block;
    page-break-inside:avoid;
    page-break-after:avoid;
    }
heading > hcounter,
heading > hcontent {
    margin-top:1in;
    margin-bottom:1em;
    -ah-margin-break:discard;
    display:block;
    float:left;
    font-weight:bold;
    }
heading > hcounter {
    width:25%;
    }
heading > hcontent {
    width:75%;
    }
body {
    clear: both;
    display: block;
    }

How you see, the -ah-margin-break-property works correct for the first heading element at page. But the margin before the following heading (heading 3, red marked) is also discard. And this shouldn't be.

That there is maybe a problem with the float I deduced from the case that the setting work well if my heading is a "normal" (simple) element

<root>
   <content>
    <heading>heading 1 at start of page</heading>
    <body>body 1</body>
    ... 
    <heading>heading 2 after page break (depends on rendering)</heading>
    <body>body 2</body>
    ...
    <heading>heading 3</heading>
    <body>body 3</body>
    <heading style="page-break-before: always">heading 4 after page break (depends on CSS)</heading>
    <body>body 4</body>
   </content>
</root>

@page {
    background-color:lightblue;
    margin: 1in;
    }
content {
    display: block; 
    background-color:lightgreen;
    }
heading {
    display: block;
    margin-top:1in;
    margin-bottom:1em;
    -ah-margin-break:discard;
    font-weight:bold;
    }
body {
    display: block;
    }

I think to add a CSS property like -ah-margin-break to CSS spec is a solution. If this property is supported by formatters and is rendered correct there are no further need instead ...

[frivoal]

@christin-goetz As far as I can tell, the problem you are talking about is a bug in AH's implementation, and if you "correctly" implement the property according to its documentation (https://www.antennahouse.com/product/ahf60/docs/ahf-ext.html#axf.margin-break), it wouldn't do that. Do you agree?

[christin-goetz]

@frivoal Yes, I agree. It seem to be a bug at AHFormatter (currently). I already sent a support mail to AH.

[atanassov]

We need to discuss this over our next F2F during TPAC.

[mstensho]

https://www.antennahouse.com/product/ahf60/docs/ahf-ext.html#axf.margin-break makes sense to me, except for the margin-block-end thing. This should only control margin-block-start.

[css-meeting-bot]

The CSS Working Group just discussed fragmentation, and agreed to the following:

• RESOLVED: Add margin-break to break L4

The full IRC log of that discussion

<gregwhitworth> Topic: fragmentation
<gregwhitworth> fantasai: the suggested was to add a margin break property which controls how margin behaves at page breaks
<astearns> github: https://github.com//issues/253
<gregwhitworth> fantasai: if you have to start a new fragmentation then the margin after it is preserved, for example a new margin heading
<gregwhitworth> fantasai: if you're at an unforced break then it isn't preserved - this makes sense because margins are there to create space between things
<gregwhitworth> fantasai: so this would allow you to keep or discard
<gregwhitworth> fantasai: auto, keep, discard are proposed keywords in fragmentation L4
<gregwhitworth> fantasai: this is the only thing in that level
<gregwhitworth> florian: this property exists in the antenna house formatter
<gregwhitworth> Rossen: is there any discrepency on the type (columns, page, etc)
<gregwhitworth> fantasai: no they all behave the same
<gregwhitworth> jensimmons: I beleive this fixes one of the things that bugs me with multicolumn
<gregwhitworth> fantasai: we would have to be clear that it would occur with the different fragmentainers
<gregwhitworth> fantasai: there are different set of issues that are dealing with margins that aren't fragmented
<gregwhitworth> TabAtkins: would this apply to general BFC?
<jensimmons> rachelandrew: what’s the number of that bug?
<gregwhitworth> fantasai: no
<gregwhitworth> TabAtkins: to me that sounds like the thing that Jen just asked for
<rachelandrew> 1939
<gregwhitworth> fantasai: we need to determine if it works with the first fragmentainer or not
<jensimmons> This is the bug we need fixed. https://github.com//issues/1939
<florian> https://www.antennahouse.com/product/ahf60/docs/ahf-ext.html#axf.margin-break
<gregwhitworth> gregwhitworth: and it's the same 1:1 scenario?
<gregwhitworth> florian: yes
<gregwhitworth> TabAtkins: I'm curious why they only allow after margin
<gregwhitworth> fantasai: because the only option is keeping it because currently it's truncated
<fantasai> s/truncated/always truncated/
<TabAtkins> s/only allow/only allow an optional 'keep' for/
<gregwhitworth> Rossen: this propety, if we bring it forward to fragmentation 4...
<emilio> So, is `auto keep` a valid value? That sounds wrong
<gregwhitworth> fantasai: we could also put it in box 3 or 4, etc
<gregwhitworth> fantasai: there's little requested, this is currently the only thing
<gregwhitworth> Rossen: any other opinions about margin break?
<gregwhitworth> emilio: does it allow the auto keep value to be correct, because that's kind of weird
<gregwhitworth> florian: I recommend we open an issue on that
<gregwhitworth> emilio: sure
<gregwhitworth> jensimmons: I don't want to bikeshed the name, but is margin-break the right name?
<gregwhitworth> fantasai: we have margin-decoration-break as well so this carries that forward
<TabAtkins> AH behavior: https://github.com//issues/253#issuecomment-229367559
<gregwhitworth> iank_: this only applies to forced breaks?
<gregwhitworth> fantasai: this is expected to work on anything that has a margin
<gregwhitworth> Rossen: ok, I'm hearing people are in favor for break L4
<TabAtkins> auto=discard on unforced breaks, keep on forced or start-of-container; discard=discard on all breaks; keep=keep on all breaks
<gregwhitworth> Rossen: people can open issues against the proposal
<gregwhitworth> Rossen: Objections?
<gregwhitworth> RESOLVED: Add margin-break to break L4
<TabAtkins> end-side break is always discard right now, regardless of break type; option to specify "keep" for those too.
<TabAtkins> <br dur=20min>
<heycam> scribenick: heycam

[fantasai]

Checked in. Thanks very much for tracking this, @SebastianZ !
I filed a follow-up issue about what margin-break: keep means for the block-end margin at #3254 @mstensho

[SebastianZ]

Checked in. Thanks very much for tracking this, @SebastianZ !

I just kicked off the discussion here on GitHub. Thanks to everyone providing valuable input and for adding margin-break!

Sebastian