[CSS21] Description of clearance issue that's incorrectly folded into Issue 203

As a follow-up to the discovery[1] that Issue 203 (how to determine if 
clearance is necessary) was hijacked by another issue (how to calculate 
clearance), I present here a summary of how Issue 203 should currently 
look on the Issues Wiki, and then I present an analysis of the 
"calculating clearance" issue, which needs filing separately.

Issue 203 should keep its  Summary and initial URI, Proposal, Resolution 
and Objection.  (My objection still holds; see also [1] for a specific 
test case.)

The subsequent URI, Testcases, Resolution and Status should be filed as 
a new Issue, whose summary should be "Problems with the second clearance 
calculation" or similar.  However, I dispute the resolution and the 
changes to the testcases.

Regarding this latter issue, the URI listed should be accompanied 
(preceded) by David Baron's recent post [2] to the mailing list.  The 
specific issue here concerns the need for the second clearance 
calculation.  Once clearance is determined to be necessary, margin 
collapsing is prevented and clearance is calculated to be the greater of 
(i) the amount necessary to place the clearing element flush with the 
bottom of the float, and (ii) the amount necessary to align the top 
border edge of the clearing element with its previously determined 
"hypothetical" position.

The second calculation was introduced in the 2007 CR.  I can find no 
public discussion of that idea on the mailing list or elsewhere prior to 
the release of that spec.  However, later requests for clarification on 
the mailing list resulted in the reason for introducing the second 
calculation becoming clear: as described in [3], it addresses the case 
where the float moves upwards after interrupting margin collapsing.  It 
would be strange to move the clearing element upwards to make it flush 
with the bottom of the float since, prior to clearing, it was as low 
down as it was for good reason: sensible margin collapsing with 
surrounding in-flow elements.  The purpose of the second calculation is 
to ensure that the clearing element cannot move upwards.

The problem that's been found is that the spec accidentally failed to do 
what it set out to do.  It introduced the second calculation, but no-one 
noticed the final clause of a previous sentence in the spec:

   # 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 sentence was first introduced in the 15 September 2003 WD when the 
clearance concept was changed from an increase in margin-top to an 
introduction of spacing, and has remained in the spec ever since.)

Talk about hidden in plain view!  I must have read that sentence a 
hundred times and, although I found that clause curious in passing, it 
never occurred to me that it should influence the second calculation. 
Indeed, in past posts I've explicitly referred to the hypothetical 
position as being calculated with respect to the canvas or to the 
containing block formatting context (since I assumed that that was what 
was intended) without realizing that I was contradicting the current spec.

The clause "within its parent block" does cause the introduction of the 
second calculation to fail, since the float only moves upwards if the 
clearing element's parent block moves upwards, and so the second 
calculation is /always/ redundant as things currently stand.

[Note that I don't think that any meaning was ever really attached to 
that clause anyway; I'm pretty sure it was added in 2003 simply because 
there was (and, strangely, still seems to be) a reluctance to accept 
that 8.3.1 defines the top border position of an element even when the 
element is empty and self-collapsing.  That clause was probably a mere 
"reassurance", which has now landed us in trouble.]

The obvious solution is to remove that clause.  However, the Resolution 
currently given is to replace it with something along the lines of 
"within its parent block or with its containing block formatting 
context".  I agree that the latter part of the sentence makes the second 
calculation work as intended, but I am less clear as to why we need to 
give UAs the freedom to use the original erroneous clause which results 
in the second calculation being redundant.

The motivation for allowing UAs to ignore the second calculation seems 
to be given in [4]: the major browsers currently ignore it, and it is 
claimed that there is some problem with regard to the Acid2 test.  (I 
responded to that post in [5].)

Concerning the fact that major browsers ignore the second calculation, 
it seems that a couple of the important PDF renderers /don't/ ignore it, 
so we can't argue that it is logically incompatible or unimplementable. 
  Instead, the argument for ignoring it seems to be that switching to 
honouring it causes browsers to fail Acid2 and hence would require Acid2 
to be changed.  I believe this conclusion to be flawed.  Firstly, I 
assume that the PDF renderers do pass Acid2.  (It wasn't stated anywhere 
that they don't.)  Secondly, Acid2 doesn't invoke the second 
calculation, as can be seen from my analysis of that test in [5]; 
specifically, the situation in which the position of the float is 
dependent on the margin collapsing of the clearing element with the 
float's parent doesn't arise, since the previous sibling of the "nose" 
float is the "forehead" block which has a non-zero specified height.

Hence I don't believe that the second calculation has any bearing on 
whether a UA passes Acid2.

I request that the WG reopen this issue (once filed correctly!) and 
consider making it obligatory to support the second calculation and, if 
necessary, reversing any changes to the test suite.

[1] http://lists.w3.org/Archives/Public/www-style/2011Mar/0431.html
[2] http://lists.w3.org/Archives/Public/www-style/2011Mar/0427.html
[3] http://lists.w3.org/Archives/Public/www-style/2010Aug/0261.html
[4] http://lists.w3.org/Archives/Public/www-style/2010Dec/0474.html
[5] http://lists.w3.org/Archives/Public/www-style/2011Mar/0426.html

Anton Prowse

Received on Monday, 21 March 2011 08:33:44 UTC