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

Re: [css-page-floats] order of page float placement

From: Johannes Wilm <mail@johanneswilm.org>
Date: Mon, 27 Jul 2015 12:32:10 +0300
Message-ID: <CABkgm-TxUmM4YkuOtw3jT6t39Z6xWY010c5BXHu6HzfYubJ4aw@mail.gmail.com>
To: www-style list <www-style@w3.org>, public-ppl@w3.org, Rossen.Atanassov@microsoft.com, Alan Stearns <stearns@adobe.com>, Florian Rivoal <florian@rivoal.net>, Shinyu Murakami <murakami@vivliostyle.com>
Another question: Float need to be placed in a specific order in order to
give predictable results. The question is what order that should be.

Easy to formulate would be:

A) The order they appear in in the DOM.

B) Page floats with float references at a higher level in the DOM are
placed before those at a lower level. Page floats whose float references
are not descendants of one-another are placed in the order they appear in
the DOM.

C) First page floats are placed in the order they appear in the DOM, then
column/region floats are placed in the order they appear in the DOM.


The spec currently specifies behavior C. It originally said A, which could
have the effect that top page floats would be floated underneath top column
floats if they appeared later in the DOM.

B would be even better, but also a lot more complex, as region fragments
can be descendants of different regions and columns, so one couldn't
determine a clear hierarchical relation between them.

C seems to take care of the most obvious problem of page/column floats, but
I am not sure if this is good enough for columns/regions that are
descendants of oneanother.

On Sun, Jul 26, 2015 at 11:25 PM, Johannes Wilm <mail@johanneswilm.org>
wrote:

> Hey again,
>
> there are some questions related to page floats [1] that I would like to
> hear some other people on.
>
> 1. Page floats are currently defined to work on columns, regions and pages
> -- anything that is fragmented. At the New York F2F there were some in the
> break asking whether they shouldn't also be able to work on any other
> element. The question is: Do we want that? And if  we do, what does a page
> float in that case? Is it not just the same as an absolutely placed
> exclusion that is placed so it doesn't overlap with any other page float in
> that same float reference container?
>
> 2. Do we need to allow floats that go both in inline and block directions
> within the same fragment? Pro: one can make really complicated layouts,
> con: The rules that are used to determine where the where exactly each
> float will be placed will be somewhat more complex. The current draft does
> not allow some floats going up and others going right in the same fragment.
>
> 3. Do we need page floats to be able to go in two directions
> simultaneously (up and right)? Currently we don't allow that.
>
>
> [1] https://drafts.csswg.org/css-page-floats/
> --
> Johannes Wilm
> http://www.johanneswilm.org
> tel: +1 (520) 399 8880
>



-- 
Johannes Wilm
http://www.johanneswilm.org
tel: +1 (520) 399 8880
Received on Monday, 27 July 2015 09:32:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:32 UTC