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

Re: Issue 158 proposed text

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 28 Jun 2010 09:50:34 -0700
Message-ID: <AANLkTinMPTqP1X4Ef35XFUrpnTclKEfwXNfZifLaCRlr@mail.gmail.com>
To: Bruno Fassino <fassino@gmail.com>
Cc: www-style list <www-style@w3.org>
On Sun, Jun 27, 2010 at 12:50 AM, Bruno Fassino <fassino@gmail.com> wrote:
> On Wed, Jun 23, 2010 at 7:57 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> Another attempt at resolving http://wiki.csswg.org/spec/css2.1#issue-158 .
>>
>> For recap, the current relevant section of 9.5.2 reads as follows:
> [...]
>>
>> I propose replacing this section with the following text:
>> """
>> 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 with all appropriate preceding
>> margins, per normal margin-collapsing rules.
>>
>> 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.)
>> """
>>
>> This addresses the test-case that fantasai was worried about*, and
>> additionally clarifies several terms so that the definition is
>> hopefully fully unambiguous now.  The additional informative note also
>> makes it clear why the second clause is needed, when a naive reading
>> would suggest that the second clause is unnecessary due to the
>> hypothetical position already being established as being *less than*
>> the float's bottom edge.
>
>
> While this rewriting clarifies things, the "hypothetical position"
> still relies on "preceding margins", which is I don't think is well
> defined. In particular it is not clear if an adjacent top margin of
> the first inflow child of the element has to be considered or not (see
> http://lists.w3.org/Archives/Public/www-style/2010Jan/0509.html).

I added language to make it clear I'm explicitly defering to the
normal margin-collapse rules.  This isn't meant to be a special case;
it should lay out the element *exactly* like it wasn't clearing at
all.

Is that sufficient?


>> In particular, here follows an ascii illustration of the test case she
>> was worried about.  The top box has no margin, while the bottom box
>> has a large top margin.  The small box is a float that comes between
>> the other two boxes.
>>
>> Without clearing, the boxes look like this:
>>
>> ┏━━━━━━━━┓
>> ┃        ┃
>> ┗━━━━━━━━┛
>>          ┬
>>          │ (approx 4em)
>>          │
>>          │
>> ┏━━━━━━━━┓
>> ┃┏┓      ┃
>> ┃┗┛      ┃
>> ┗━━━━━━━━┛
>>
>> With a clear:left set on the bottom box, it *should* look like this:
>>
>> ┏━━━━━━━━┓
>> ┃        ┃
>> ┗━━━━━━━━┛
>> ┏┓       ┬
>> ┗┛       │ (approx 4em)
>>          │
>>          │
>> ┏━━━━━━━━┓
>> ┃        ┃
>> ┃        ┃
>> ┗━━━━━━━━┛
>>
>> Note that the the bottom box maintains its 4em separation from the top
>> box.  Only the float moves, as the bottom box's top margin no longer
>> collapse with the top box's (0px) bottom margin, so there's no longer
>> anything pushing the float downwards.  The second clause then prevents
>> the bottom box from gobbling up its own margin in an attempt to line
>> up flush with the bottom of the float.
>
>
> I'm probably misunderstanding something in this example, but:
> If the float comes _between_ the two boxes then it is already in the
> upper position (just below the first box) even in the first case with
> margin collapsing, isn't it?

Not quite (though I did misstate the reasoning here).  Recall that the
code in question is this:

<div margin-bottom:0></div>
<div>
  <div float:left></div>
  <div clear:left; margin-top:4em;></div>
</div>

The floating div is ignored for margin-collapse purposes, so the
bottom box collapses its margin-top with that of its parent (and the
bottom margin of the top box, but that's irrelevant here, which I
misstated).  Since the float's parent now "owns" the margin, it's
pushed down.  When the bottom box clears itself, though, it stops
collapsing its margin into its parent, so the float can move back up
to be flush it's parent's top edge (and the top box's bottom edge).

~TJ
Received on Monday, 28 June 2010 16:51:28 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:28 GMT