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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Johannes Wilm-3
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.
Reply | Threaded
Open this post in threaded view
|

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

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

On Wed, Jun 22, 2016 at 6:30 PM, Johannes Wilm <[hidden email]> 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.