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

Also sprach Simon Sapin:

 > > 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/ )

It's complex. But all UAs have implemented it. And I believe we can
refer to it without defining it.

 > 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.

It seems to be only one extra constraint: that the width of 'top-left'
and 'top-right' remain the same. To me, this seems like a simpler way
to describe margin boxes.

 > 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

Perhaps. But I can read and understand one description and not the
other. (Unless I really take time off from email and such :)

 > > 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.

We can remove the corner left/right margin boxes from the "table" --
their dimensions are given. This leaves three cells in the "table".

I tried describing layout with:

 <table>
   <col width=1*><col width=*><col width=1*>
   <tr><td id=top-left-corner><td id=top-left><td id=top-center><td id=top-right><td id=top-right-corner></tr>
</table>

But it seems that proportional spacing isn't supported the way I
remember from the past.

We also support 'margin-*' properties for margin boxes. This is not
the case for table cells and the models therefore differ. We could
re-align the two models by removing support for 'margin-*' properties
in the margin context. Hmm.

  http://www.w3.org/TR/2013/WD-css3-page-20130314/#margin-property-list

 > >   > >   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, … */
 > }

Yes, that could work. Hacky, but still.

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Monday, 25 March 2013 18:23:05 UTC