- From: antonprowse via GitHub <sysbot+gh@w3.org>
- Date: Tue, 11 Oct 2016 22:18:29 +0000
- To: public-css-archive@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