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

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

From: Anton Prowse <prowse@moonhenge.net>
Date: Tue, 15 Mar 2011 22:02:47 +0100
Message-ID: <4D7FD3F7.5050808@moonhenge.net>
To: "www-style@w3.org" <www-style@w3.org>
Hi,

I'm responding to the comments presented on 
http://wiki.csswg.org/spec/css2.1/anton-lc-2010 with regard to my major 
comments post 
[http://lists.w3.org/Archives/Public/www-style/2010Dec/0312.html].

I'm not sure I'm expected to respond to that document, since I got the 
impression that it was just a scratch pad to help the WG determine which 
problems to file as formal Issues.  (Many thanks for taking the time to 
consider the problems in detail!)  Indeed, the document's not even 
up-to-date with the resolutions on the Issues wiki.  However, a few 
misunderstandings are evident in the document which jeopardized the 
filing of three of the problems, and I think it's worth trying to clear 
those up.  I hope the WG will reconsider filing these three problems as 
formal Issues!


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


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


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


Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Tuesday, 15 March 2011 21:03:27 GMT

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