Viewport width unit challenges (HTML/CSS)

Fairly easy to layout modern browser page using vh, vw, vmin and vmax. But I ran into a problems with background text. V-scaled background text sometimes displays larger than the style value, and sometimes smaller. We example these variations in our workspace. V-scaling also refuses to aligns center except with inheritance from parent. How do we style v-scale so that background text is properly styled in browser?

We examine issues using methods from various sources, including CSS-Tricks and noob-cube, as well as W3C. Old as the first display, but only performing as a CSS measure unit in newer browsers; without any apparent corollary coming out of the current shim-market (though cloudflare.com is probably hosting something way too script-intensive for me); and frisky to put it mildly... vw measure is not going away. I want to help us dig in. And maybe get some workaround for quirks, missing responsive fit, and so on. Gee. Is anybody working on a scripted shim for vw? So many questions.

Would like to point out here, that noob's transform trick applied to em units behaves differently than the same transform method applied to 'vectoral' vw units. Transformed em's are static in proportion to screen size, while vw units are liquid.

Eric E. Meyer, "CSS Pocket Reference" follows the crowd, lumping vw in with 'static' relative measurement units. Vw is fluid, and W3C is recognizing two units of measure (including vw) 'may' require a new "fluid" frame of reference. With W3C that could mean 20 years down the road. For now, vw is simply relative measure, with a four-legged punch.

http://teamtreehouse.com/workspaces/1337822# (please do read the Workspace files' content, thanks)

index.html... with/without shims, same problem. Complex 3d page-space

noob-textblock.html... simple 2d fit

noob-textchar.html... dissecting vw across 2d/3d environments reveals a shrinking flower, and more greedy insistence.

solved.html... sort of, section container to the rescue

1. Guess I should add, already tried using absolute and relative units other than vm to size bg text, but that breaks the entire page's v-scale behavior. Vw is one greedy beast.
2. Also, when resizing page by dragging bottom right window corner, hr element's built-in center-alignment flakes (bg-color shifts down 1px to show background white strip). This bug in Word is shielded as page-view adjusts to maintain hr in spite of drag-displacement, but I doubt global hr bugginess has anything to do with vw's bg text woes - hr's just weird!
3. Another minor possibly related detail, that background text gets pushed about 1 or 2 vw's right or left of where it should be (?): re-size that layout using vh, vw, vmin or vmax and same general problems. As if today's browser logic treats v-scale like IE4-6 confused inline list layout in navigation, messing up li position and text size. Suspect DOM, we must. Changing font-family from sans-serif to default (serif) seems to swap displayed sentence string from right to left of it's stubborn left-aligned center. So that may be a further v-scale bug where typographic outline/block focus is corrupting styled/computed text-align center. Onerous to assume anything, but IE4-6 inline list mess was ultimately an outline issue... let's get back to 40vw that tends to 80vw (or was it the other way around) and center-align style that is ignored in standard block elements that other-wise would center text if vw wasn't around.
4. Okay, change shim conditional: <!--[if lt IE10]>]>thanks google>ARGH! Update your browser!<![endif]-->... but our v-sized background text issues continue. Help!