W3C home > Mailing lists > Public > www-style@w3.org > July 2010

Re: Issue 158 proposed text

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 30 Jul 2010 15:38:46 -0700
Message-ID: <AANLkTi=HtkXWe+rrMxzCwSnOBc8qrPhTDtrQwD8HbtQK@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: Bruno Fassino <fassino@gmail.com>, www-style list <www-style@w3.org>
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.

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:48 UTC