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

> On Nov 6, 2015, at 10:42 PM, Johannes Wilm <johannes@fiduswriter.org> wrote:
>>> 
>>>>> I think one problem may be the name. "page floats" suggests they behave much like our current inline floats. At one stage I was wondering if we should simply change the name entirely to make it clear that page floats behave differently and have a different meaning in many ways.
>>>> 
>>>> That's where we diverge philosophically. I want floats to be floats, but left them start at the top or bottom of their block container (or some other container), instead of only starting on the line box they originated from. That seems way simpler to me, and probably easier to implement by using existing float code. I don't think adding new values to 'float' should make it into an entirety different animal, especially if we have to then explain how the 'left' and 'right' values possibly behave differently than before whenever you also move the float to the top or bottom. 
>>> 
>>> 
>>> I can see our philosophical difference there.
>>> 
>>>  
>>>> 
>>>>> Also the relation to Exclusions wasn't clear initially. When I started on this, one of the first questions other people in the CSSWG came with was whether this was going to be some kind of alternative proposal to CSS Exclusions. 
>>>>> 
>>>>> Which it is not supposed to be. It's merely a way of placing exclusions in relation to a fragment series. We already have exclusions, so there is no need to redo the part about page floats that can evenly well be explained be handled by letting them be exclusions.
>>>> 
>>>> But floats are not exclusions, and exclusions are not floats. Exclusions don't have collision avoidance, their scope is different, they aren't part of the inline flow or connected to line boxes, and they can be positioned without becoming non-floats. Something that only applies to exclusions while loosing all uniquely float-like behavior should not be part of the 'float' property, they should be part of the Exclusions spec. 
>>> 
>>> 
>>> Well, page floats, as currently defined, are exclusions that are positioned in a specific way. Exclusions are not page floats though.
>>> 
>>> Exclusions are not about placement or collision avoidance. It therefore makes sense not to have this in the exclusions spec, but rather to depend on it and not redefine everything from scratch.
>> 
>> If it is only a special kind of exclusion, it should be in the exclusion spec, and 'float' should not contain properties that create exclusions masquerading as floats. I would protest that. 
> 
> 
> I think we just have to accept that we disagree on that point. One could also say that "floats change the display property of elements, ergo floats should be put into a spec together with the display property".

That's more of a side effect than what we're talking about here, which is having a 'float' value in a 'float' spec that creates exclusions. Exclusions are a whole separate alternate to floats. It is more like saying extensions to grid should not be done with a new value to 'table' in a spec called 'tables'. Unless you were going to be more explicit about it being grid, with something like 'table-layout: grid'. 

I would have less of an objection if you had 'float-behavior: exclusions' or something, which would allow exclusion wrapping in both direction, while allowing something more like my proposal when it was 'float-behavior: floats' or something. 

>>> But if many more think that page floats should be named something else, then I would find that ok.
>>>  
>>> From my perspective: Today's inline floats, seem to be less than perfect, especially when it comes to stacking.
>> 
>> Sure. But many authors have a lot of experience and expectations with them. Their behavior is familiar and well used. 
> 
> And those floats can only move along one axis in the current block formatting context.

If that is the important thing now, and my suggested work-around isn't enough, then I have already offered a solution: a new property to switch the floating axis. It could be 'float-axis: vertical | horizontal | inline | block'. 

'float-axis: vertical' would cause the next floater of the same horizontal 'float' value to move down to a line box that did not yet have other floats of the same value on it, while still allowing text and inlines to wrap around specified side of the previous floats and itself. That would stack all the left floats along the left, and all the right floats along the right.

This could be combined with 'float:left top' to move the first such float to the left end of the top line box, and the second one to the first line box that fit under that, and so on.

'float-axis: vertical; float:left bottom' would move the first such float to the left end of the bottom line box. The second one like that would move the first one up enough so that it the second one would fit under it, and so on. Overflow or fragmenting would occur if there wasn't space due to previous non-bottom floats blocking the earlier bottom floats from going higher. 

> There is no float-reference,

Sure there is. I don't know why you keep saying that. It is only the initial value that would be 'containing-block' or 'bfc' or whatever. 

> no 2D floating,

Huh? I have been proposing a 2-value system from the beginning. 

> no deferring,

Again, this is not what I proposed. The only non-deferring would be if there were no more fragments. If there were fragments, even if they weren't the same fragment chain as the float-reference, then you could defer.

> no complex relation to the float anchor, etc. .

Not sure what you mean here, but lack of complexity is a virtue, not a fault. My proposal solves all the use cases now, simply.

> In short: they are not the  same and noone can know how to use page floats just from having using right/left floats, no matter how you define them.

My proposal adds a few simple things to what people know about floats. Yours forces them to switch to a whole different system that acts differently in fundamental ways. 

>>> But I understand that this is not something we can do anything about, because so much content exists that depends on them being like they are. I just think that for something new, we should not let us lock down by that.
>> 
>> I think that whether you use floats or exclusions, you should have the ability to move it to the top or bottom or corners, and then have behave in predictable, easy to understand ways. My proposal does this with floats, in a very simple but valuable way. 
> 
> An alternative proposal would probably need to address stacking and deferring.

Done, at least in broad strokes. See above.

> There not to be concrete rules how to handle these, as the current proposal has, so that output is predictable for authors.

OK. That could take some time, I guess, but I wouldn't want to spend the time unless there was some chance of it moving forward. 

> Just saying that something floats to the top left will work for one single float, but doesn't give us enough information once we have more floats.

What else do you want to know? I think it is pretty simple and straightforward for that example.

> We would need to be able to do at least what we can do with the current proposal in terms of page designs: we need to be able to stack horizontally on some pages and vertical on others.

I have presented a recipe for that in a previous post, and now have proposed a new property to make it more straightforward. 

>>>> And btw, I am not against having a way of placing exclusions in relation to a fragment series too. But I also want that as a capability of real floats, and to have a way to move a real float to the top or bottom. 
>>> 
>>> That would be the third type of float. As mentioned, it would not be able to make sue of deferring and the clear property...
>> 
>> Why not? An inline float can be in a fragment chain. 
> 
> I am talking about floats with flat references to a single block element.

If there are no fragments, then deferring doesn't even make sense. If there are, it does, and I allow for that in my proposal.