I believe Hitch's comment is about two images in a row or even x images in a row with only a small amount of text or none in between. Then when you try and delay the image you encounter, not more text, but another image. This can then stack up so that you have many images waiting to print until you have enough text to complete the page.
This is potentially an interesting issue but of course the user should be smart enough not to set up this kind of scenario since they have control over the CSS for each and every image. The latest CSS specification linked to in this thread has a different approach in that there is a block of data that has text and potentially one or more images. This approach limit the problem by only push the image around within the block. The user controls how much text and images in the block so thus control and disallows the stack of image to back up ad infintum.
Wolf thought that tables should be exempted since the size of the table is related to the font size. I think an algorithm can take this into account so long as the total block is the only area for the float table. The table can be made to start at the top of a page if it doesn't fit but, of course, after that it might overflow the new page if it is too big. I think this is an acceptable result. The idea starting it delayed to the top of the page is the best that can be done. If it gets too big it gets too big. The same can be true of a paper book that won't fit on one page.
I like the idea of permitting the object to be pushed both ways, to the bottom of the current page by shoving text later and the top of the next page by shoving text earlier. The CSS solution allows for this as well.
I think this could be a useful tool for conscientious eBook makers but it could be misused.
Dale
Dale
|