Box model

[bertfrees]

Box Model

• Bring in connection with "Box model for breaking", to be added to "Paged Media" (see Paged media #28)

Anonymous Boxes

• What if two inline-level boxes that contain block-level boxes are "unwrapped" after which two of the resulting anonymous boxes become siblings? in that case the anonymous boxes should become a single block-level box, but I can't find that in the CSS specification.

Collapsing Margins

• The top and bottom margins of the root element's box and any adjoining margins should become nil. (EDIT: this is liblouis behavior, but will not be part of braille CSS for now, see below)
• Margins should also collapse at the top/bottom of a page, and before/after a print page break indicator. (EDIT: this is liblouis behavior, but will not be part of braille CSS for now, see below) (2nd EDIT: what does http://www.w3.org/TR/2012/WD-css3-break-20120823/#break-margins mean?)
• Margins should collapse at the bottom of pages (margins are implemented this way in Dotify)
• Top/bottom page margins could "collapse" with block margins in such a way that text can flow into headers and footers if they have no content except for the right corner. Page padding could be used to disable this behavior. (EDIT: this was achieved by changing to the behavior of page-margin boxes instead, see commit 013cbd2, and issue Text flow into header/footer #22)

The 'display' property

• Differences with original display property: no table, no run-in, ...

Margins

• Combination of a border and a negative margin: implementation dependent?

---

See also

• http://www.w3.org/TR/2007/WD-css3-box-20070809/#the-lsquo
• http://www.w3.org/TR/CSS21/visuren.html#display-prop
• http://www.w3.org/TR/CSS21/visuren.html#position-props
• http://www.w3.org/TR/CSS21/box.html#border-properties
• http://dev.w3.org/csswg/css-position/#box-offsets-trbl
• http://www.w3.org/TR/css3-background/#borders

[bertfrees]

The problem with collapsing margins at the top of a page is that you can't get the following behavior (example from @joeha480):

--- page ---

h1
...

and

--- page ---
list (with bottom margin)

h1
...

For this reason we decided to drop that part for now.

[bertfrees]

In order to get the following behavior:

--- page ---
h1
...

and

--- page ---
p (or any other element)

h1
...

we can make use of the fact that empty lines at the bottom of the page are suppressed: if we make the top margin of h1 into a bottom margin of the previous element, it will not be visible at the top of the page nor at the bottom of the page.

:has(+ h1) {
  margin-bottom: 1;
}

[joeha480]

@bertfrees Nice! However, shouldn't it be margin-bottom: 1?

[bertfrees]

Corrected.

[mixa72]

Making the top margin of an element into a bottom margin of the previous element indeed works with the above mentioned and similar css patches. There are, however, many corner cases which have to be taken into account. The majority of them are caused by a preceding pagenum element: as it is set to display:none in general, the following code will not create any margin below it.

*:has(+ h1) {
  margin-bottom: 1;
}

Only this additional workaround will give the expected result:

*:has(+ pagenum:has(+ h1)) {
  margin-bottom: 1;
}

The same applies to margins before paragraphs: they should not show at the beginning of a new page. If preceded by a pagenum element, this code can be used:

*:has(+ pagenum:has(+ .precedingemptyline)) {
  margin-bottom: 1;
}

Nevertheless, the whole story gets more complex when there are not only one but multiple pagenum elements before the paragraph due to some empty pages or an illustration omitted in the source file. Then, each of the possible cases needs to be covered separately in the CSS.
Last but not least the number of corner cases is also increased by freely positionable blocks such as (multiple) note containers in the file. These combined with (multiple) pagenum elements make it almost impossible to cover everything.
In conclusion, an additional parameter to choose the behaviour of 'margin-top' would be a welcome alternative to the so far existing workaround. It would also keep the CSS manageable and user-friendly.

[dkager]

From this discussion it sounds like suppressing top margins at the start of a page would be a useful addition. Furthermore, some way of testing whether an element ends up at the top of the page would be useful, since e.g. pagenums shouldn't be displayed there (but they should be displayed inline in the text).

[dkager]

I thought to be clever and added the margins to the element before the level, e.g. :has(+ level2) { margin-bottom: 2; }.
But this has another problem. In the following XML:

<level1>
<pagenum page="normal" id="p-1">1</pagenum>
<h1>Hoofdstuk 1</h1>
<level2>
<pagenum page="normal" id="p-2">2</pagenum>
<h2>Paragraaf 1</h2>
</level2>
</level1>

... the <h1> now has two rules, the one I mentioned above and h1 { margin-bottom: 1; }. A quick glance at the PEF shows that the latter wins.
Trimming top margins at the top of a page would be a huge improvement IMO. Why is this not done yet? That is, is it a design choice or is it difficult to implement?

[bertfrees]

For an explanation of why this is not done yet see discussion above.

[dkager]

It looks like you could work around the problematic case with a ::first-on-braille-page pseudo-element, but I have no idea if that would be feasible at all given the order of execution in the Pipeline.
I suppose it boils down to which behavior leads to more corner cases. Could it be made a configurable option as @mixa72 suggested?

[bertfrees]

Yes, going to work on this soon, see daisy/pipeline-mod-braille#97.