The Large, Small, and Dynamic Viewports – Bram.us


~

Table of Contents

  1. The Large, Small, and Dynamic Viewports

  2. The catch
  3. Going Logical
  4. In Closing

~

Update 2021.07.14: Some parts of this post have been rewritten to include the latest CSSWG changes regarding these units.

Update 2021.07.23: 🎉 The proposed changes have landed in the official spec by now. This post has been updated accordingly.

~

# The Large, Small, and Dynamic Viewports

The CSSWG has defined several extra Viewport Sizes and accompanying Viewport-relative Units (spec), in addition to the already existing vw/vh/vmin/vmax ones.

# The Large Viewport

The Large Viewport is the viewport sized assuming any UA interfaces (such as the address bar) that are dynamically expanded and retracted to be *retracted*. It has the l-prefix, so units are lvh / lvw / lvmin / lvmax.

# The Small Viewport

The Small Viewport is the viewport sized assuming any UA interfaces that are dynamically expanded and retracted to be *expanded*. It has the s-prefix, so units are svh / svw / svmin / svmax.

# The Dynamic Viewport

The Dynamic Viewport is the viewport sized with *dynamic consideration of any UA interfaces*. It will automatically adjust itself in response to UA interface elements being shown or not: the value will be anything within the limits of 100vh (maximum) and 100svh (minimum).

Its prefix is d, so the units are dvh / dvw / dvmin / dvmax.

👉 You’ll want these Dynamic Viewport Units to have a UI that auto-stretches as the UA interface changes.

~

# The catch

As mentioned before these new proposed l*/s*/d* units are additions to the already existing vw/vh/vmin/vmax units. With this, the CSSWG chose to keep these “old” units ambiguous: they have no explicit definition, and it’s totally up to the UA (browser) to define how they behave. Some browsers will have vh behave like lvh (like the current Safari does), while other browsers can make vh behave like dvh.

What also is up to the UA to choose, is the behavior of the Dynamic Viewport. Some browsers may update its value immediately while the interface is changing, whereas other browsers may only update the value after the UI has transitioned … the spec is fine with both.

The UA is not required to animate the dynamic viewport-percentage units while expanding and retracting any relevant interfaces, and may instead calculate the units as if the relevant interface was fully expanded or retracted during the UI animation.

Above that things like on-screen keyboards are not taken into account. For that we have the upcoming Virtual Keyboard API.

~

# Going Logical

Additionally the spec now also defines logical units, and thus talks about vi/dvi/svi and vb/dvb/svb which are the inline and block size respectively of the large/dynamic/small viewport. A small but very welcome addition.

~

# In Closing

It feels great to see things finally move in this area I must say, as the reported WebKit bug dates back from 2015, and the relevant CSSWG Issue from 2019.

As a final consensus on these viewport additions has been reached, I hope that the upcoming Safari 15 — which alters the viewport extensively as you scroll up/down — will make work to include these additions on top of their already supported env(safe-area-inset-*) values (e.g. height: calc(100vh - env(safe-area-inset-bottom));).

~

To help spread the contents of this post, feel free to retweet the announcement tweet:

~

🔥 Like what you see? Want to stay in the loop? Here’s how:





Source link