Jeremias Maerki wrote:
> On 30.11.2007 11:54:38 Vincent Hennebert wrote:
>> Jeremias Maerki wrote:
>>> On 29.11.2007 18:12:35 Vincent Hennebert wrote:
>>>> 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.

Yeah, but with bpd on table-row? I took block-container as an analogy:
    block-container <-> table-row
    children blocks <-> children table-cells
bpd set on the block-container is to be divided among the children 
blocks’ bpds, paddings and borders.

So, likewise IMO, bpd set on table-row would have to be divided among 
the cells’ bpd, paddings and borders.

>> 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 sum matches h. See attached picture. If the row has an explicit 
>> height we would do exactly the same, taking for h the max of the 
>> calculation above and of the explicit height.
> I thought we're already doing that.

When bpd on table-row is set to auto, yes (border-separation is also 
included). When bpd is set to an explicit value, no: each cell is forced 
to that explicit bpd, and only then the previous formula is used to 
compute the row-height trait (AFAIU from the code...).

Which implies that the row-height trait hasn’t the same value as the 
height (or bpd) property...

>> Now this doesn’t answer the question whether the border-separation 
>> should be included or not. This is not important when the row height is 
>> left to auto, but it is when it is set to an explicit value.
> Of course, border-separation needs to be included for calculating the
> row-height trait but it's not important in the actual "row height" (note
> the missing dash) calculation, because the border-separation is simply
> added at the very end to get row-height. In other words, as long as
> you're working with the height properties you can leave
> border-separation aside. So your row-height_2.png is ok but it ignores
> border-separation. If border-separation is included, there should be a
> "row-height" measurement which includes half border separation twice.

... which you seem to confirm with that statement. I’m uncomfortable 
with this but it’s a sensible point of vue.

>> The fact that the border-separation should be filled with the table’s 
>> background leads to answer no, but the fact that half the 
>> border-separation is part of each cell border, like you mention above, 
>> would lead to a yes.
> The way border-separation is handled painting-wise doesn't say anything
> about how it is to be used in calculations, does it?

Well it gives a hint. In the end the row-height trait is used to paint 
the row’s background, so the calculation method will be visible through 
that. Once again that’s not an issue if the row’s height is left to 
auto, but it is if it is set to an explicit value.

> The spec saying
> that it's part of a border does on the other side.

It does with a bit more strength ;-)

>>> Test suite! Test suite! Test suite!!! :-)
>> Pictures! Pictures! Pictures!
> Yes, but we should have a more complete pictures. Yours help but they
> are still incomplete or only show part of the problem IMO. I think it
> would be easiest to spark a discussion on xsl-editors by providing a
> simple but comprehensive example which can be used to show how different
> the various implementations do the calculations. Otherwise, we're
> wasting a lot of time here with speculation.

Yes, I think it’s time to move to [EMAIL PROTECTED] Although this discussion 
was certainly useful, to be sure I wasn’t missing anything obvious, and 
to help me phrase my question correctly. Obviously I was myself not 
precise enough.


Reply via email to