Re: [css3-page] Flexbox or table algorithm for page-margin box layout

Le 25/03/2013 15:41, Håkon Wium Lie a écrit :
> Hello Simon,
>
>   > > How about using the table algorithm? The rendering of the top margin
>   > > boxes would be described with:
>   > >
>   > > <style>
>   > >   #top-left-corner { text-align: right; vertical-align: middle }
>   > >   #top-left { text-align: left; vertical-align: middle }
>   > >   #top-center { text-align: center; vertical-align: middle }
>   > >   #top-right { text-align: right; vertical-align: middle }
>   > >   #top-right-corner { text-align: left; vertical-align: middle }
>   > >   #page-area { /* determined elsewhere */ }
>   > > <style>
>   > > <table>
>   > >   <tr><td id=top-left-corner><td id=top-left><td id=top-center><td id=top-right><td id=top-right-corner></tr>
>   > >   <tr><td><td colspan=3 id=page-area><td></tr>
>   > > </table>
>   >
>   > Maybe there something in this direction, but the code above is not enough:
>   >
>   > 1. If there is any content in #top-left or #top-right, #top-center may
>   > not be centered compared to #page-area.
>
> Right. We could add a constraint that:
>
>   #top-right.width = max (#top-left.width, #top-right.width )
>   #top-left.width = max (#top-left.width, #top-right.width )
>
> Or something.

The automatic table layout algorithm is already very complex. (Well, 
it’s not specified, but the next best thing describing what browsers do 
is http://dbaron.org/css/intrinsic/ )

I think that a single algorithm that supports tables (with colspan, 
column groups…) *and* at the same time supports additional constraints 
like the above is just not realistic.

So, maybe doing "like tables" with a different algorithm that accounts 
for these constraints? I believe this is exactly what’s currently in the 
spec:

http://www.w3.org/TR/2013/WD-css3-page-20130314/#variable-sizing


> It's not ideal as it cannot be represented in CSS. But it ensures that
> overlap doesn't happen.
>
>   > 2. Large unbreakable content in #top-left-corner will make the column
>   > smaller (even if the cell has a fixed 'width'), which in turn probably
>   > makes #page-area smaller.
>
> The dimension/size of #page-area must be the strongest constraint --
> we never want margin boxes to change the dimension/size of the page
> area. This could probably be represented formally by "!important" or
> something.

!important only affects the cascade, and does not change the fact that 
'width' on table cells is actually more like 'min-width'. With wide 
enough unbreakable content (aka. 'min-content' or preferred minimum 
width) table cells can be wider than specified by 'width'.

So this kind of constraint needs to be in the layout algorithm, which 
raises the same issue as above.


>   > > Margin boxes on the side of a page often need even more precise
>   > > placement:
>   > >
>   > >   http://people.opera.com/howcome/2013/tests/margin-boxes.jpg
>   >
>   > I think there is no difficulty in doing this in a printed book. If you
>   > know the size of your paper, fonts and content, just use fixed
>   > (non-auto) heights and margins.
>
> Hmm, would that work? On a right page, the top right margin box (the
> one who leaves a dark mark on the edge of the paper) must be taller
> than the top page margin. So, the dark margin boxes don't really fit
> into the grid of 16 margin boxes.

Always use the same page-margin box, give it a fixed height, and vary 
its margin-top to position it:

@right-top {
   height: 2cm;
   margin-top: -2cm; /* 0, 2cm, 4cm, … */
}


-- 
Simon Sapin

Received on Monday, 25 March 2013 15:17:36 UTC