Re: Does Forced Height on Table Rows Include the Cells’ borders and border-separation?
On 30.11.2007 11:54:38 Vincent Hennebert wrote: > Hi Jeremias, > > Thanks again for your patience :-) > > Jeremias Maerki wrote: > > On 29.11.2007 18:12:35 Vincent Hennebert wrote: > >> Hi, > >> > >> Ready for yet another one? Everyone’s welcome to join the game ;-) > >> > >> If a table-row element has a forced height, must that height include > >> border-separation and the cells’ borders, or only the cells’ bpd? > > > > The property (!) b-p-d is defined to specify the extent of the > > content-rectangle which means border (and border-separation) and padding > > do not belong in here. > > So? When a block-container has block children, its content rectangle > includes the childrens’ borders, paddings and contents. A bpd explicitly > set on the block-container is to be divided among the childrens’ > borders, paddings and bpds. With bpd on a table for example, I mean the table's border and padding are not included. I don't talk about its children. > > > The row-height trait (including border, border > > sep, padding) is calculated as described in the CSS spec. I think/hope > > that's what I implemented. Your example seems to prove that. > > > >> There’s nothing about that in the XSL-FO Rec since it explicitly > >> refers to CSS (section 7.15.6, “height”). In CSS2 section 17.5.3, > >> “Table height algorithms" says that “the height [of the table] is the > >> sum of the row heights plus any cell spacing or borders”. Which seems > >> to imply that the row height should not include the cells’ borders > >> and border-separation (third case). > > > > Exactly. > > > >> The following paragraph about computing the row height talks about the > >> cell’s height but not their borders; however this is contradictory to me > >> since that would lead to situations like on the attached picture if the > >> cells’ borders don’t have the same widths. And I don’t dare to follow > >> the “line box” hyperlink which leads to obscure text about replaced and > >> non-replaced inline and block-level elements. > > > > Ignore the "line box" hyperlink because that's only useful for > > vertical-align handling which we currently don't fully support. > > > > It's also important to note again the necessary distinction between > > "block-progression-dimension, the property" and > > "block-progression-dimension, the trait"! > > What’s the difference? Section 7.15.3: “This property specifies the > block-progression-dimension of the content-rectangle for each area > generated by this formatting object.” > A table-row doesn’t generate any area, anyway... No, but the value is used in the formulas to calculate the BPDs of the area generated by the table-cells or for backgrounds. > > > The table's content rectangle > > is basically the table grid which includes cell borders and most of the > > border-separations but not the table's border(-sep) and padding. > > Sorry, don’t follow you, why are you talking about the table here? After re-reading, me neither. > > I guess that's also the reason for the XSL spec to mention > > a "row-height" trait (but it doesn't really define it). > > > >> There’s a small hint in the XSL-FO Rec which says that the space > >> corresponding to border-separation should be filled with the table’s > >> background color, which would indicate that the row should actually not > >> contain the border-separation. > > > > Based on the description in the spec I consider half border-separation > > to be part of the border. > > Good point, but which adds to the confusion IMO. See below. > > > >> The behaviour of XSL Formatter looks the most reasonable one; that is, > >> include the cells’ borders in the row-height calculation. That’s already > >> what FOP’s doing when the row height is left to "auto", BTW! > > > > The key part is in the CSS spec (17.5.3): > > http://www.w3.org/TR/REC-CSS2/tables.html#height-layout > > "The height of a 'table-row' element's box is calculated once the user > > agent has all the cells in the row available: it is the maximum of the > > row's specified 'height' and the minimum height (MIN) required by the > > cells. A 'height' value of 'auto' for a 'table-row' means the computed > > row height is MIN." > > Of course but on the picture I attached in the previous mail both cells > have the same height, yet the row really can’t be like I drew it. The > relationship is IMO more complex and involves the cells’ borders, and > that’s why the second case (XSL Formatter) looks more logical to me. > > In my opinion we should play with the cells’ allocation-rectangles > (extending to the border-rectangle) instead of their content-rectangles > (like implied by CSS when mentioning the cells’ “height”). The height of > a row would then be h with > h = max(border-before + padding-before + bpd + padding-after + > border-after, > for each cell belonging to the row) > Then the height (content rectangle) of each cell would be modified so > that the
Re: Does Forced Height on Table Rows Include the Cells’ borders and border-separation?
On 29.11.2007 18:12:35 Vincent Hennebert wrote: > Hi, > > Ready for yet another one? Everyone’s welcome to join the game ;-) > > If a table-row element has a forced height, must that height include > border-separation and the cells’ borders, or only the cells’ bpd? The property (!) b-p-d is defined to specify the extent of the content-rectangle which means border (and border-separation) and padding do not belong in here. The row-height trait (including border, border sep, padding) is calculated as described in the CSS spec. I think/hope that's what I implemented. Your example seems to prove that. > See the attached pdf. On the left you have a table with one cell, and: > - border-separation = 6pt > - border-width of the cell = 2pt > - block-progression-dimension on table-row = 25pt > On the right you have a block-container with different forced heights to > use as a comparison. > > First case: the row’s height should include border-separation and cell > border; thus we have: > table bpd = row bpd = 25pt > cell bpd = row bpd - border-separation (half before, half after) - > border-before - border-after > = 25 - 6 - 2 - 2 > = 15pt > > Second case: the row’s height should include the cells’ borders but not > border-separation; thus: > table bpd = border-separation/2 + row bpd + border-separation/2 > = 3 + 25 + 3 > = 31pt > cell bpd = row bpd - border-before - border-after > = 25 - 2 - 2 > = 21pt > > Third case: the row’s height should include neither the cells’ borders > nor the border-separation; thus: > table bpd = border-separation/2 + max(cells’ border-before) + row bpd + > max(cells’ border-after) + border-separation/2 > = 3 + 2 + 25 + 2 + 3 > = 35pt > cell bpd = row bpd > = 25pt > > Now guess what? Xep applies the first case (apart from the fact that it > also forgets the half of border-separation belonging to the table’s > border). XSL Formatter applies the second case. And FOP (if we assume > the currently missing half of border-separation has been fixed) applies > the third case! > > There’s nothing about that in the XSL-FO Rec since it explicitly refers > to CSS (section 7.15.6, “height”). In CSS2 section 17.5.3, “Table height > algorithms" says that “the height [of the table] is the sum of the row > heights plus any cell spacing or borders”. Which seems to imply that the > row height should not include the cells’ borders and border-separation > (third case). Exactly. > The following paragraph about computing the row height talks about the > cell’s height but not their borders; however this is contradictory to me > since that would lead to situations like on the attached picture if the > cells’ borders don’t have the same widths. And I don’t dare to follow > the “line box” hyperlink which leads to obscure text about replaced and > non-replaced inline and block-level elements. Ignore the "line box" hyperlink because that's only useful for vertical-align handling which we currently don't fully support. It's also important to note again the necessary distinction between "block-progression-dimension, the property" and "block-progression-dimension, the trait"! The table's content rectangle is basically the table grid which includes cell borders and most of the border-separations but not the table's border(-sep) and padding. I guess that's also the reason for the XSL spec to mention a "row-height" trait (but it doesn't really define it). > There’s a small hint in the XSL-FO Rec which says that the space > corresponding to border-separation should be filled with the table’s > background color, which would indicate that the row should actually not > contain the border-separation. Based on the description in the spec I consider half border-separation to be part of the border. > The behaviour of XSL Formatter looks the most reasonable one; that is, > include the cells’ borders in the row-height calculation. That’s already > what FOP’s doing when the row height is left to "auto", BTW! The key part is in the CSS spec (17.5.3): http://www.w3.org/TR/REC-CSS2/tables.html#height-layout "The height of a 'table-row' element's box is calculated once the user agent has all the cells in the row available: it is the maximum of the row's specified 'height' and the minimum height (MIN) required by the cells. A 'height' value of 'auto' for a 'table-row' means the computed row height is MIN." The problem again is probably the reference from XSL to CSS. And CSS is sometimes not precise enough. It refers to a "box". What exactly is the "box"? I'm looking forward to XSL 1.2/2.0 where references to CSS are hopefully removed. The alternative is only the refinement of the CSS spec. > Anybody wants to add anything before I send a request for clarification > on [EMAIL PROTECTED] Definitely worth clarifying based on your results comparing the th
