Jeremias Maerki a écrit : > On 23.03.2007 15:44:57 Vincent Hennebert wrote: >> Guys, >> >> I've again stumbled upon uncertainties regarding the handling of >> conditional borders in the collapsing-border model, and breaks inside >> headers/footers. I'd like to have your opinions on these: >> >> >> Table headers and footers: >> Headers and footers are generated only once, and replicated on each >> page. This means that cells in headers and footers only generate one >> area, with the is-first and is-last traits set. Border- and >> padding-conditionality don't apply here. > > Conditionality still applies but because there's a header or footer
Why would conditionality apply? Every area from headers would have is-first set. > serving as fence, the cell borders and paddings don't get discarded. > Different wording, but essentially, yes. > >> Or perhaps that the border-before of the table should still be >> considered? I mean, for the first header it would come into play, and >> for following headers it also would only if conditionality=retain. >> I think I'll go that way as it more closely matches the behavior of the >> separate border-model. > > There's no table border in the collapsing border model when we're > talking about areas. All levels of borders inside a table are merged. In > the end, all you have are cell borders, nothing else. I know, the question is for the border-before of (the first row of) the header: for the very first header, border-before on table and table-columns play in the border resolution. Should they also for the headers on the following pages? > > Only in separate border model do you have separate borders on the table > and on the cells. >> Table body(-ies): >> There are several uncertainties: >> - should the border-before of the table and table-columns be considered >> or not: do we consider that those borders only apply to the very first >> (or last) row of the table? Or also to the first (last) row on each >> page? The question remains whether there are headers/footers or not. >> I would say yes. > > http://www.w3.org/TR/REC-CSS2/tables.html#table-layers answers that. The > image should help you understand. An example: take the before border of > the first cell of a table header. The elements that influence the > resolved borders are: table, column-groups if applicable, the column, > table-header, the first row in the table-header and the cell itself. All > the borders of these elements have to be combined. That's what's already > (!) implemented in CollapsingBorderModelEyeCatching (for > border-collapse="collapse") That doesn't tell anything regarding page breaks!? If the table is broken across several pages and the header shall be replicated, do border-before for table and table-column play again in border-resolution for the second and following headers? Or only for the first one? That's the same question as above actually. And that also applies to the first row from the table-body on each page, when header should be omitted at page breaks. >> - when we break /within/ a cell, should the following row come into play >> for computing the border-after? As the row hasn't even been reached >> yet, I'd say no. > > Right. That's the case in CollapsingBorderModelEyeCatching when > currentCell is not null, and otherCell is null. Fine. >> - when we break at a grid line, should the two rows meeting a the line >> count in border resolution? Or only the row before for the >> border-after at the end of the page, and the row after for the >> border-before at the beginning of the following page? >> I would go with that latter. > > That's right. Fine (that means that the border may potentially be different at the bottom of the previous page and at the top of the next page). Do we agree that those two latter cases are not described by the spec? >> - when we break at a grid line, should the entire border appear on each >> page, or the higher half at the bottom of the first page, and the >> lower half at the top of the following page? >> I would also go with that latter. > > No, the entire border has to be painted. This is > BorderProps.COLLAPSE_OUTER/COLLAPSE_INNER as used by the renderers. See > the BorderProps class. So the grid line at the page break would have two borders, one at the bottom of the page, one at the top of the next page? That's fine for me, but again I think it's specified nowhere. >> Tables and breaks: >> - do breaks on headers and footers make sense? Obviously not, excepted >> perhaps a break-before on the header's first row, or a break-after on >> the footer's last row. But as the same effect can be achieved by >> putting the breaks on the fo:table object, I think breaks on >> headers/footers should be entirely discarded. > > Yes, breaks in headers and footers make no sense and should be ignored. Great. > >> Opinions? >> Thanks, >> Vincent > > Jeremias Maerki Thanks, Vincent
