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

Re: Issue 158 proposed text

From: Bruno Fassino <fassino@gmail.com>
Date: Mon, 28 Jun 2010 20:01:05 +0200
Message-ID: <AANLkTika4LrrkcxZRq8racDAmmCnGbTcvswdqHm4apnO@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>
On Mon, Jun 28, 2010 at 6:50 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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?

It is not explicitly stated what margins are considered during this
collapsing to determine the hypothetical position.
It is said "preceding margins", but I don't think this is precise enough.

Consider something like this:

<div style="background: lime; border-top: 1px solid">
	<div style="float: left; background: blue; height: 50px; width: 100px"></div>
	<div style="clear: left">
		<div style="margin-top: 60px"></div>
<div style="background: yellow">next</div>

(you can see it at http://brunildo.org/test/margin-collapse-clear-child-7.html)

Should the top margin of the child of the div with clear, after the
float, be considered in the computation of the hypothetical position?
It collapses with the (null) top margin of the clear, but does not
seem to be a "preceding" margin.

However I doubt the intention is to really exclude it. At least
Firefox and Safari seem to behave as if it was considered in the
hypothetical position, and so as if no clearance was necessary here.

>>> 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).

That's OK!  Since you said "the float comes between the two boxes" I
didn't know there was a "parent" wrapping the float and the second
box. Assuming a markup without that parent I couldn't understand your
example, sorry.

> ~TJ


Bruno Fassino http://www.brunildo.org/test
Received on Monday, 28 June 2010 18:01:36 UTC

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