[css-logical][css-scoping] margin-inside / margin-outside

[christin-goetz]

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:

To control the "outer" margin for an element on a page (depending on whether the element is rendered on a right or left page), it would be great if the "margin" property could be extended by two new properties "margin-inside" and "margin-outside".

Prince XML already implemented this with the following properties:

• http://www.princexml.com/doc/properties/margin-inside/
• http://www.princexml.com/doc/properties/margin-outside/

An implementation of such property would make it easier to set up a paged media CSS for different rendering engines. At the moment you need different CSS settings for each render engine to achieve the described formatting.

Kind regards,
Christin

[frivoal]

I support this. As soon as you do any print work (or any non print work with pages / spreads), this is a very desirable feature. The need for float: inside and float: outside come about as quickly. In theory, anything that has a left or a right variant could need an inside and outside variant as well, but in my experience floats and margins are the most needed.

[ghost]

Sorry, but how would this behave when not printing (i.e. on a device’s screen)?

[tofi86]

@Zambonifofex does this matter? There are other yet existing properties which also aren't taken into account when rendering on screen (eg page-break-*)...

[ghost]

@tofi86

It’s not a deal‐breaker, but I just think this should be thought out. I just don't think it should do nothing when on a screen.

Another potential problem: what if the element is intersected by a page boundary? It might not be a problem if it applies margin to half of the element, but I think float would be confusing.

[frivoal]

The question is not screen vs paper, it is paginated vs not paginated. It is not the majority case, on-screen and paginated does exist.

Anyway, we can simply solve this problem by saying that in non paginated media, margin-inside maps to margin-inline-start and margin-outside to margin-inline-end, as it would on the first page of a paginated document.

[frivoal]

margin-inside maps to margin-inline-start and margin-outside to margin-inline-end, as it would on the first page of a paginated document.

Actually, -inline-start and -inline-end are the wrong answer, as it wouldn't do what you want in a vertical writing mode. What we want to map inside to right and outside to left for horizontal rtl / vertical-rl / sideways-rl, and the otherway around for horizontal ltr and sideways-lr.

[dbaron]

So this isn't quite as straightforward as things that depend on writing modes, since it is possible for whether you're treating something as being on a left or right page changes which page it's on.

For example, if you have an element with overflow:hidden (or some other element that establishes a BFC, like with [display: flow-root](https://drafts.csswg.org/css-display-3/#valdef-display-flow-root display:flow-root)) that is next to a float, then different combinations of margins that are changed as a function of whether the element is on a left or right page could control whether the element can fit next to the float or is pushed down below the float.

I think in these cases you'd need to specify that any such cycles are broken by pushing the element to the later page.

The question is not screen vs paper, it is paginated vs not paginated. It is not the majority case, on-screen and paginated does exist.

However, there are paginated displays that don't have a obvious inside/outside pages, e.g., if you're paginating on a screen. You can simulate it by just assuming the first page is a right page (or left page), but you might or might not want to.

[frivoal]

I think in these cases you'd need to specify that any such cycles are broken by pushing the element to the later page.

That seems ok with me.

However, there are paginated displays that don't have a obvious inside/outside pages, e.g., if you're paginating on a screen. You can simulate it by just assuming the first page is a right page (or left page), but you might or might not want to.

We probably want to do something in css-page-3 about that, as it currently seems to assume that if you are paginated, there always is a left/right recto/verso page (or if it doesn't assume that, it isn't very clear about it).

[fantasai]

Yes, css-page-3 assumes left/right recto/verso alternate, even if there aren't spreads. The same would be true here, I assume.

Another solution to this is using scoped styles, so you can target content on different pages and style the fragments of boxes on those pages accordingly. Either way, though, it's a much more complicated issue than the flow-relative mode, because it the mapping is resolved during layout, not during the cascade.