- From: Simon Sapin <simon.sapin@exyr.org>
- Date: Mon, 25 Mar 2013 16:17:09 +0100
- To: Håkon Wium Lie <howcome@opera.com>
- CC: www-style@w3.org
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