W3C home > Mailing lists > Public > www-style@w3.org > March 2011

Re: [CSS21] Response to wiki comments on my major comments post

From: L. David Baron <dbaron@dbaron.org>
Date: Tue, 15 Mar 2011 15:13:57 -0700
To: Anton Prowse <prowse@moonhenge.net>
Cc: "www-style@w3.org" <www-style@w3.org>
Message-ID: <20110315221357.GA14930@pickering.dbaron.org>
On Tuesday 2011-03-15 22:02 +0100, Anton Prowse wrote:
> (MC1)-----------------------------------------------------------
> wiki:"If the top and bottom margins of an element with clearance are
> adjoining, they always collapse, so the change is not necessary."
> Yes, but the margins can also collapse when they are *not*
> adjoining, since adjoiningness is intransitive but collapsing isn't,
> so the change is necessary else a case is missed.
> wiki:"The suggestion to add “all of its in-flow children's margins
> (if any) collapse.” seem redundant with the existing statement that
> “A collapsed margin is considered adjoining to another margin if any
> of its component margins is adjoining to that margin.”"
> I don't understand this statement, since that wasn't at all what I
> suggested.  My suggestion concerned a rather more complex issue.
> I'd appreciate a re-review of this issue!

Is this the same as Issue 211, i.e.,
http://lists.w3.org/Archives/Public/www-style/2010Sep/0451.html ?
While I'd like to fix this issue, my argument for fixing it was
substantially weakened by the fact that fixing it doesn't agree with
any implementations.

(It's also related to issue 234.)

The testcase was:
and the proposal would have changed the specification's requirement
for the first of the three gaps mentioned in the testcase from 1em
to 2em.

(Gecko's behavior, unfortunately, needs to be ignored, since I
*think* it breaks collapsing based on whether the min-height had an
effect.  I believe we looked at a testcase earlier in the day that
showed that.  If that's incorrect, then we'd still only have one
implementation for the desired behavior.)

The raw IRC log of the discussion is in
(Unfortunately the W3C copy of the IRC log has permissions set
incorrectly, so even I can't get to it.  In theory it should be in
http://www.w3.org/2011/03/07-css-irc.html around 22:04:53 (search
for "http://wiki.csswg.org/spec/css2.1#issue-211").)

> (BOX8)------------------------------------------------------------
> wiki:"Could remove the quotes, but other than that it doesn't seem
> we need a change. (An inline-level block container /is/ an
> inline-block, so these two terms are exactly equivalent.)"
> I disagree; when the spec uses 'inline-block' (especially within
> single quotes) it is assumed to mean the principal box generated by
> an element with display:inline-block, and hence this is not a
> suitable term to use for the table wrapper box of an inline-table
> element.  (cf. the first two quoted paragraphs of this issue's
> post.)

In reality, I think anonymous boxes do have values of properties...
and they often have particular values of 'display' specified.  Not
that the spec specifies the box tree at all, but I think it is
reasonable the way it is if the spec did specify the box tree.

> (FL3)
> wiki:"I don't understand this issue. Isn't the available space
> negative (i.e. not enough to fit any content) in the case given?"
> This issue is less complex now that Issue 280 has been filed and
> resolved, which makes the particular case illustrated in this
> issue's post invalid.
> This issue now boils down to the following: when there are multiple
> narrow floats inside multiple narrow containing blocks themselves
> inside some wide parent containing block, the line boxes of that
> parent need to somehow be placed around the floats.  A horizontal
> line drawn between the parent's sides quite possibly passes through
> several positive-width spaces before, after and between the floats,
> and hence it needs to be clarified that at most /one/ of those
> spaces is occupied by a shortened line box (ie the line box isn't
> fragmented), and clarified /which/ of those spaces is occupied.
> It's easy to kill both of these birds with one stone, merely by
> stating that no line box can be to the left of a left float, nor to
> the right of a right float.  That information is currently missing
> from the spec, which says where content _can_ go but omits to say
> where content _can't_ go.  As my test cases showed, there is
> currently no interop on this issue.

So you're saying we should change, in 9.5:
  # However, line boxes created next to the float are shortened to
  # make room for the margin box of the float.
  # However, line boxes created next to the float are shortened to
  # make room for the margin box of the float:  the left edge of a
  # line box must not be to the left of right margin edge of any
  # left float next to it and in the same block formatting context,
  # and likewise for the right edge and right floats.

Such a change makes sense to me.


L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Received on Tuesday, 15 March 2011 22:14:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:44 UTC