W3C home > Mailing lists > Public > www-style@w3.org > August 2010

Re: [css2.1] Issue 158 and Issue 178 Resolution

From: Anton Prowse <prowse@moonhenge.net>
Date: Sat, 07 Aug 2010 11:25:02 +0200
Message-ID: <4C5D266E.5060508@moonhenge.net>
To: www-style list <www-style@w3.org>
CC: "L. David Baron" <dbaron@dbaron.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
L. David Baron wrote:
> On Friday 2010-08-06 17:40 -0700, Tab Atkins Jr. wrote:
>> On Thu, Aug 5, 2010 at 8:17 PM, L. David Baron <dbaron@dbaron.org> wrote:
>>> That said, I'm not sure that we're interpreting the spec correctly.
>>> I think we're both presuming that, where bullet point (1) below this
>>> text says "the border edge" it means "the hypothetical position of
>>> the border edge".  But I'm actually starting to think that
>>> assumption is wrong.
>> All right, I've been considering this.  I don't see anything else that
>> it could possibly mean, though.
> 
> The alternative I was considering was that it meant exactly what it
> said, "the border edge".  In other words, that it was saying that
> the hypothetical border edge calculation was used only to determine
> whether or not there is clearance, but when calculating the amount
> of clearance, the real rules (i.e., the real margin collapse) are
> used.
> 
> This does have all the same problems I described in
> http://lists.w3.org/Archives/Public/www-style/2010Aug/0085.html
> 
>> Take this test-case:
> 
> It's not clear to me how this test case differentiates between the
> two interpretations I described above (real vs. hypothetical top
> border edge of the block with clear).  (It might, though; I'm just
> not inclined to spend half an hour stepping through various lists of
> constraints in the spec.)

Indeed.  On a related note, the hurdle I pointed out in the previous
thread [1] still needs to be addressed (or at least acknowledged) before
progress can be made here, since it concerns the calculation of the
hypothetical top border edge position.  9.5.2 currently says:

   # 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 has been collapsed with previous
   # adjacent margins (including the top margin of the parent block).

which is all well and good, apart from the fact that nothing tells us
/how/ to calculate the hypothetical top border edge position, assuming
that the collapsing being permitted here is distinct from the collapsing
ordinarily permitted in 8.3.1.

In particular, when the clear has self-adjoining margins as in most of
the difficult test cases, there's no obvious candidate for top border
edge apart from what's described in 8.3.1.6 – but those rules *do not
apply* because we're not doing normal margin collapsing as per 8.3.1;
we're doing custom margin collapsing with special constraints.

If we *want* those rules to apply (and we might) then we have to (a)
verify that they make sense in the context of our custom collapsing
rules, and (b) explicitly state that they apply in that context.  The
latter could be as easy as modifying the last sentence in the quote
above as follows:

   | This position is determined using the margin collapsing rules of
   | 8.3.1 under the extra constraint that the top margin of the element
   | can only collapse with previous adjacent margins (including the top
   | margin of the parent block).

One thing that came up in the discussion of Issue 158 was the idea of
expressing the custom margin collapsing rules in terms of the temporary
introduction of a border top or border bottom.  This would have the
happy side-effect of making the rules in 8.3.1.6 irrelevant since the
clear would no longer have self adjoining margins, and hence task (a)
above could be avoided.


Whatever is agreed up here, once clearance has been deemed necessary in
a particular case, then it is "introduced" (approved by issue 115) and
the normal margin collapsing rules resume (unstated but needs stating)
taking account of the clearance, and we get back to David's issue of
what we think "border edge" means in clearance calculation 1 (see
below), and the issue of what we think the relationship is between the
custom margin collapsing rules used for determining whether clearance is
necessary and the factors involved in clearance calculation 2 (including
understanding what "these margins" refers to; Issue 158).

>>> That said, I'm not sure that we're interpreting the spec correctly.
>>> I think we're both presuming that, where bullet point (1) below this
>>> text says "the border edge" it means "the hypothetical position of
>>> the border edge".  But I'm actually starting to think that
>>> assumption is wrong.
>> All right, I've been considering this.  I don't see anything else that
>> it could possibly mean, though.

I think precisely the opposite; I don't see it could possibly mean
anything *other* than what David suggests.  After all, by the time we're
doing clearance calculation 2, we've already resumed normal margin
collapsing and the hypothetical top border edge has disappeared into the
ether, unless you can come up with some imaginative way of pinning it to
the clear somehow.  (Easier said than done, given that there's no longer
any such thing as the "margin area box" for a self collapsing clear(*);
rather, there's merely a convention in 8.3.1.6 for where its actual top
border edge is positioned within a faceless margin lump.[2])

(*) nor indeed for any box whose margins participate in collapsing; this
is the elephant in the box room for Chapter 8, but that's a story for
another day...

[1] http://lists.w3.org/Archives/Public/www-style/2010Jul/0022.html
[2] http://lists.w3.org/Archives/Public/www-style/2010Aug/0090.html

Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Saturday, 7 August 2010 09:26:49 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:30 GMT