Re: [css-logical-properties] the 'inline-{start,end}' values for 'float' and 'clear'

> On Nov 6, 2015, at 2:54 AM, Johannes Wilm <johannes@fiduswriter.org> wrote:
> 
>  
>> -- 'float: bottom' = 'float: none bottom ' (no left or right mentioned, so no left or right floating).
>> 
>> -- 'float: left' = 'float: left none' (no top or bottom mentioned, so no top or bottom floating, matches existing).
>> 
>> -- 'float: right' = 'float: right none' (no top or bottom mentioned, so no top or bottom floating, matches existing).
> 
> 
> I think page floats will have to behave quite differently than inline floats here. If one floats to the top, one expects the float to cover the entire top, not to land at some arbiotrary place in the inline direction. Same if one wants to float to the right or left of a column/page/region.
>  
>> 
>> ------------------
>> If you accept that, and that the logical values should be in the spots equivalent to Western style writing (left to right, top to bottom), then the order of logical equivalents should be 'inline' then 'block'. So 'float: start none' would be the same as 'float: left none' (for me), which is 'float: left'. Very logical logical, to me.
> 
> As mentioned in my earlier emails, this will not do it. It creates problems for stacking.

The part of my email that you are quoting is about how in this two value property (horizontal and vertical) a single value is actually just hiding the initial second value of 'none' for vertical, and how to make the logical versions consistent with that. I fail to see how to translate single values into double values creates stacking problems. 

>> So single word logical equivalents would be:
>> 
>> -- 'float: start' = 'float: start none'
>> 
>> -- 'float: end' = 'float: end none'
>> 
>> Both of those are useful for the simple case of inline floating. For block floating, just use the 2 word version. E.g., 'float: none start', not 'float: block-start', and 'float: start start', not 'float: line-start block-start'.
> 
> inline floating only works along a single axis. The "page floats" that do float along two axis will need to be able to specify if the top or the left is prioritized.

Again, not so with my proposal.   The mechanics of inline floating is unchanged, and block direction "floating" is really just moving it to a different line box. There is no prioritization needed, vertically you are not doing anything similar to inline floating (unless you also provide a non-none value for inline floating). 

If you really want to go further and provide a way for floats to stack up underneath each other along the right or left sides (and logical versions of that), then this could be handled by a separate property that we don't need to include now. 

> A syntax such as "float: start end" is not working for that.

Only because I don't think vertical stacking is a must-have for the first level, and that when we do add it, it should be through a separate property that is much more clear than what you proposed. 

>> ----
>> Vertical float clearing only matters if you have multiple fragments.
> 
> 
> That's the conclusion I had with page floats, which is why the float reference for all but inline floats only can some kind of fragment.

The lack of utility of vertical clearing when there is only a single fragment does not negate the utility of floating within that single fragment. It just isn't necessary, is all, until you go to print the page or let it overflow into regions. 

> Putting the images to the top of a conventional DIV, etc. can also be achieved in other ways.

Not with the same benefits. 

I really don't understand why we should have to have this unnecessary restriction. It is useful to have this within a single fragment of the containing block. It would be even more useful to be able to specify any ancestor as the float reference, but I can wait for that feature. 

> However, the feedback I have received so far indicates that people would also like to float in the block direction in block elements.

Me too, but with much simpler mechanics of what that really means. 

> They will just lose a lot of features related to deferring floats, etc.

With what I have proposed, they would not lose deferring. I don't know where you get that. I was only discussing the top, bottom, and block direction values of 'float' and what they would do.