- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 14 Dec 2015 17:23:47 -0800
- 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