New issue
Advanced search Search tips

Issue 832016 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

div 100vh bug with margin-bottom in last div.

Reported by mind...@gmail.com, Apr 12 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce the problem:
Here is a plnkr witch demonstrates wrong functionality 

https://plnkr.co/edit/vfqH6Vl6FOY8DS9eRKlp?p=preview

What is the expected behavior?
It should not show whitespace after container,

What went wrong?
When using a div with 100vh and margin-bottom in the last div to parent div it adds white space which is wrong.

Did this work before? No 

Chrome version: 65.0.3325.181  Channel: stable
OS Version: OS X 10.13.4
Flash Version:
 
Screen Shot 2018-04-12 at 11.44.24.png
59.5 KB View Download

Comment 1 by woxxom@gmail.com, Apr 12 2018

It's not specific to 100vh because even ".container { min-height: 500px }" exhibits the same bug.
Observed since Chrome 23 at least, including Canary.
Adding text in .container div "fixes" the bug.
Simplified test.html attached below.

test.html
313 bytes View Download

Comment 2 by mind...@gmail.com, Apr 12 2018

I have tested it on windows it does not work in there as well.

@woxxom It has to be fixed, your suggestion is not suitable as I can not add test there.

Comment 3 by woxxom@gmail.com, Apr 12 2018

It's not a suggestion, it's an observation.
Also note the quotes which means the meaning is not literal.
Components: -Blink Blink>Layout
Labels: Needs-Triage-M65
Labels: Triaged-ET M-67 Target-67 FoundIn-67 OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
Able to reproduce this issue on reported version 65.0.3325.181, on latest beta 66.0.3359.106 and latest canary 67.0.3396.0 using Windows 10, Mac 10.13.3 and Ubuntu 14.04 with link given in comment#0.

This issue is seen from M-60. Hence considering this issue as Non-Regression and marking as Untriaged.

Thanks!

Comment 7 by e...@chromium.org, Apr 19 2018

Cc: mstensho@chromium.org ikilpatrick@chromium.org
Status: Available (was: Untriaged)
test.html is a good reduction. The spec has the following to say about what becomes adjoining margins in this case [1]:

"bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height"

I.e. according to the spec, there's nothing to prevent the bottom margins of #header and #container from adjoining, and therefore they are adjoining. Both Chrome and Edge treat them as adjoining, while Firefox doesn't. What Firefox seems way more sensible, but it's not correct according to the spec, the way I read it.

[1] https://www.w3.org/TR/CSS22/box.html#collapsing-margins

I reported a spec issue on this: https://github.com/w3c/csswg-drafts/issues/2607

Comment 9 by mind...@gmail.com, Apr 23 2018

@mstensho current functionality does not make any sense.

If I apply bottom margin it should be applied to an element, not a parent element.

Right?

That is why I have created this bug report.
Margin collapsing: https://www.w3.org/TR/CSS22/box.html#collapsing-margins

Sometimes it's correct to propagate a bottom margin from a child to the parent.

In this particular case, I think the current behavior in Chrome makes no sense, although Chrome seems to do what the spec says.

Comment 11 by mind...@gmail.com, Apr 23 2018

Do you have an example why it propagate a bottom margin from a child to the parent?

I guess they did spec like this for some reason. 
Sure, here:

<!DOCTYPE html>
<div style="background:red;">
  <div style="margin-bottom:100px; background:yellow;">
    There should be no red on this page.
  </div>
</div>
<div style="background:cyan;">
  There should be a white vertical gap between the yellow box and the cyan box.
</div>

Comment 13 by mind...@gmail.com, Apr 23 2018

Yes, it makes sense, especially from the technical point of view.

But if you read into a:

* If the top margin of a box with non-zero computed 'min-height' and 'auto' computed 'height' collapses with the bottom margin of its last in-flow child, then the child's bottom margin does not collapse with the parent's bottom margin.

It says that it does not have to add up to parent right?
That's about the *top* margin of the parent collapsing with the last in-flow bottom margin, which isn't the case here.

Sign in to add a comment