W3C home > Mailing lists > Public > www-style@w3.org > November 2016

Not convinced by resolution from Telecon 2016-10-26: [css-box-3][css-21] Positioning boxes with { float:left; width:0px; }

From: Anton Prowse <prowse@moonhenge.net>
Date: Tue, 1 Nov 2016 21:40:19 +0100
To: www-style@w3.org
Message-ID: <fb93ef50-0e5c-aa67-ac55-d89b9c4170a7@moonhenge.net>
> Positioning boxes with { float:left; width:0px; }
> -------------------------------------------------
>
>   <Rossen> https://github.com/w3c/csswg-drafts/issues/576
>   Rossen: Who added this?
>   fremy: Probably me.
>   TabAtkins: astearns put it back on.
>   Rossen: Is it close? Do we need discussion?
>
>   fremy: We need to resolve. Last time we concluded but people
>          wanted more time to review. We said if you have 0px floats
>          it's shortening the line so you wrap to the next line.
>   fremy: If people are fine we can resolve.
>   TabAtkins: This means if you have an inline that exactly fills
>              space a 0px float stays. If it's larger the float wraps?
>   fremy: Yes.
>   TabAtkins: Perfect. I agree.
>   Rossen: Which test case in github is an example of what you just
>           described?
>   fremy: First 2.
>   Rossen: Both I see interoperability.
>   <tantek> is this bugwards / accidental interop? or deliberate?
>   fremy: You must be on a different Edge version..
>   Rossen: 0px floats cannot fit in a 0px available width?
>   fremy: It's when you have a negative avail width. If your line
>          already overflows you're on the next line.
>   Rossen: I'm fine with it.
>
>   <dbaron> these testcases are complicated enough that I'm not
>            incredibly confident that we're even discussing the right
>            issue to cover the testcases
>   <tantek> agreed with dbaron
>
>   Rossen: Objections to defining that floats in an over-constrained
>           scenario drop to the next line?
>   dbaron: That's not really the resolution.
>   Rossen: No? That's what I heard.
>   dbaron: The issue is about if the inlines are pushed down. It's a
>           0 width float constitutes a float that shortens the
>           linebox.
>   Rossen: I can live with that as well.
>   TabAtkins: That's if the float is before. If the float is after
>              it's pushed down.
>   Rossen: Correct.
>   fremy: Yes.
>   Rossen: How is the 0px width any significance?
>   TabAtkins: Because 0px don't take space. You can always cram them
>              onto a line without making it worse.
>   dbaron: We should be very careful, but the reason I thought it was
>           is because the spec says "if a float shortens the linebox"
>           A 0px width float counts as a float shortening the
>           linebox. I believe that's the clarification.
>   TabAtkins: I think so. I think that's the actual spec change.
>   fremy: I think that's it. A 0px float is shortening the line box.
>   Rossen: Okay. I can live with this behavior
>   <fantasai> Proposal for hanging-punctuation is,
>              hanging-punctuation is scrollable overflow. UAs *may*
>              trim the blank half of overflowing CJK punctuation that
>              takes up 1ic but only has ink on the inner half. (This
>              will have no effect on rendering but may affect the
>              scrollable area.)
>   dbaron: Specifically 0px width. Not height.
>
>   TabAtkins: It's the same as flexbox. If you have a 0px flexbox and
>              a really big thing, the really big wraps. If you
>              reverse the big stays and the 0 wraps.
>   TabAtkins: Flexbox spec is explicit about this. Float is less. It
>              gives you constraints. Flexbox should be interoperable
>              on that because it has an algorithm that says do this
>              thing.
>   Rossen: Okay.
>
>   Rossen: dbaron can you summarize proposal one more time?
>   dbaron: Proposed resolution: 0px width float that is next to a
>           line box does count as shortening a line box
>   Rossen: Objections?
>   fremy: It's fine.
>
>   RESOLVED: 0px width float that is next to a line box does count as
>             shortening a line box

Just to be clear, this resolution is basically saying "we confirm that 
what the spec says is correct", since the spec already says that /any/ 
float with a margin area of positive height that's on the same 
horizontal level as a line box is regarded as shortening the line box. 
(I don't agree with dbaron and Tab that a clarification is needed; the 
spec is clear.)

Or to put it another way, the answer to Fremy's question at the end of 
the post with which he opened the issue is: we should file bugs on 
browsers here, rather than change the rules.  And that ought to be the 
end of it.

But, since we're discussing these cases, I'll point out that I'm not 
sure that we should be so happy with the current rules in the spec.

Consider the opposite case where a 0-width float precedes an overflowing 
inline, such as in the the last two examples in 
https://lists.w3.org/Archives/Public/www-style/2010Aug/0182.html as well 
as in the following example:

<!DOCTYPE html>
<div style="width:100px; height:100px; background:gray">
	<div style="float:left; width:0; height:50px;
background:green"></div>
	<span>supercalifragilisticexpialidocious</span>
</div>

The spec says that the inline should get pushed down to below the float 
(because the line box is shortened since the float is next the line box; 
note that the spec basically says that "next to" means you can draw a 
horizontal line to connect the float's margin area box to the line box, 
irrespective of whether they even touch - although I do suspect that 
that definition was arrived at in order to solve the 0-height float 
problem of Issue 185 [https://wiki.csswg.org/spec/css2.1#issue-185] 
rather than because of some deeper fundamental consideration).

But Gecko (for example) doesn't push the word down, which I think is 
reasonable of it; and indeed I certainly dislike treating the line box 
as being shortened in the case where the right margin of a preceding 
float is negative and doesn't even intersect the content area of the 
element which generates the block container box in which the line box 
sits - yet that's what the spec demands.

So perhaps we *should* consider changing the spec to approve Gecko's 
current behaviour in the latter situation.  What do folks think?

It would make for some hard editorial work though, since we do still 
want to achieve the motivation for the resolution, namely that 
/subsequent/ 0-width floats should be pushed down to below the 
overflowing line box; and if we're no longer able to achieve that in the 
way that the spec currently does it (by saying that such a float is next 
to the line box and hence shortens the line box) then, since it will be 
horrible to try to exclude such floats from being regarded as "next to 
the line box", we will instead have to introduce float placeholders and 
say that if a placeholder is encountered immediately after an inline 
which overflows then it is treated as sitting at the start of the next 
line box instead of at the end of the one containing the overflowing inline.

Thoughts?

Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Tuesday, 1 November 2016 20:43:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:05 UTC