[Spec editing] Viewport height

Question

[Spec editing] Viewport height

JayPanoz opened this issue 7 years ago · comments

Just so that you know, the Viewport height sub-section in the CSS section doesn’t make any sense.

Viewport Height (vh)

Kobo advises against using the CSS element vh in reflowable content as it is not supported on all display engines and may result in text getting cut off or overlapping with other content. More conventional elements such as height or max-height are recommended.

First and foremost, the main use case for vh is (portrait) images, not text. And it’s useful for images.

Then, vh is not a CSS element but a unit. So it’s like %, em, px, etc.

In other words, you use vh in combination with height or max-height, not as a substitution of those two CSS properties. What you mean is probably:

A more conventional unit such as % is recommended.

But that brings other issues as it means you must make sure (on your side) that you don’t break the cascade and the container wrapping the content with a (max-)height + % unit combo can have an explicit/computed height (or else the value computes to auto or none). Which is to say the author’s declarations are then useless.

For instance:

html, body {
  height: 100%;
}
figure {
  height: 80%;
}
img {
  height: 100%;
}

Will fail if you have some wrapper and don’t set its (max-)height:

<html>
  <body>
    <div class="kobo-wrapper">
      <figure>
        <img alt="" src="img.jpg" />
      </figure>
    </div>
  </body>
</html>

Which is the reason why the viewport units exist, BTW, since the viewport-percentage lengths are relative to the size of the initial containing block.

As regards interop, it’s worth noting other vendors are actually advising authors to use vh units e.g. portrait images. So you might want to introduce feature queries to authors at some point, since it can solve a lot of your limitations/issues related to having to deal with both the RMSDK and your own Reading System.

In the case of vh, the underlying logic would look like this:

figure {
  height: 80%;
}
img {
  height: 100%;
}

@supports (height: 80vh) {
  figure {
    height: auto;
  }
  img {
    height: 80vh;
  }
}

Authors have to deal with this anyway, and features queries are the only option if you want to make some progress and kill a lot of maintenance on your side in the longer term (such as dealing with the cascade + % units for height). But there’s also small caps, and a lot of issues you might encounter in the future but are not in the spec yet.

bdugas · Answer 1 · Thu Jan 25 2018 05:49:05 GMT+0800 (China Standard Time)

@JayPanoz we reviewed and will actually just remove the section. I checked and we only had one instance that caused it. The HTML/CSS looked like this:

.ipadportrait
{
        height: 65vh;
        text-align: center;
}

.portrait img
{
        height: 100%;
}


<div class="portrait"><div class="ipadportrait">
<img src="../images/ins-03.jpg" alt="Images"/>
</div>
</div>

It created a text/image overlap. VH seems to have much more verbose browser support than it did when we first came across it. In recent years we haven't come across other display issues caused by use of VH. Content creators should not have to modify their content or send us anything other than what they are distributing elsewhere.