Re: Issue 158 proposed text

On Thu, Jul 29, 2010 at 6:31 PM, L. David Baron <dbaron@dbaron.org> wrote:
> On Wednesday 2010-06-30 08:47 -0700, Tab Atkins Jr. wrote:
>> So, then, current proposal for fixing issue 158.  As a reminder, it's
>> meant to address the issue found at
>> http://wiki.csswg.org/spec/css2.1#issue-158 and replace the text found
>> at http://www.w3.org/TR/CSS2/visuren.html#flow-control .
>>
>> | Computing the clearance of an element on which 'clear' is set is
>> | done by first determining the hypothetical position of the element's
>> | top border edge within its parent block.  This position is
>> | determined after the top margin of the element has been collapsed
>> | with all appropriate adjoining margins per normal margin-collapse
>> | rules, except that the clearing element's top margin is not allowed
>> | to collapse with the clearing element's bottom margin.
>
> Saying that the top margin of an element can't collapse with its
> bottom margin is ambiguous, since there could be margins in-between
> the two, and you don't say at which point the collapsing breaks.
> The simplest such case is:
>  <div style="clear: left"><div style="margin-top: 100px"></div></div>

Right, I corrected this in a later email to say that in such a case
the child collapses with the top margin.

> The current spec says that the collapsing should be done as though
> the element has a nonzero top border width, and I think (based on
> the rationale you gave, not on the proposed spec text) you're
> proposing to change it to say that the collapsing should be done as
> though the element had a nonzero bottom border width.
>
> However, it's also not clear to me why you're proposing this change.
> I'm actually not even sure that you intended it.

I didn't intend such a change.  I can't find where that is specified,
though, in either 9.5.2 or 8.3.1.  Is it somewhere else in the spec?
If so, I think it should be moved to be in one of these sections.

> Either way, it should be more explicit at which boundary the
> collapsing is inhibited.  (And it should also be done in a way that
> doesn't contradict the current wording of the margin collapsing
> section, in which "collapses with" is a transitive relation.)

Indeed, it should.


>> | If this hypothetical position of the element's top border edge is
>> | flush with or past the relevant floats, then no clearance is
>> | applied. Otherwise, the top margin of the element no longer
>> | collapses with preceding margins, and the clearance is set to the
>> | greater of:
>> | * The amount necessary to place the top border edge of the block
>> |   even with the bottom outer edge of the lowest float that is to be
>> |   cleared.
>> | * The amount necessary to place the top border edge of the block
>> |   even with the previously computed hypothetical position of the top
>> |   border edge of the element.  (Informative Note: This is necessary
>> |   to handle the case where the float moves due to the element's top
>> |   margin no longer collapsing with previous margins.)
>
> The second bullet point here also seems like a change from the
> current spec in the case of elements whose margins collapse with
> each other and contain elements with margins, since it changes from
> not including the child margins to including them.  At first glance
> I think that change is probably a good one, but I'd be interested to
> know if it's compatible with implementations.

Based on my recent email, I don't think anything
margin-collapse-related is compatible with implementations at the
moment.  If I'm right, then issue 158 needs to wait for issue 178
before it can be resolved properly.

~TJ

Received on Friday, 30 July 2010 22:39:38 UTC