The spec text here is not especially thorough. This is the relevant text, I think: > The border box of a [...] an element in the normal flow that establishes a new block formatting context [...] must not overlap the margin box of any floats in the same block formatting context as the element itself. If necessary, implementations should clear the said element by placing it below any preceding floats, but may place it adjacent to such floats if there is sufficient space. https://www.w3.org/TR/CSS21/visuren.html#floats The disagreements between browsers here are simply different choices under the spec's allowance that we "may place it...if there is sufficient space". It seems everyone is in agreement that 0px to the side of a float is sometimes sufficient space for a 0px-wide formatting context; we are just extra-thorough/consistent about that, whereas it seems Chrome and WebKit are a little bit (in my opinion) less consistent about that. So: I think this is probably "invalid" from a spec-compliance perspective. If there are WPT tests that rely on Chrome's behavior here, we should probably fix those WPT tests (or file bugs on them in their authors' bug trackers).
Bug 1763431 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The spec text here is not especially thorough. This is the relevant text, I think: > The border box of a [...] an element in the normal flow that establishes a new block formatting context [...] must not overlap the margin box of any floats in the same block formatting context as the element itself. If necessary, implementations should clear the said element by placing it below any preceding floats, but may place it adjacent to such floats if there is sufficient space. https://www.w3.org/TR/CSS21/visuren.html#floats The disagreements between browsers here are simply different choices under the spec's allowance that we "may place it...if there is sufficient space". It seems everyone is in agreement that 0px to the side of a float is sometimes sufficient space for a 0px-wide formatting context; we are just extra-thorough/consistent about that, whereas it seems Chrome and WebKit are a little bit (in my opinion) less consistent about that. ~So: I think this is probably "invalid" from a spec-compliance perspective. If there are WPT tests that rely on Chrome's behavior here, we should probably fix those WPT tests (or file bugs on them in their authors' bug trackers).~