- From: Anton Prowse <prowse@moonhenge.net>
- Date: Thu, 17 Mar 2011 01:33:13 +0100
- 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 http://lists.w3.org/Archives/Public/www-style/2011Mar/0374.html) >> (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. Exactly! Cheers, Anton Prowse http://dev.moonhenge.net
Received on Thursday, 17 March 2011 00:33:43 UTC