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

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

From: Anton Prowse <prowse@moonhenge.net>
Date: Thu, 17 Mar 2011 01:33:13 +0100
Message-ID: <4D8156C9.4030502@moonhenge.net>
To: "www-style@w3.org" <www-style@w3.org>
CC: "L. David Baron" <dbaron@dbaron.org>
On 15/03/2011 23:13, L. David Baron wrote:
> On Tuesday 2011-03-15 22:02 +0100, Anton Prowse wrote:
>> (MC1)-----------------------------------------------------------

(This part of the conversation was responded to separately in 

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

OK, but that's interesting: does that mean that 'inline-table' is a kind 
of virtual value, then?  No box ever takes that display property value; 
rather, the boxes generated by an inline table take inline-block 
(wrapper box) and table (table box).

>> (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.
> into:
>    # 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.


Anton Prowse
Received on Thursday, 17 March 2011 00:33:43 UTC

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