- From: Anton Prowse <prowse@moonhenge.net>
- Date: Sun, 15 Aug 2010 10:16:33 +0200
- To: www-style list <www-style@w3.org>
- CC: "Tab Atkins Jr." <jackalmage@gmail.com>, Bruno Fassino <fassino@gmail.com>
We know by know, from various recent threads concerning clearance and margin collapsing, that 9.5.1 is /trying/ to say the following: # 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. <del>This position is # determined after the top margin of the element has been collapsed # with previous adjacent margins (including the top margin of the # parent block).</del> <ins>This position is the same as the where # the actual top border edge would have been if the # element had a non-zero top border.</ins> # # If this hypothetical position of the element's top border edge is # not past the relevant floats, then clearance <ins>is introduced # and</ins> must be set to the greater of: # # 1. The amount necessary to place the border edge of the block even # with the bottom outer edge of the lowest float that is to be # cleared. # 2. The amount necessary to make the sum of the following equal to # the distance to which <del>these margins</del> <ins>the top # margin of the element and previous adjacent margins</ins> # collapsed when the hypothetical position was calculated: # * the margins collapsing above the clearance # * the clearance itself # * if the block's own margins collapse together: the block's # top margin # * if the block's own margins do not collapse together: the # margins collapsing below the clearance Firstly, we note the insertion of "clearance is introduced" in the second paragraph; this is as a result of the resolution of Issue 115 (the clearance paradox)[1]. It's important, because it indicates that margin collapsing is interrupted. The calculations which follow are then based on the fact that this interrupt exists (and that, as a result, the clearing element may have moved down and the float may have moved up). The purpose of the calculations is to then adjust the resulting position of the clearing element, moving it to the desired place. Secondly, we note the "hypothetical top border edge position" described in the first paragraph is merely the position of a hypothetical non-zero top border. It's hypothetical in the sense that the clearing element may not actually have a non-zero top border; it's the position where such a border would be if it had one. Of course, if it really does have one, then the hypothetical edge is the real edge, and the position of the two is the same. Thirdly, we can define "hypothetical top border edge position" to *always* mean this, not just at the point in time when it is calculated in the first paragraph. Indeed, it's my belief that this is the border edge being talked about in Calculation 1. It's also what's implicitly being talked about in calculation 2. Fourthly, it's been established that the term "these margins" in Calculation 2 refers to the margins being discussed in the paragraph above. That is, it refers to the top margin of the clearing element and previous adjacent margins. Accordingly, Calculation 2 finally becomes clear: it's saying that clearance2 is the amount necessary, once clearance is known to be required and hence margin collapsing has been prevented between boxes prior to the clearing element and subsequent margins, to return the hypothetical top border edge to its original position before margin collapsing was interrupted. In other words, clearance2 is what stops the clearing element from moving upwards from its original position. It's necessary because of the following situation: <div>text</div> <div> <div style="float:left; width:100px; height:100px"></div> <div style="clear:left; margin-top:50px">text</div> </div> Interrupting the margin collapsing means that the float moves upwards. Clearance1 would place the clearing element flush with the bottom of the float; it would move it upwards. This is typographically unpleasing. After all, prior to clearing, it was as low down as it was for good reason: sensible margin collapsing with surrounding in-flow elements. How do we know that this really what Calculation 2 is saying? Well, the equation is saying: height of collapsed margin lump resulting from the top margin of the clearing element and previous adjacent margins = height of margin lump above the clearance + clearance + the clearing element's top margin (if element is self- collapsing) or the height of the margin lump resulting from collapsing below the clearance (otherwise) = height of margin lump of previous adjacent margins + clearance + distance from the clearance to the clearing element's hypothetical top border edge Which is to say (rephrasing the left-hand side): distance above the clearing element's hypothetical top border edge to the top of the collapsed margin lump (prior to introducing clearance) = height of margin lump of previous adjacent margins (after introducing clearance, which separates these margins from subsequent margins) + clearance + distance from the clearance to the clearing element's hypothetical top border edge The three terms on the right describe the spacings we end up with after introducing clearance, namely the margin lump above the clearance, the clearance itself, and the distance from the clearance to the (new position of the) hypothetical top border edge. The term on the left is the distance from the top of the original margin lump (before clearance was determined as being necessary) to the hypothetical position. In other words, clearance-2 is precisely the amount needed to return the hypothetical border edge, after margin collapsing has been interrupted, to the position it originally occupied. So that is what the spec is /trying/ to say, with the clearance paradox and Issue 158 solved. However, it now becomes clear that what it's trying to say is nonsense. Given that we're talking about the hypothetical top border edge in Calculation 2, it's reasonably safe to assume that it's talking about the hypothetical top border edge in Calculation 1. So the whole thing is talking about hypothetical top border edge. But what /is/ this hypothetical top border edge? We're not interested in some hypothetical edge! We're interested in the *actual* edge, right? Well, the hypothetical edge /is/ the actual edge, in the case that an actual non-zero edge exists (either its own edge, or if not, that of its first in-flow child that has an edge, etc, according to 8.3.1). But in the case that there's no "natural" edge – which is to say, in the case that the clearing element is self-collapsing – the actual edge position is that determined in 8.3.1.6...... _which used to be the position of a hypothetical non-zero top border edge, in other words the hypothetical top border edge_. So my lingering suspicion[2] that there was a relationship between the hypothetical edge and the actual edge was well-founded: under the old convention of how to position self-collapsing elements, our "hypothetical top border edge" wasn't hypothetical at all; it was the actual, real top border edge position as determined by 8.3.1. But then in 2007, the convention was changed.[3] Suddenly, the actual position of a self-collapsing element was determined using the position of a hypothetical /bottom/ border edge in 8.3.1.6.2 (which results in a different top border position in some cases). But no-one noticed that the clearance rules also needed changing to match, no doubt because it wasn't obvious that they relied on the rules in 8.3.1.6.2.... because yet again, one part of the spec (9.5.2) tried to re-express some complicated other part of the spec (8.3.1) in its own words instead of deferring to that part, and got it wrong. Had 9.5.2 just said "top border edge" instead of "hypothetical top border edge as calculated by assuming blah, blah and blah", we wouldn't have had this problem. (It now comes as no surprise that using a "hypothetical bottom border" in 9.5.2 during Bruno Fassino and Tab's experiments in [4] produced more pleasing results; bottom border was in fact the "right answer". Having 9.5.2 use a "border" that's not the same as the actual border is obviously going to result in a silly final position of the clearing element. The only reason that tests don't produce total nonsense when using the incorrect hypothetical border was that its position is always the same or higher than the actual border position. Hence the worst that could happen is that the clearing element is moved down too far: its "hypothetical" position flush with the bottom of the float and its actual border position perhaps lower.) So, to fix the problem, remove all reference to "hypothetical". We need to be talking about the real top border edge position in 9.5.2, as determined by the margin collapsing rules in 8.3.1. [1] http://wiki.csswg.org/spec/css2.1#issue-115 [2] http://lists.w3.org/Archives/Public/www-style/2010Aug/0090.html [3] http://lists.w3.org/Archives/Public/www-style/2007Sep/0100.html [4] http://lists.w3.org/Archives/Public/www-style/2010Jul/0025.html Cheers, Anton Prowse http://dev.moonhenge.net
Received on Sunday, 15 August 2010 08:18:39 UTC