W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2016

Re: [csswg-drafts] [css-box-3][css-21] Positioning boxes with { float:left; width:0px; }

From: antonprowse via GitHub <sysbot+gh@w3.org>
Date: Tue, 11 Oct 2016 22:18:29 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-253063816-1476224307-sysbot+gh@w3.org>
We've had a similar discussion in the past:
https://lists.w3.org/Archives/Public/www-style/2010Aug/0182.html
https://lists.w3.org/Archives/Public/www-style/2010Sep/0129.html

In that discussion we concluded that a 0-width float doesn't shorten a
 line box.  (Really, we should be a bit more careful here, as we were 
in that discussion and other contemporary ones; the relevant thing is 
not the width per se but rather the position of the right margin edge 
of the float [assuming it's a left float] and whether that intrudes a 
non-zero amount into the space where the line box would otherwise 
begin.  The final two examples in the first post I linked to 
illustrate that, and also illustrate that browsers don't regard the 
float as shortening the line box [else the subsequent overflowing 
unbreakable word would have to be shunted down to below the float].)

But let's quickly consider what would happed if such a float _is_ 
regarded as shortening a line box.  If I understand Fremy correctly, 
he's considering the situation in which there's an overflowing 
unbreakable word immediately followed (in the source) by a 0-width 
float, and he's questioning whether the float should remain on the 
same line as the word, or whether it should drop down to align with 
the sunsequent line box.  In this case, the float can't stay on the 
same line as the word, because given that the line box is regarded as 
shortened and is not sufficiently wide to contain the word, the line 
box would need to be moved down below the float - and yet this 
contradicts the positioning rules since the float is later in the 
source than the word.  So the only option is to move the float down to
 the subsequent line.

Back to regarding the float as _not_ shortening the line box, we have 
to decide whether the float can stay on the same line as the word or 
move below.  The spec seems to have something to say here:

9.5 Floats, paragraph 7:

  # [...]. In other words, if inline-level boxes are placed on the 
line before a left float is encountered that fits in the remaining 
line box space, the left float is placed on that line, aligned with 
the top of the line box, and then the inline-level boxes already on 
the line are moved accordingly to the right of the float (the right 
being the other side of the left float) and vice versa for rtl and 
right floats.

Now, the text in this section is pretty raw and I don't think we can 
treat it as gospel, but my interpretation is that first we reached the
 word and it's found to overflow, and then we reach our 0-width left 
float, and we have to decide whether it "fits in the remaining line 
box space".  I would argue that it doesn't fit, because the word is 
already overflowing.  And so we don't apply the instruction to place 
the float on the same line.  That is, we place the float on the 
subsequent line.  Of course, it's also reasonable to argue that it 
_must_ fit because it's zero-width.  But I prefer the first 
interpretation, and it gets my vote.  (Plus I like the fact that it 
corresponds to the result that you're obliged to get if you want to 
regard the float as shortening the line box, thus making it a moot 
point whether you regard the line box as getting shortened or not.)

-- 
GitHub Notification of comment by antonprowse
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/576#issuecomment-253063816 
using your GitHub account
Received on Tuesday, 11 October 2016 22:18:36 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:04 UTC