- From: Peter Sorotokin <psorotok@adobe.com>
- Date: Wed, 11 Oct 2006 13:07:31 -0700
- To: "Joe Wells" <sllewbj@blueyonder.co.uk>
- Cc: <www-style@w3.org>
> > -----Original Message----- > From: Joe Wells [mailto:sllewbj@blueyonder.co.uk] > Sent: Wednesday, October 11, 2006 12:23 PM > To: Peter Sorotokin > Cc: www-style@w3.org > Subject: Re: floats vs. page breaks > > "Peter Sorotokin" <psorotok@adobe.com> writes: > > > I have faced the same problem and in my CSS implementation if a > > float overflows, it takes all the content that follows it with > > it. Doing it this way solves this problem, but it makes > > illustrations cause undesirable overflow of the text. > > Unfortunately, it doesn't solve the problem in general because CSS is > an open standard and other people are allowed to implement it also. > :-) Certainly. I have not seen a solution that would handle it, unfortunately. > > So the behavior can vary where the standard allows freedom. And it > seems the behavior I'm seeing is a very legitimate (and probably > usually desirable) choice. > > > I think that there should be a property that specifies if a piece of > > content should be "postponed" until it can fit on the page entirely, > > even though the content that follows it can still take up the rest of > > the page. This is useful for things like tables and illustrations in > > general - no matter if they are floats or just regular blocks. The > > property could take three values - if this postponing should be allowed, > > disallowed or up to the user agent (as it is implemented today). > > > > Without such property, I do not think there is a way to do that. > > The control you are asking for is (in theory, if not in actual > implementations so far) already present for normally flowed content in > the form of the "page-break-inside: avoid" property setting. I don't > think it will be useful in this case because floats are allowed to > escape. No, page-break-inside merely suggests that the block is not broken. It says nothing about the content that goes after it. The control that I propose would work like this: if the element to which it is applied fits on the current page, it would have no effect. If it does not fit, the element is not rendered on the current page at all (as if display was set to "none"). Instead the element is rendered on the next page before any regular content. This is effectively what Konqueror does today with floats, but the usefulness of such feature would not be limited to floats only and it would be nice if an author had a say on enabling or disabling such behavior. Peter > > I think the real problem is that the only way to get text wrapped > around a shape is to use floats. Floats however have that name > because they are supposed to _float_, i.e., to move as needed until a > good space is found to put them. What is needed here is the > text-wrapping feature _without_ the floating feature. > > -- > Joe [snip]
Received on Wednesday, 11 October 2006 20:07:48 UTC