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
Cheers
Anton Prowse
http://dev.moonhenge.net