Issues using vh units in CSS

How do I get backstopJS to respect height: [num]vh in my css?

Theyre getting comically stretched out.

Eg. (viewport: 1366x768, selectors: ‘document’)

Actual Chrome Browser (1366x768) - showing just the second section, for reference:

Those two stretched-out sections have a height:90vh.

[kwaves]

Here’s how I get around this issue:

CSS variables to the rescue

Step 1: Set all vh values with a CSS variable

:root {
  --viewport-height: 100vh;
}

Example usage:

.full-viewport-height {
    min-height: var(--viewport-height, 100vh);
}

.half-viewport-height {
    min-height: calc(var(--viewport-height, 100vh) * .5);
}

Step 2: Hard-code a px-based --viewport-height for your tests

Update the top line of overrideCSS.js to something like this:

const BACKSTOP_TEST_CSS_OVERRIDE = `html { --viewport-height: 1000px !important; } @media screen and (max-width: 361px) { html { --viewport-height: 740px !important; } }`;

The values above should match the dimensions of your viewports in backstop.json. In that example, the viewports were:

{
  "id": "whatever",
  "viewports": [
    {
      "label": "desktop",
      "width": 1440,
      "height": 1000
    },
    {
      "label": "mobile",
      "width": 360,
      "height": 740
    }
  ]
}

The above also assumes you’re using onReady.js with the default overrideCSS reference intact.

For Chromy folks, you’d need to adapt overrideCSS.js from the Puppeteer folder.

Side benefit for 100vh mobile UI patterns

This idea occurred to me when I was trying to fix another problem:

As you may know, there’s a long-running “feature-not-a-bug” on iPhone (and now Android too) where 100vh ignores the top and bottom browser bars. Those bars jump around as you scroll (and is also directionally-dependent, to my memory). The result is this:

(Graphic: CSS Tricks)

More example code of the fix here.

Side note: While most people seem to be calculating 1vh then multiplying with calc(), I’ve found it’s usually cleaner to set 100vh and divide, at least for the sorts of problems I’m usually trying to solve.

This doesn’t seem like a Backstop problem

Given we’re seeing this vh behavior with Chrome’s full page screenshot feature in DevTools (as a commenter above pointed out), perhaps this should be addressed in Chromium (or whatever’s responsible for this feature)? I’d be surprised if this wasn’t a deliberate choice–even off the top of my head I can think of some advantages to handling it the way they currently are–but maybe this could be a candidate for a flag.

[JamieMcNaught]

See my bug #820 - this seems to be an issue with the way Chrome(y) takes the screenshot by resizing the page - you can reproduce the issue in desktop Chrome by using “Capture Full size screenshot” in the “Developer Tools + mobile view”. What I think we need to do is screenshot, scroll, screenshot, scroll and then stitch together.

I’ve no idea of any current + working workaround, but without a work around unfortunately I can’t use backstep 😦 😦 😦