Re: [css-page-floats] Options for floating without iterative reflow

On Tue, Dec 15, 2015 at 2:23 AM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> In the page floats informal meeting today, the big problem we came
> back to was that it's easy to accidentally design something that
> either doesn't work in complicated cases, or works but is very
> expensive in complicated cases.  Exclusions give an example of this -
> if you don't reflow and reposition, you'll often get "later"
> exclusions positioned wrong; if you do reflow and reposition, you redo
> layout multiple times, which is really expensive.
>
> One way around this is to limit page floats to things that can be done
> cheaply and accurately, giving you correct results without having to
> relayout already-laid-out things.  Here's an incomplete list of some
> behaviors that satisfy this limit:
>
> 1. Float to the top of the first fragment, so you can gather all the
> "front" floats at the beginning of layout, layout and position them,
> then flow the rest of the content around them.  Or float to the
> "back", placed at the end of the last fragment - you flow everything
> else, and then just put the floats at the end.
>
> 2. Float to the end of the current fragment. You can do layout only to
> the line that the placeholder lives on, then add the float and flow
> following content around.  There are a few alternatives for what to do
> if there's not enough free space left in the fragment - we can move it
> to the next fragment, or move lines from the bottom to the next
> fragment, or do both.  Preferred behavior here depends on use-case, I
> think - pictures can move to next fragment and just keep flowing
> content, footnotes need to move and pull their placeholder's line with
> them, etc.
>


The current model doesn't cover footnotes-as-bottom-floats, as it was
assumed they need a more complex and different model, among other things to
ensure that the anchor and the footnote are in the same fragment. This can
get quite complex if you have, for example, 8 footnotes right after
oneanother (no space inbetween), but there is only space enough for four of
the footnotes on the current page.

I believe footnotes are currently described as a type of regions.

Always deferring all page-floats at least one fragment unless it is placed
at the very top of a page would sound like an OK compromise to me if that
means being faster. Authors don't currently have precise control over the
fragment where things are placed anyway. But the main use case I am
thinking of is things like books with 325 pages, where 1 page/column
doesn't really make a big difference.

As I understand it, one would still have to do float placement and flow
layouting simultaneously.


The page float spec also still includes the ability to use a negative defer
value which may place the float in a fragment that is prior to the one
where the anchor is. And because that negative is counted from the end of
all the fragments, we need to know how many fragments there will be in
total to place it. I guess the ability to make the float-defer be negative
should then also be eliminated. I think that would be OK.


> 3. Float to a position in a specific fragment, like "top left of the
> second column".  Like "float to front", this can be preprocessed and
> then flowed around.  It's terrible for content that can be flowed
> arbitrarily, though - you do *not* want to try to position a book's
> illustrations by guessing which page they should go on.  However, it's
> *ideal* for reasonably fixed layouts where the floats are more
> "decorative" and don't have a strict connection to a particular piece
> of content - seems reasonable to prefer one image per column, rather
> than some columns having two and some having none, or something like
> that.
>
> 4. Require that floats take up the entire inline-width of the
> fragment, or otherwise exclude lineboxes from flowing around them.
> This means all you need to do is shift lineboxes to accommodate the
> floats, which is cheap and not "real" layout.
>
> Is there anything else?
>
> ~TJ
>
>


-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org