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

On 03/21/2011 01:32 AM, Anton Prowse wrote:
> 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.
> without realizing that I was contradicting the current spec.

Issue split, as 203 and 285.
   http://wiki.csswg.org/spec/css2.1#issue-203
   http://wiki.csswg.org/spec/css2.1#issue-285

> 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.
>
> 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.

The argument isn't about Acid2 specifically -- we could just ask Hixie to
fix Acid2 if that were the only problem. The problem is that, because we
have interop across all web browsers, there may be a signficant web
compatibility issue with changing their behavior. The WG resolved to allow
both behaviors not because of Acid2, nor because we lacked implementations,
nor because we disagree that removing (or changing) that clause would give
more sensible results, but because we do not have enough time to evaluate
web compat and make an appropriate decision.

(Evaluating web compat would mean Mozilla and/or IE taking the patches they
have pending to fix this, and seeing whether stuff breaks. It's not something
to try very late in a release cycle, so we have to wait until the IE10/FF5
release cycles begin and there has been some time to evaluate the impact of
such changes.)

~fantasai

Received on Tuesday, 22 March 2011 19:20:12 UTC