Without having done more than glance at your reasoning, I believe it’s all made moot by the css3 Flexible Box Layout Module.
The Gecko and Webkit engines already support this module. Use the proprietary test prefixes, -moz- and -webkit- for the new properties. h/t to dresden_phoenix.
cheers,
gary
h/t?
Hat tip (h/t) I suspect.
Yes I mentioned that in post #6 and if it works as well as expected it will solve a lot of the problems.
It doesn’t seem as though there will be support in IE9 though which is a shame.
Ack, sorry about that, Paul. That was more than a fortnight ago, and I’ve slept since then. 
So a belated tip o’ the hat to you, also.
Too bad about IE9b. I tried it by adding the -ms- prefix. No joy.
cheers,
gary
Yes, the flexible box has been brought in discussion. One thing I see and it’s kind of out of place:
The ‘float’ and ‘clear’ properties do not apply to children of box elements, so the used value for these properties is ‘none’. These properties do apply to the box itself if it is not a child of another box.
If you think about it, it’s reasonable. The children of a box have specific positioning methods that exclude floats by their nature. No floats, no possibility of clearing. The parent box has its own block formatting context, so clearing doesn’t extend beyond its own self.
The parent box can be float, and can clear floats as long as it is not, itself, the child of a block.
cheers,
gary
Probably. But my point was about being restrictive. It’s a feature removal.
In what way?
cheers,
gary
Regarding floating. It’s about the lack of backward compatibility. If you define <body> as a box, you can’t have child floating elements as you see now in most of the layouts.
This CSS3 attempt it’s really more of an experiment. And seeing that specs mature in decades, experiments will never mature web dev. It should be as it is in Java AWT: the CSS specs should define layout managers rather than box models. After so many years, the specs still try to accommodate HTML for CSS. The specs should tailor CSS for presentation in general, not for some specific HTML markup patterns, a couple of so called “common templates”. <header>, <nav>, these are BAD solutions.
That way many CSS problems would be solved: implementing general solutions, not seeking out dabbler innovations. Yes, web dev can be targeted by amateurs, but web dev specs should be professionally though of. And the specs implementation (like it is the case with what this thread is about: a % to px transformation in a correct manner) also should “suffer” from professionalism and consistency.
One thing I forgot: XML Islands. One of my biggest perplexities: why aren’t those elements never taken seriously. I mean, you have XML processors, XML stylesheets, AJAX technologies, but UAs and specs decided to ditch <xml> element? Giving us… <nav>?