vh-based rules don't respect media queries

[tjmeneses]

When I write rules in media queries, I noticed that the last rule of a given selector using vh units override any succeeding rule targeting the same selector bu using different units (i.e. not vh). Also, the same vh-based rule inside any media queries will get executed regardless of whether the query returns true or not.

I understand that your implementation pulls vh-based rules out of stylesheets and into the HTML, but perhaps you could make it so that every succeeding use of the selector gets pulled as well, and that any wrapping media queries is also grabbed.

[rodneyrehm]

I see the problem. The "simple" solution would be to simply grab the entire source CSS, replace the viewport units and dump it back into the DOM. Looking for succeeding rules that might or might not override a viewport-unit-using-rule seems like too much trouble to go through.

[gregplaysguitar]

I just had this exact issue - would be great if there was a fix but I can see how tricky it would be to solve. Would your "simple" solution have performance drawbacks?

[rodneyrehm]

Without having this tested I would say "yes". We would be replacing the entire CSS with every change to the viewport (resize, orientationchange). Depending on the device's performance and the amount of CSS you throw at it, this might take a little while. The browser has to parse the CSS, style (calculate the styles for each element), layout (calculate the layout based on changed style), paint (draw the result of the layout) for the entire document - instead of, in the best case, only couple of elements.

[stophecom]

+1

[nhoizey]

I think I have the same issue: http://lab.gasteroprod.com/vub/

I had to add !important to the top: auto; in my real code.

This lib could at least duplicate rules that have values like auto and inherit

[rodneyrehm]

This lib could at least duplicate rules that have values like auto and inherit

That would mean the lib had to understand what auto and inherit mean. So really this is not an option. Copying all the CSS and doing a replace right there is probably the only sane way to solve this problem. But even that's opening another can of worms…

[nhoizey]

understand what auto and inherit mean

Why would it be necessary, if they are simply copied into the new rules?

Feels safe IMHO, and really better than copying everything.

[rodneyrehm]

Why would it be necessary, if they are simply copied into the new rules?

I think I didn't make this clear enough. The library doesn't need to know what auto and inherit mean. It has to know that these values exist in the first place.

Feels safe IMHO, and really better than copying everything.

Why stop at auto and inherit? What about initial? And what about about any other value that is being set? I fear this idea does not scale. I have trouble understanding why auto and initial are to be handled differently from every other value… Maybe you can elaborate?

We should either fix it "properly" (whatever that is), or leave it open as a known issue if we can't.

[nhoizey]

The library doesn't need to know what auto and inherit mean. It has to know that these values exist in the first place

Ok, makes sense.

I have trouble understanding why auto and initial are to be handled differently from every other value…

My example shows that these values, when set in a MQ, are ignored because the value set by the lib outside the MQs (Mobile First CSS…) is inline, with greater specificity.

[nhoizey]

Maybe it's more obvious when comparing http://lab.gasteroprod.com/vub/index-bugfill-issue.html and http://lab.gasteroprod.com/vub/index-bugfill-fixed.html on thin and large screen (MQ at 20em).

There is only one !important added to the second's CSS.

[rodneyrehm]

I understand the problem just fine, only the suggested solution did not compute. I stand by comment 1, transforming the entire CSS into one <style> seems to be the simplest solution…

[nhoizey]

Simplest maybe, but dangereous for performances, as already said… :-/

[celiolatorraca]

Hi everyone!!

Any news regarding this issue?

[nhoizey]

I've been hit once again by this issue on http://alpha.esviji.com on iOS… :-/

I had to add !important to a height: auto; inside a Media Query.

[Lenoxus]

Huh, that took a while for me to narrow down in my project. I see why it wouldn't be easy to fix, though.

[Hiswe]

I've been able to handle vh & media-queries by doing a very different thing…
It's really less handy than the buggyfill, but it has done the job in a recent project for me:

https://github.com/Hiswe/vh-check

If you see something wrong with the approach (or the code), let me know :)

[AllanPooley]

I guess another work around for this is writing your css mobile-first.

Make your breakpoints apply style overrides to desktop resolutions as opposed to the opposite way around.

[AllanPooley]

With the UI / URL Bar collapsing and revealing on iOS chrome, my hero images using vh units were shrinking and expanding on scroll and it was driving me nuts!

I've spent about 6 hours on this issue. I've ended up opting for a solution posted on CSS-Tricks by Louis Hoebregts.

It goes like this...

In your Javascript (in my case, React) add:

componentDidMount() {
    // First we get the viewport height and we multiple it by 1% to get a value for a vh unit
    const vh = window.innerHeight * 0.01;
    // Then we set the value in the --vh custom property to the root of the document
    document.documentElement.style.setProperty('--vh', `${vh}px`);
}

Then in your CSS add:

:root {
  --vh: 1vh; // Fallback units
}

.full-width-hero {
    width: 100%;
    height: 90vh;
    height: calc(var(--vh, 1vh) * 90);
}

More here: https://css-tricks.com/the-trick-to-viewport-units-on-mobile/

[sstauross]

Solved this issue with the calculated vh in a React project using this library: https://github.com/mvasin/react-div-100vh
The actual height is calculated using javascript in this.