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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 5 Aug 2010 20:26:36 -0700
Message-ID: <AANLkTi=vjYOGiLh5hsqZebryak2Raq6uAYmaiA86J930@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: www-style list <www-style@w3.org>
On Thu, Aug 5, 2010 at 8:17 PM, L. David Baron <dbaron@dbaron.org> wrote:
> On Thursday 2010-08-05 18:28 -0700, Tab Atkins Jr. wrote:
>> On Thu, Aug 5, 2010 at 2:22 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> > Change 3
>> > --------
>> >
>> > In section 9.5.2, at the end of the paragraph starting "Computing the
>> > clearance of an element...", delete from "previous adjacent margins"
>> > to the end of the sentence.  Replace it with "adjoining margins,
>> > according to the margin-collapsing rules in 8.3.1".
>>
>> I thought that this change would make the text sync up with
>> implementations.  It does, but only partially.
>
> This proposed change also means that whether an element has
> clearance could depend not only on whether earlier elements have
> clearance, but also on whether *later* elements have clearance,
> since which later margins are adjoining depends on which later
> elements have clearance.

Yeah, I had a similar thought floating through my head on the ride
home.  I'll see if I can produce a test-case that would demonstrate
the issue tomorrow.


> It seems likely that this could introduce cases that are ambiguous
> or impossible to satisfy, though I haven't yet demonstrated this.
>
> On the other hand, if you consider later margins but presume that
> later elements won't have clearance, you could end up in cases where
> 'clear' fails to cause an element to clear because it presumes that
> a margin will participate in the collapse, but in the end it
> actually doesn't.
>
> And if you consider later margins and presume that all later
> elements will have clearance, then you end up back where we started,
> except for the empty element case (which is probably less important
> than the case of an element with clear whose first child is a block
> with a margin).

The empty element case is the one that's causing all the trouble.
Damn early HTML spec writers.

I want to ensure that we don't change the behavior of the non-empty
element case, since that's the part that actually makes sense.


>> Quite a lot in this section is totally arbitrary in the first place,
>> so neither option makes more sense than the other.  Thus, I suggest
>> going with my change, as it's the option that IE and Webkit have
>> taken.
>
> Which parts do you think are totally arbitrary?

I'm just going to circle my hands over that part of the spec and say
"Sorta this spot".


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

That was my assumption, yes.


> I've now spent almost an hour and a half trying to understand this
> change, and largely failed.

You and me both, brother.

~TJ
Received on Friday, 6 August 2010 03:27:29 GMT

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