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 16:12:34 -0700
Message-ID: <AANLkTilOW1xuniJ2uom5WWQtVWd88g2J6oe7Cdy0a1AG@mail.gmail.com>
To: Bruno Fassino <fassino@gmail.com>
Cc: www-style list <www-style@w3.org>
On Mon, Jun 28, 2010 at 2:59 PM, Bruno Fassino <fassino@gmail.com> wrote:
> The only problem is that I'm not sure that the intention is really to
> have the hypothetical position the same as the one with _all_ margins
> normally collapsed (i.e. the same as with clear: none).
> In other words, I'm not sure if the word "preceding" was initially
> there for any specific reason.
>
> Consider this:
>
> <div style="background: yellow">before</div>
> <div style="background: lime">
>        <div style="float: left; height: 50px; width: 100px; background:blue"></div>
>        <div style="clear: left; margin-bottom: 100px"></div>
> </div>
> <div style="background: yellow">next</div>
>
> (you can see it at http://brunildo.org/test/margin-collapse-clear-child-9.html)
> What behavior do we want for this test case?
> With the new formulation the top border edge of the clear should be
> 100px lower than the bottom of "before" (hypothetical position), but
> then (since with clear there is no more collapsing with the parent
> top) we should have other 100px below this position. Or something like
> that... I'm not sure, but I believe we are not going to get a
> "reasonable" rendering of this test case.

Ah, I think you're right, and fantasai also thinks the "preceding" may
have been intentional.  Rendering gets pretty odd if following margins
are collapsed "upwards" above the hypothetical position of the border
box, and then moved back below after clearing triggers.

In that case, let's return the "preceding", and specify it precisely
so that children, later siblings, and the element's own bottom margin
aren't counted:

| 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 is collapsed with all
| appropriate preceding margins (margins of the element's children and
| following siblings, as well as the element's own bottom margin, are
| never preceding for this purpose), 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.)

(For those following along at home, the changes from the current spec
are minor.  I've added clarifying language to the second sentence of
the first paragraph, clarified in the second paragraph that margins no
longer collapse if clearance must be applied, and replaced the second
bullet point entirely.)

~TJ
Received on Monday, 28 June 2010 23:13:27 GMT

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