Re: [CSS21] Disposition of Comments (Issue 225, 229 etc)

On 06/04/2011 09:03, fantasai wrote:
> On 04/03/2011 02:10 AM, Anton Prowse wrote:
>>
>>> Disposition of Comments:
>>> http://dev.w3.org/csswg/css2-src/issues-lc-2011.html
>>> Latest draft:
>>> http://www.w3.org/Style/css2-updates/draft-PR-CSS21-201103XX/
>>
>> I have comments to make about the following issues.
>>
>> Issue 225 currently marked as Invalid. The WG couldn't understand the
>> problem I was trying to illustrate, probably because my
>> illustration contained inaccuracies. I followed up in
>> http://lists.w3.org/Archives/Public/www-style/2011Mar/0345.html with an
>> accurate (I hope!) illustration of the problem. Note that this issue
>> is superseded by
>> http://lists.w3.org/Archives/Public/www-style/2011Feb/0492.html which
>> is not on the Disposition of Comments since it was
>> raised after the deadline for LCWD comments. My issue still stands,
>> however, if this later issue (which concerns a superset of
>> problems) is not addressed.
>
> OK. There's a proposal in the wiki for that, specifically to replace the
> third and fourth paragraphs of 10.6.3 ("If it only has ... bottommost
> child.").
> Here's a slighly updated version:
>
> | If the element has children, its height is the distance from its top
> content
> | edge to the first applicable of the following:
> | * the bottom edge of the last line box, if the box establishes a inline
> | formatting context with one or more lines
> | * the bottom edge of the bottom collapsed margin of its last child,
> | if the child's bottom margin does not collapse with the element's
> | bottom margin
> | * the bottom border edge of its last child, if the child's bottom
> | margin collapses with the element's bottom (but not with its top)
> | margin
> | * zero, otherwise
>
> Would this solve the issues?

Sorry, that's not going to work either.  The text must take into account 
that the last child might be self-collapsing and collapse with the 
element's bottom margin, in which case it's the last 
/non/-self-collapsing child which is going to dictate the element's 
height.  I believe that my proposal in [1] is technically correct.

[1] http://lists.w3.org/Archives/Public/www-style/2011Feb/0492.html


>> Issue 229 concerns how floats interact with other floats, line boxes
>> and in-flow block boxes that occur earlier in the source;
>> specifically the observation that the rules in the spec forbade floats
>> from appearing higher than such objects but
>> implementations routinely permit this when these objects do not share
>> the float's containing block.
>>
>> However, the Comment URL given in the Disposition should be marked as
>> "(first half)", and the Response and Status URLs are
>> wrong: they refer to a different issue raised in the second half of
>> the Comment URL (namely "left floats being to the right of
>> a right float", which is Issue 280).
>>
>> The Response to Issue 229 is actually in the Minutes and Resolutions
>> of the f2f at
>> http://lists.w3.org/Archives/Public/www-style/2011Mar/0272.html and I
>> don't think
>> it was separately raised on the mailing list.
>
> Ok, fixed.

Thanks.

>> I've followed up on the resolution given therein and on the Issues
>> Wiki in
>> http://lists.w3.org/Archives/Public/www-style/2011Mar/0650.html and
>> http://lists.w3.org/Archives/Public/www-style/2011Mar/0652.html but I
>> am prepared to mark the f2f resolution as
>> Verified-Accepted (although I'm very much interested to hear the WGs
>> response to my follow-up!).
>
> I think it's mainly a "we don't have time to figure this all out precisely"
> thing.

I don't doubt it.  The trouble is that common cases which are definitely 
not undefined in practice are being made undefined in the spec.  At the 
very least, we don't want to make undefined easy cases where the 
negative margin has no effect on the part of the document that's in the 
vicinity of the float, such as

<p style="margin-top:-10px">
	[lots of text, much more than 10px high!]
</p>
<div style="float:left; width:10px; height:10px"></div>

How about:

   | But in CSS 2.1, if there is a line box, in-flow block or floated
   | box that would constrain the position of the float through the
   | application of rules 5 and 6 but which would not constrain it if
   | certain in-flow vertical negative margins within the block
   | formatting context were set to zero, then position of the float is
   | undefined.

I can't accept the wording in the current pre-PR Editor's Draft, since 
it doesn't match the proposal in the Issues Wiki and hence doesn't even 
fully encompass the problematic cases.  Specifically, the Wiki proposal 
is "... were all such negative margins were set to zero", whereas the ED 
is "... were the negative margin set to zero".  The cumulative effect 
hinted at by the Wiki proposal is important:

<div style="height:50px; margin-bottom:-11px">
	<p style="float:left; width:50px; height:50px"></p>
</div>
<div style="margin-top:-11px">
	<p style="height:20px"></p>
	<p style="float:left; width:50px; height:50px"></p>
</div>

The second float doesn't cause us to worry about it overlapping previous 
blocks/floats when only one of the negative margins is set to zero, but 
it does when both are set to zero.

(Note that it's not yet clear to me that setting /all/ negative margins 
to zero doesn't also miss cases by going "too far the other way", so 
I've used "certain negative margins" in my proposal above.  My instinct 
is that this is a non-issue, though.)


>> Regarding other issues that I raised before the deadline for comments,
>> there are many which have not been filed on the Issues
>> Wiki but have been responded to on the mailing list or wiki stating by
>> marking them as postponed to errata or later revisions
>> of CSS. I'm fine with that.
>>
>> There are others which were not responded to. I'm happy to re-raise
>> the majority of those for errata or later revisions, and I
>> regard them as postponed for now.
>
> Cool. I think we need a better tracking mechanism than the wiki for the
> errata.
> One where you can directly file all your individual issues as individual
> issues. :)
> It's been a nightmare to keep track of all the editorial issues via
> mailing list.

Yeah, I can imagine!


>> There is one issue which was raised and responded to, but was not
>> filed or "concluded". David Baron provided a proposal which
>> I'm happy with. I'd like this issue to added to the Issues Wiki if
>> possible, even if it's postponed to errata. The issue is:
>>
>> FL3) http://lists.w3.org/Archives/Public/www-style/2010Mar/0366.html
>> http://lists.w3.org/Archives/Public/www-style/2011Mar/0346.html (last
>> third)
>
> Ok, I will file this as 288, marked deferred.

OK, thanks.


>> There are two distinct issues which have been grouped together as
>> Issue 207 on the wiki. They both stem from the same post
>> which I made:
>> http://lists.w3.org/Archives/Public/www-style/2010Aug/0569.html. The
>> first half of the post concerns the fact
>> that clearance results in discontinuities in position of subsequent
>> siblings. This was the original issue that was filed as
>> Issue 207. The second half of the post concerns the fact that
>> clearance is underspecified. The resolution given on the wiki is
>> that the second half is deferred to errata. I'm happy with that
>> resolution, but I ask that the issue be filed as a separate
>> Issue on the wiki. The resolution also says that the first half is a
>> duplicate of Issue 203. This is in fact not the case, but
>> as I said in
>> http://lists.w3.org/Archives/Public/www-style/2011Mar/0424.html I'm
>> happy to defer it to errata. I ask that the
>> resolution on the wiki be updated with that information.
>
> Ok, I will split this issue into 287 and 207 and update the wiki and DoC
> accordingly.

Great, thanks!


Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Thursday, 7 April 2011 07:19:08 UTC