Re: [CSS21] Disposition of Comments (Issue 225, 229 etc)

On 07/04/2011 19:38, fantasai wrote:
> On 04/07/2011 12:18 AM, Anton Prowse wrote:
>>>
>>> | If the element has children, its height is the distance from its
>>> top content
>>> | edge to the first applicable of the following:
>>> | * the bottom edge of the last line box, if the box establishes a
>>> inline
>>> | formatting context with one or more lines
>>> | * the bottom edge of the bottom collapsed margin of its last child,
>>> | if the child's bottom margin does not collapse with the element's
>>> | bottom margin
>>> | * the bottom border edge of its last child, if the child's bottom
>>> | margin collapses with the element's bottom (but not with its top)
>>> | margin
>>> | * zero, otherwise
>>>
>>> Would this solve the issues?
>>
>> Sorry, that's not going to work either. The text must take into account
>> that the last child might be self-collapsing and collapse with the
>> element's
>> bottom margin, in which case it's the last /non/-self-collapsing child
>> which
>> is going to dictate the element's height. I believe that my proposal
>> in [1]
>> is technically correct.
>>
>> [1] http://lists.w3.org/Archives/Public/www-style/2011Feb/0492.html
>
> Yeah, but I've read your proposal at least 5 times now, and I still
> can't really make sense of it. So I don't really want to put it in
> the spec, even if I trust it's correct. :)

heh, OK :-)

> Now that I understand what the problematic situation is, let me try
> again.
>
> | If the element has children, its height is the distance from its top
> content
> | edge to the first applicable of the following:
> | * the bottom edge of the last line box, if the box establishes a inline
> | formatting context with one or more lines
> | * the bottom edge of the bottom collapsed margin of its last child,
> | if the child's bottom margin does not collapse with the element's
> | bottom margin
> | * the top edge of its bottom collapsed margin, if the last child's
> | bottom margin collapses with the element's bottom (but not with
> | its top) margin
> | * zero, otherwise
>
> Does this work?

It covers all the cases, certainly.  (Although you mean last /in-flow/ 
child.)  But I'm not too happy about talking about the top edge of the 
collapsed margin, because 8.3.1 actually fails to explain where a 
collapsed margin sits in relation to the border edge positions of the 
elements involved.  Quibbly, I know, but nothing in 8.3.1 says that a 
collapsed margin between an element and its last in-flow child doesn't 
sit /between/ the last child's bottom border edge and the element's 
bottom border edge, for example.  Rather, we're relying on this 10.6.3 
text to tell us that that's not the case.  Hence 10.6.3 shouldn't define 
height in terms of the the top edge of a collapsed margin.

How about:

   | If the element has children, its height is the distance from its
   | top content edge to the first applicable of the following:
   |   * the bottom edge of the last line box, if the box establishes a
   |     inline formatting context with one or more lines
   |   * the bottom edge of the bottom (possibly collapsed) margin of
   |     its last in-flow child, if the child's bottom margin does not
   |     collapse with the element's bottom margin
   |   * the bottom border edge of the lattermost in-flow child whose top
   |     and bottom margins do not collapse
   |   * zero, otherwise

[CSS3 might introduce some kind of in-flow block-level element whose 
bottom margin doesn't collapse with its subsequent sibling's top margin. 
  If that happens, we'll need to modify the third item (in the 
equivalent text in Basic Box Model 3) to say "bottom margin edge" 
instead of "bottom border edge" of such elements.]


>> How about:
>>
>> | But in CSS 2.1, if there is a line box, in-flow block or floated
>> | box that would constrain the position of the float through the
>> | application of rules 5 and 6 but which would not constrain it if
>> | certain in-flow vertical negative margins within the block
>> | formatting context were set to zero, then position of the float is
>> | undefined.
>
> I think at this point we'd have to defer such a change to errata.

That's disappointing, but so be it.

>> I can't accept the wording in the current pre-PR Editor's Draft, since
>> it doesn't match the proposal in the Issues Wiki and
>> hence doesn't even fully encompass the problematic cases.
>> Specifically, the Wiki proposal is "... were all such negative
>> margins were set to zero", whereas the ED is "... were the negative
>> margin set to zero". The cumulative effect hinted at by
>> the Wiki proposal is important:
>
> Ugh, good catch. Yes, we absolutely need to fix that. I'll tell
> Bert to regenerate the draft...

OK great.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Thursday, 7 April 2011 19:51:18 UTC