W3C home > Mailing lists > Public > www-style@w3.org > January 2008

Re: Advanced Floats

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Sun, 06 Jan 2008 12:04:45 -0800
Message-ID: <4781345D.6010705@terrainformatica.com>
To: David Woolley <forums@david-woolley.me.uk>
CC: www-style@w3.org

David Woolley wrote:
> Brad Kemper wrote:
>> Are iterative balancing algorithms difficult to write? Or do they slow 
>> the browser to a crawl or something? 
> They imply that the page cannot be incrementally rendered, which is 
> considered an undesirable, although not forbidden, characteristic for 
> new CSS features.

I am not sure of what is that "iterative balancing algorithm" here,
and why it cannot be incrementally rendered but I would like you to 
consider algorithm that I use for flex length units computation:

Consider this markup:

   <header />
   <body height=*>....</body>
   <footer />

This markup/styling means:
<header> - on the top of root
<footer> - on the bottom of root as:
<body> - takes rest that left from <header> and <footer> in the <root> 
or it gets intrinsic height if there is no free space left in
the <root>.

Computation is simple:

Phase 1: Do layout as if all flex values defined as having 0 value.
          (standard layout algorithm)
Phase 2: If height of content inside the <root> is less than
          its height (so we get free space to distribute) do
          "shrink-to-fit" balancing.

This algorithm works as good for incremental rendering as
a standard layout algorithm.

Phase 2 ("shrink-to-fit" phase) is in effect only
when measured size of delivered content is less than
the view. At the moment when content of the document
exceeds view height then it stops shrinking.

> They are also a cost every time the window is resized.

Yes it is additional pass (phase 2) but a) it is
conditional and b) all modern UAs already have effective algorithms
in place for such balancing.

Load this page in your favorite UA:


as you may see it does "shrink-to-fit" pretty effectively.

Andrew Fedoniouk.

Received on Sunday, 6 January 2008 20:04:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:33 UTC