Re: [css-page-floats] [css-logical-properties] state of logical directions in relation to floats

Moved to github for discussion:
https://github.com/w3c/csswg-drafts/issues/220

On Wed, Jun 22, 2016 at 6:30 PM, Johannes Wilm <johanneswilm@vivliostyle.com
> wrote:

> Hey,
> it has been a while so I have been looking at what i could find of
> communication on this. The following is my understanding of the situation:
>
> Page floats are currently defined as moving only in one direction
> (inline-start/end or block-start/end). For this reason the direction had to
> be specified saying whether it should either be the inline or the block
> direction the float went in.
>
> Through the discussion about this, and various people pointing out how
> this would be problematic, I came to agree with those critics of the
> current draft such as Tab, who held that page floats really always need to
> be two-dimensional: they need to go to one of the four corners of the
> fragmentainer they are in, and there is not any sense in only having page
> floats be able to float in two of the possible four corners.
>
> If the spec is changed accordingly, this should no longer be an issue as
> both directions will need to be specified.
>
> So it can either be A)  that we use "float: start start" where the first
> "start" is the block direction and the second is the inline direction, or
> B) we can use "float: block-start inline-start" in which case the order
> doesn't matter. We can also agree a shorthand for case A, if only one
> direction is mentioned, that "start" stands for "start start" and "end"
> stands for "end end". I do not have an opinion on whether A or B is better.
>
> It has been a while, so my understanding of the state of the dicsussion
> may be somewhat incorrect, but if I'm not mistaken we seemed to be close to
> a consensus on this. Brad Kemper seemed to maintain a more general
> criticism of  defining page floats in terms of exclusions and I think he
> wanted to possibly write an alternative spec in which he wanted to expand
> the current inline floats to be able to float in two directions (?), but if
> I'm not mistaken, the issue of inline-start/end was not part of that
> disagreement.
>