[css-page-floats] clearance

[frivoal]

Based on implementation and usage experience at Vivliostyle, we have found that the current css-page-floats clear property has the following problems:

• Can not clear page floats when specified on block-level elements
• The value syntax is too complex for most use cases (i.e., just 'clear: all' is needed for clearing page floats in most scenario), and not sufficient for other cases (not possible to clear only 'column' floats or 'page' floats).

We'd like to propose to change the definition of the 'clear' property in css-page-floats as follows:

• Change "To prevent stacking of floats, ..." to "To ensure that the element is positioned after earlier floats, ..."
• Define only the following values at this level: none | left | right | inline-start | inline-end | both | all
• Treat 'left' and 'right' values as line-left and line-right and map to always 'inline-start' or 'inline-end'.
• 'clear: all' clears all floats including block-start and block-end floats.

Clearing works by shifting an element down until its block-start edge is lower than the block-end edge of any float preceding it in document order, or by pushing it to the next fragmentainer if there's not enough room to shift down. (this should be phrased carefully, in order to not prevent float stacking from working).

It is understood that this will remove some possibilities, such as preventing the presence of more than 1 top float at the top of a page, but we think this can be handled in a later version of the specification, either with additional values to the clear property, or maybe preferably via the float-defer property.

[johanneswilm]

(not possible to clear only 'column' floats or 'page' floats).

@frivoal Isn't this given when taken in combination with the float reference? (See examples 7-10)

[johanneswilm]

Can not clear page floats when specified on block-level elements

Not sure what you mean by that. Maybe a problem of wording in the spec?

[frivoal]

Can not clear page floats when specified on block-level elements

Not sure what you mean by that. Maybe a problem of wording in the spec?

I meant we cannot make in-flow elements clear the floats.

[frivoal]

(not possible to clear only 'column' floats or 'page' floats).

@frivoal Isn't this given when taken in combination with the float reference? (See examples 7-10)

I guess this is primarily because the current spec uses clear to mean "push to the next fragmentainer", while we've found it would be more useful if it meant "shift down if possible, push to the next fragmentainer if not", like old-fashioned floats do.

Pushing to a subsequent fragmentainer even if there would be enough room seems more about deferring than about clearing. But I agree it's a bit of a gray zone.

[johanneswilm]

I guess this is primarily because the current spec uses clear to mean "push to the next fragmentainer", while we've found it would be more useful if it meant "shift down if possible, push to the next fragmentainer if not", like old-fashioned floats do.

@frivoal Ah, so you mean you have two top floats and you place the first one at line start and the second one next to it, unless you clear the second float?

Have you looked at 8.1 and 8.2 about float placement?

How would this work with column floats that are floating in the inline direction?

As we said during the meeting a while ago, the interpretation of what "clear" means will have to be different necessarily when we deal with 2 instead of 1 dimension. I guess this highlights the need to add 2 dimensions to all aspects of the spec, as we said during that meeting.

[johanneswilm]

That being said, if you have implemented something that works differently than the spec and that fullfills the needs of most users, then it may make more sense to change the spec to follow what you are doing rather than the other way round.

[frivoal]

live example

This is based on the suggested behavior above.

[frivoal]

Ah, so you mean you have two top floats and you place the first one at line start and the second one next to it, unless you clear the second float?

Yes. If you clear or if it doesn't fit next to the first one, it goes down. if it fits, it stays on the side

Have you looked at 8.1 and 8.2 about float placement?

Yes, adjustements will be needed.

How would this work with column floats that are floating in the inline direction?

The same. For now, this part is less use case driven, and more driven by consistency, but if the float fits next to the previous one, it stays there, and if it does not, or if there's clearance, it is pushed downwards (well, block-end-wards). Like top and bottom floats (with this change) and like old-fashioned floats.

That being said, if you have implemented something that works differently than the spec and that fullfills the needs of most users, then it may make more sense to change the spec to follow what you are doing rather than the other way round.

That's indeed what happened. We started from the spec logic, and as we tried to fullfil actual use cases from real projects, what we're proposing here turned out to me simpler / more effective.

[johanneswilm]

The same. For now, this part is less use case driven, and more driven by consistency, but if the float fits next to the previous one, it stays there, and if it does not, or if there's clearance, it is pushed downwards (well, block-end-wards). Like top and bottom floats (with this change) and like old-fashioned floats.

So you always stack in the inline direction and you always put floats that float in the block direction at inline start? I believe it was the need for either stacking in the inline or the block direction was the main reason that made us come to the conclusion that we needed to specify both dimensions.

Maybe we need to discuss whether this really is needed based on your implementation and experience with end users?

[johanneswilm]

How would this work with column floats that are floating in the inline direction?

The same. For now, this part is less use case driven, and more driven by consistency, but if the float fits next to the previous one, it stays there, and if it does not, or if there's clearance, it is pushed downwards (well, block-end-wards). Like top and bottom floats (with this change) and like old-fashioned floats.

What do you mean by "the same"? If you have two page floats that are both floating in the line-end direction within the same page and the first one is clearing "all", then the second one is going where?

And if you have two that float to the block end and you clear the first one, does that then move that first one upward or does it move the second one to the next page?

[johanneswilm]

After looking at PrinceXML, it seems they don't really use clear for page floats at all. In the inline direction, they only allow one page float and the remaining part of the line remains blank. That is one option, but that then means 1 dimensional floats.

If we want to have 2D floats, I don't quite get how this will work.