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

Re: Issue 158 proposed text

From: Bruno Fassino <fassino@gmail.com>
Date: Sun, 4 Jul 2010 21:38:48 +0200
Message-ID: <AANLkTimf9jgHqtzp-MFwL0sK1baUGQYpSggfMK1wXFBY@mail.gmail.com>
To: Anton Prowse <prowse@moonhenge.net>
Cc: www-style list <www-style@w3.org>
On Sun, Jul 4, 2010 at 6:58 PM, Anton Prowse <prowse@moonhenge.net> wrote:
> Bruno Fassino wrote:
>>
>> On Sun, Jul 4, 2010 at 12:40 PM, Anton Prowse <prowse@moonhenge.net>
>> wrote:
>>>
>>> Tab Atkins Jr. wrote:
>>>>
>>>> On Thu, Jul 1, 2010 at 2:49 PM, Anton Prowse <prowse@moonhenge.net>
>>>> wrote:
>>>>>
>>>>> Tab Atkins Jr. wrote:
>>>>>>
>>>>>> So, then, current proposal for fixing issue 158.  As a reminder, it's
>>>>>> meant to address the issue found at
>>>>>> http://wiki.csswg.org/spec/css2.1#issue-158 and replace the text found
>>>>>> at http://www.w3.org/TR/CSS2/visuren.html#flow-control .
>>>>>>
>>>>>> | 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 all appropriate adjoining margins per normal margin-collapse
>>>>>> | rules, except that the clearing element's top margin is not allowed
>>>>>> | to collapse with the clearing element's bottom margin.
>>>>>> |
>>>>>> | If this hypothetical position of the element's top border edge is
>>>>>> | flush with or past the relevant floats, then no clearance is
>>>>>> | applied. Otherwise, the top margin of the element no longer
>>>>>> | collapses with preceding margins,
>>>>>
>>>>> Doesn't this reintroduce the "preceding margins" ambiguity that was
>>>>> potentially resolved in [1]?
>>>>
>>>> No, as I'm no longer trying to make a special distinction about it
>>>> only collapsing with certain types of margins.  It just collapses with
>>>> everything that it would normally collapse with, except for the one
>>>> exception I specify.  This exception properly excludes everything I
>>>> want to exclude - in essence, it captures the notion of "preceding"
>>>> more precisely, but without the chance of accidentally overruling
>>>> normal margin-collapse rules.
>>>>
>>> I can't tell if we're talking about the same thing!  What I meant was is
>>> that you've reintroduced the term "preceding margins" in the prose
>>> without defining what it means for a margin to be preceding.  (Eg, it's
>>> still not clear to me from the 9.5.2 prose whether the first in-flow
>>> child's top margin collapses with the clearing element's top margin once
>>> clearance has been deemed necessary via the hypothetical position
>>> calculation, although 8.3.1 very much indicates that it is: "When an
>>> element's own margins collapse, and that element has had clearance
>>> applied to it, [...]".)  If this term relates to your description of
>>> which margins collapse when calculating the hypothetical position, then
>>> it should be made explicit.
>>
>>
>> I don't think the term "preceding" here refers to the margins used for
>> the hypothetical position calculation.
>> Here it just refers to the fact that:
>> - there is something new above the element's top margin (the
>> clearance, even if possibly 0) separating it from (= making it not
>> adjacent to) margins "above" (parent top margin, preceding
>> siblings...)
>> How to express this more precisely, I don't know.
>
> Do we have to mention it at all?  I'm concerned that we're setting
> ourselves up for a fall by doing so.  The rules for margin collapsing --
> including where clearance is involved -- are clearly specified in 8.3.1
> and I don't see any benefit of trying to restate them in 9.5.2.  Let's
> just defer to 8.3.1 in the case that we've determined that clearance be
> necessary.  (The spec has something of a history of getting itself into
> trouble through unnecessarily restating complicated things in different
> places and not getting the details quite right.)


It could be a good idea. So you mean simply something like this:

| If this hypothetical position of the element's top border edge is
| flush with or past the relevant floats, then no clearance is
| applied, otherwise clearance is introduced and is set to the greater of:
| ....

With the (implicit? or better explicitly stated?) assumption that:

| In both cases (clearance applied or not applied) the real position of the
| element is then determined using the collapsing rules at 8.3.1.


> In particular, although the primary effect of clearance on an element is
> to prevent its top margin from collapsing with proceeding margins (in
> the sense that you describe), there's also that curious rule about
> preventing the bottom margin of a block from collapsing with a previous
> combined margin if such margin arose in part from an self-collapsing
> clearing element.  That doesn't get mentioned in the proposal for 9.5.2,
> a fact which is anomalous and potentially confusing.

I thought this lack was not so important, since that further rule
doesn't affect the position of the cleared element which is the
primary goal of 9.5.2. But I agree that reiterating only part of the
rules is confusing.
(I believe that rule preventing the collapse with the parent bottom
margin is necessary to make the parent to "enclose" the clearing
element even when this is self-collapsed. This enclosing effect is
desired; without it  self-collapsed clearing elements would not have
the 'expected' behavior).



>>> The current proposal also contains an ambiguity:
>>>
>>> | 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 all appropriate adjoining margins per normal margin-collapse
>>> | rules, except that the clearing element's top margin is not allowed
>>> | to collapse with the clearing element's bottom margin.
>>>
>>> You're deferring to the normal margin-collapsing rules, and yet you're
>>> constraining how they're supposed to be applied; you can only do this is
>>> you then redefine how the normal margin-collapsing rules work under this
>>> constraint.
>>>
>>> In particular, when you say that the clearing element's top margin is
>>> not allowed to collapse with its bottom margin, I assume you mean that
>>> the two margins must be regarded as non-adjacent (to use the terminology
>>> of 8.3.1, which I recommend doing).  But what if the clearing element
>>> contains an only child whose top and bottom margins collapse?  This
>>> combined child margin would ordinarily be adjacent to the clearing
>>> element's top and bottom margins and hence would combine with both.
>>> However, since you're preventing the clearing element's top and bottom
>>> margins from collapsing in your hypothetical position calculation, you
>>> need to state how the combined child margin interacts with the parent
>>> margins.
>>
>>
>> Re-reading again this part of the proposed definition of hypothetical
>> position:
>>
>> | except that the clearing element's top margin is not allowed
>> | to collapse with the clearing element's bottom margin
>>
>> I agree that probably it is still ambiguous. I mentioned in a previous
>> message using instead of that exception something like:
>>
>> | but assuming the clearing element has a non-zero bottom border
>>
>> (this locution is already used at 8.3.1 to identify the position if a
>> collapsed through element top border).
>> This formulation leaves no ambiguity: in particular margins of first
>> inflow children will be considered  (allowed to collapse with the
>> element top).
>>
>
> Until now I had only been skimming your discussion with Tab.  Now that
> I've looked back at it more carefully, I see that you did indeed already
> express doubts about such an ambiguity, and I agree that a proposal like
> the one you're making -- using normal margin collapsing rules on a
> tweaked style foundation (temporary introduction of non-zero bottom
> border), rather than trying to tweak the margin collapsing rules
> themselves -- is a suitable way of avoiding the problem.  Indeed, my
> mail should ideally have been a response to Tab's comment in [1]:
>
> 'Saying "assume the element has a non-zero bottom border", though, is
> just an indirect way of saying "don't let the element's top and bottom
> margins collapse together"'
>
> which is in fact not the case, as the ambiguity shows.
>
>
> This clearance + margin collapsing business is a real vipers nest, isn't
> it!


It really is :-)


Best,
Bruno

-- 
Bruno Fassino http://www.brunildo.org/test
Received on Sunday, 4 July 2010 19:39:17 GMT

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