- From: Bruno Fassino <fassino@gmail.com>
- Date: Tue, 29 Jun 2010 15:37:41 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: www-style list <www-style@w3.org>
On Tue, Jun 29, 2010 at 1:12 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > 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 Well, this defines "preceding" margins, explicitly excluding margins of the element's children. So I'm back to one of my original doubts: is it "reasonable" to exclude such margins? Not much, in my opinion. In something like this: <div style="background: yellow">before</div> <div style="float: left; height: 50px; width: 100px; background:blue"></div> <div style="clear: left"> <div style="margin-top: 100px"></div> </div> <div style="background: yellow">next</div> I would prefer to say that the hypothetical position is already 100px below the first yellow box, so it stays there and no clearance is necessary (which seems to be Firefox's behavior). In other words, I would not exclude margins of children collapsing with the element's top margin (the rationale for this could be that for what concerns the position of the element's top border these margins have the same role as the element's top margin. Only the element's bottom margin and margins of following siblings have a different role and should be excluded. Of course I'm not sure this makes sense :-). Bruno -- Bruno Fassino http://www.brunildo.org/test
Received on Tuesday, 29 June 2010 13:38:11 UTC