units of measure

This article is an evaluation of viewport performance, Spring of 2015. Viewport is a collection of CSS declarations. Viewport appeared in Web 2.0 and now in Web 3.0 is being made useful. Viewport is better suited to professional design and deployment at present, as it is a new approach to established technology, requiring understanding of architecture and systems that build the Internet. Simple viewport applications of DOM (HTML and CSS) are ready for public use.

Viewport is sometimes referred to as a “technology”, probably as it so fundamentally empowers existing technology. But no, CSS is nothing new, nor is viewport which graced Earth's first computer display. For now, understand that to acquire a technology, you must arrange a suitable environment. Keep that principal in mind, working with viewport.

There are a two easy fixes you need to make your site viewport friendly. Each fix requires one simple, dedicated task, not necessarily in any specific order.
TASK: convert measure to viewport
TASK: bridge viewport with ‘safe’ measures, as required
One could easily code an entire site using only viewport units of measure. CSS3 transforms and transitions could any viewport into a wiggling bowl of jello. Be prudent.

Viewport Tips

  1. The viewport is always a parent style process, but it depends on appropriate child declarations to maintain its presence.
    • The viewport relies on exclusive parenting of only relative fluid measures, including bridging for screen technology.
    • Exclusivity is not an intended property of the parent, but simply conforms to all known logical space models associated with common html and css.
      Get ready for 3D printing!
  2. Viewport supports various applications of text and object, to style response to viewport change...
    • In order to optimize style response, it is useful to maintain a coded root viewport deployment:
      <meta content="initial-scale=1.0" name="viewport" width="device-width">
      <style type="text/css">
      body { font-size: 2.97vmin; }
      @viewport { width: extend-to-zoom; zoom: 1.0; }

      Device-width is contentious for a few old androids, but grid layouts require it. This page has no grid (css table), so viewport meta-tag omits device-width.
    • Font-size with viewport can mean all devices display the same page the same way (v-units and rem), or…
      Depending on your viewports physical size, you can see fluid variations everywhere (v-units, % and rem... check out Big Bird at Storm-Link)
    • IMPORTANT! % and rem units must be carefully integrated with the parent viewport.
      While it is true that in general 1v-unit is approximately equal to 10 px, for the purposes of simple conversion, it is more sensible to convert to rem, rather than covert to a % or viewport unit of measure, for all font-size conversions. The rem units are specifically tailored for such conversions, as rem units are suited to address complex vector relationships that exist in all fonts. Conversions set aside, rem is simply the best measure to style font size inside of viewports' screen relationships.
      Retrospectively, the current pixel dependencies of query call-ups will perhaps extend to include measures suited directly to viewport.
      selector { text-shadow: 0.05rem 0.05rem 0.01rem rgba(255,255,255,0.5); }
  3. Screen is where most web 2.0 sites are cramped today, and where floppy bootstraps come 'a-clunking'.
    • Viewport is where designers are looking, to explore the 'new' (or expanded) fluid viewport layout.
    • To begin, remove ALL static measure ( px, em, etc. ) from ALL internal style and attached style sheets.
      With only one exception...

      Static measuring units such as px measures CAN BE USED IN ANY QUERY CALL-UP ( @media, @viewport, etc. ).
      e.g., @media screen and (max-width: 480px)
      but static measure MUST NOT BE USED TO STYLE ANY QUERY CALL-UP
      e.g., @media screen and (max-width: 480px) { #outerWrapper #header { font-size: 15px; } }
      Viewport relative fluid convention should be followed to code style inside of the screen environment.
      e.g., @media screen and (max-width: 480px) { #outerWrapper #header { min-height: 1rem; } }

      This is because the query call-up is addressing all devices and machines from the viewport dependent external environment, which is outside of the screen dependent internal page environment. This is also because viewport attaches to the style hierarchy root, regardless of where in the hierarchy viewport code is planted: viewport points to all HTML tags on the page, not necessarily styling each element, but 'staging' the display's global fluid style environment...
      While the query's call-up rests outside of the hierarchy, in the containing network environment, screen style is obviously under the skin of each local device that deploys any global viewport call-up. That is, viewport's deployment is dependent on screen's selector declarations conforming to the fluid relationships that anchor viewpotr to the screen. Static screen and fluid viewport measures simply canot be pointed at the same element tag in the same page, it is not possible to be static and fluid at the same time, within the screen environment...
      Should a static measure slip into the fluid screen code stream, the global viewport collapses and the local screen environment takes over.

A Few Details

Consider viewport style hierarchy.
Parent layer is fluid, because its outline properties are identical (FLUID) across all devices.
Parent layer is fixed, as viewport cannot be changed on any device, you get only one viewport per device or browser window.
Child layers must also be fluid, as each page measure addresses the containing viewport cascade through the browser window and device screen.
Child layers must be relative to the ‘full screen’ environment contained by the physical viewport technology.

Initiate viewport using a meta tag, as follows.
<meta name="viewport" content="initial-scale=1.0">
This prepares the Internet browser for viewport styling. This viewport style will be further cemented in older devices by inserting a viewport query, enforcing bridging between screen and viewport environments.

Viewport measure can be directly applied to the parent body element, using a viewport unit of measure: vh, vmin, vw.
EXAMPLE: body { font-size: 2.76vmin; }
IMPORTANT! All child measures under the root must be relative fluid measures: rem, %, vh, vmin, vw.
At Riverleaf, we have tried to isolate viewport in section elements, but this does not work (see above, TIPS).

Queries are another essential ingredient. To manage smaller (older) devices whose browser outlines represent the full screen viewport, the following CSS code may be useful.
@viewport { width: extend-to-zoom; zoom: 1.0; }
@media (some call-up) { @viewport { width: extend-to-zoom; zoom: 1.0; } /* media style goes here */ }
Outside of a few networks where IE10 updates are blocked, the @-ms-viewport query is not required.

Microsoft and Adobe engineers WHO WE MERE MORTALS ARE ALLOWED TO COMMUNICATE WITH... are not clear on what specific relative units are in fact viewport friendly. This is because web 2.0 is the launching pad for viewport, and web 3.0 when it arrives will use our 2.0 anchor to host viewport technologies. Web 2.0 structure is viewport’s first PUBLIC HTML/CSS release and anchor environment (don’t ask me why IE6 displays viewport with fair accuracy). Esthetically, I imagine my viewport productions to be like Kindle Readers: only far more flexible and universally resource friendly. Friendly, because viewport has been a programmatic structure ever since French Tel Sat launched 60 years ago.

Why so few relative fluid measures, and why leave out vmax in this discussion?
There are enough measures to accomplish everything we need to do. Vmax is not supported by IE and Operah Mini. Vmax is slated for integration in 3D applications, where it is a critical measure. Auto-Cad has its own layer systems, regardless of browser used. If you really need to max-out on a contemporary 2D web page, deploy @media or @ viewport.
What use is viewport technology today?
Today is a very fluid temporal framework. Two weeks ago I wrote Microsoft complaining that text-shadow only accepts px units which are not fluid or relative and hence collapse viewport style. So viewport pages could not use text-shadow! A few days later, Microsoft and Apple updated their browsers to use viewport units for text-shadow: 1px = 0.1vmin, approximately.

Selector uptake is rapidly expanding as the viewport anchor digs into the fertile foundations of CSS. Do not take for granted that only rem and % can complement the v-units: experiment with other relative units anywhere need arises (See below, W3 REFERENCES).


Let’s take one more look at those complementary units: REM AND % LISTED ABOVE.
These units actually ‘bridge’ the old static-based web 1 and web 2 units, into the new Web 3.0 viewport cascade [Kindly note however, viewport launched 2008 into Web 2.0, though it was poorly supported by major browsers.].
Units rem are relative expressions of the static em unit, at the exact point where the em always appears in the style hierarchy’s ‘root’.
Where em appears in the root of the hierarchy: when text content exists, on the page for non-viewport measure associations.
Where the style hierarchy begins: where text may be included, for viewport measure associations.

So, we can see that a bridge is essentially always there for us to style around, with relative fluid measures.
All that web designers require is a set of selectors and values that are viewport accessible.
I mentioned text-shadow above, and frankly haven’t found any other holes to be plugged.

Across devices...
Viewports' fluid bridging makes the style cascade's hierarchy structure far more logical than the traditional static screen objects' relatively conflicted and competitive cascade.
Can this relate to a reduction of accessible measure values, for the 'new' html viewport, which will eventually overload and conflict like screen hierarchies do today?
Again, no comment from the engineering teams I can interact with.

Within each device...
Traditionally, em units in bottom-margin measure behave differently than em units for top-margin.
Depending on selector, property and value, we are all left pulling our hairs out trying to figure out what is going on.

Static and fluid...
Viewport units are structured around the fixed viewport in a fluid multi-device environment, with a limited but more focused set of style property values.
Old static units are structured around competing cascade elements that can be variously static or fluid, relative or absolute, resulting unresolved compatibility issues.

.closeform { font-size: 2.5vh; margin-top 95vh; }...
No way is the viewport design culture thirsting to fall back into the old static screen chaos.

Bootstrap’s GAWD! AWFUL! Clunkiness is another dead bird in free-fall. You think?
body { font-size: 2.97vmin; }
@media all and (device-width:768px) { body { font-variant: small caps } }
100 paragraphs from page-top, does the browser focus stop flipping away, somwhere up-or-down?
Well… okay, that’s stretching it: Apple and Microsoft Teams are now working to extend certain hand-held device’s “reliable focus” to all devices.
Until then, nothing lost or gained by avoiding stupid and applying intelligent @media queries.
@media all and (device-width:768px)... color: black.

Here is my demonstration of viewport bridging: BIG BIRD - fixed and fluid, resize your browser and flap his wings.

Viewport-Safe Measure

Units % rem vh, vw vmin (good enough for most site layout)

Note that Microsoft IE resolution involves EXTENSION of text-shadow to INCLUDE vh, vw and vmin. Backdrop please? For at least another decade, Earth is stuck in conflicted style, as the OS’s gradually extend and include everything ‘screen’ in 3D friendly viewport… Anyway, excepting text-shadow in older browsers, and bootstrap-in-transit, pixels remain conflicted and ignored, so the five staples above work fine, and are backwards compatible to IE 5/6 in my tests. Where’s the link to that view in other browsers site? Move on.

% (percent) Percent and rem are clever foot holds between screen and viewport.
They both capture any device tendencies to secure display object in a static space.
At the very same time, they both anchor those static relations in viewport.
The logical and logistical bridge.

Simply convert all your pixel units and em units to rem units.
To convert pixels, go metric: 10 pixels are 1 rem.
Adjust rem then to suit layout using a simple body { ‘n’v-something; } environment.
To convert em to rem, type ‘r’ in front of any ‘em’ to make a rem.

Read this page from Chris Coyer with caution.
You are visiting a bootstrap occupation trying to manually script style overlays to compete for 3D control against super-computer extensions of scripted overlays.
Well, it works like this. Script all your style. Then convert your styled script to more script. Then convert that to viewport. No thanks. Simple folk here.
(Chris either forgot to write to Microsoft to request style features, or has morphed into a test rat species on the development ramp that Microsoft/Apple/Ubuntu uses to test and resolve formal requests… long story, but suffice to say that where viewport is discussed, Chris seems to squeeze his eyes very tight and try even harder to confabulate conflict, calling himself a “Brave warrior”… Contribution appreciated here, Chris!)

VH, VW Cuter, Craig Buckler.
What Craig says about vm and vh font size is only relevant if you choose viewport units to size fonts. Not always good idea. Hang onto that idea until we share below how rem and percent bridge screen and viewport layout. For now, appreciate that aesthetically fonts, built around fluid relative vectors, need that rem anchor to snug text flow into the fluid relative viewport. Naturally hitting on a stable policy for a world tinged in screen chaos. Therein devicing the marketplace. Raw romance.

Craig can decide on any mix of rem, percent and/or viewport to layout, just like all the rest of us. Big Bird love. Viewport love. All the same simple assembled part of something much more complex. 3D dimension!

VMIN This measure tells us something very important about viewport-sized objects.
In any viewport window or device edge, object x and y proportions are stable.
Craig demonstrated this for us with vh, vw font sizes.
But not all bridges are flat.
Especially viewport bridges, which arch and sweep in explicitly in every direction.
That is, x-y distortion of objects does not occur except in very specific application of the rem-% bridge. In fact, because of this this stable bridge relationship that permeates vmin (and vmax) measure, especially noting the specific rem-% distortion capability, Microsoft quite rightly determined that 2D support for VMAX was redundant. Which indeed it absolutely is! Can’t find the link to two redundancy discussions anywhere today. But now, 3D printing is unfolding, and so here is an opportunity to unleash vmax as a stable ordinal. It’s not just that Microsoft is addicted to being the standout, even if here the impact is zero. The VMAX standout allows Microsoft to posture, while prudently retaining a symbolic ‘final say’, as vmax is applied to the depth curve. Please don’t break my leg!

Rule # One
(and a half)

Stay away from scripting, for now: unfortunately, most popular scripting styles HTML5 and CSS3 behaviors inside the screen environment. Some day, that may be okay. Not today!
We should never script style anyway, just the style’s element containers. HTML and CSS manage pages right. Manage pages better with appropriate script support. The DOM's foundation user interface, HTML and its CSS branch are complex and capable, too often ignored. Open your viewport!

Any thoughts? Join the conversation. 604-677-1560