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

On Tue, Nov 1, 2016 at 1:40 PM, Anton Prowse <prowse@moonhenge.net> wrote:
> 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?

Pushing the content down when the preceding float is 0px is consistent
with how Flexbox's line-breaking works, btw.

That said, Chrome also doesn't push the word down in that case.

~TJ

Received on Tuesday, 1 November 2016 22:02:18 UTC