W3C home > Mailing lists > Public > www-style@w3.org > December 2015

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 14 Dec 2015 17:23:47 -0800
Message-ID: <CAAWBYDAMxE_=qm9wVK56EfLtm1mXikx1yOyJOLRS53444rE=rA@mail.gmail.com>
To: www-style list <www-style@w3.org>
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.

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
Received on Tuesday, 15 December 2015 01:24:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:59 UTC