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

> On Nov 6, 2015, at 10:26 AM, Johannes Wilm <johannes@fiduswriter.org> wrote:
> 
> 
> 
>> On Fri, Nov 6, 2015 at 6:39 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> 
>> 
>> On Nov 6, 2015, at 2:33 AM, Johannes Wilm <johannes@fiduswriter.org> wrote:
>> 
>>>> This seems complicated and unnecessary to me, and breaks the normal expectations of horizontal coming first when two values represent two axes (X and Y, horizontal and vertical). And it is way too subtle to expect authors to easily figure out that this ordering is significant to float stacking. 
>>> 
>>> Well, floats are a complex thing, and we are trying to get it right rather than provide a lot of features that will just end in content breaking for no good reason.
>> 
>> My proposal keeps most of the complexity confined to what we already have in inline floats, and vastly limits the vertical and block direction effects to something much simpler than that. They just move the float to the beginning of a different line box (or to the end of the line box if it's 'bottom', I guess, probably), and turn it into a block. 
> 
> 
> The part that I haven't figured out about your proposal is the recipe for stacking the floats and which fragment to place them in (deferring).

OK, I don't really have built in vertical stacking with text wrapping around it, as such. That is where I was suggesting a separate property in the future to handle that as a switch. However, I think an author should be able simulate it anyway. So, to get floats stacked along the right side, do something like this:

article-content {
    width: 80%;
    float: left top;
}
sibling-floaters {
    width: 20%;
    float: right top;
}   

...which you can pretty much do anyway without 'top'. But I would keep 'float-defer' and 'float-reference' (as long as the initial value was 'float-reference: containing-block' or whatever we call it). I don't think my proposal is incompatible with those. 

So you could also have an absolutely positioned side bar to float-defer floats into, which would get you a stack of floats along the side of the page, with nothing under them. That would just combine 'float: top' with your 'float-defer' value to float it into the top line-box of that sidebar. 

> I think we have both of those points figured out pretty well in the current proposal, although I am waiting for feedback from Toru Kawakubo, who is trying to implement it in Vivliostyle and may find problems with this proposal.
> 
> 
> But I do accept the criticism that essentially restricting authors to float to 2 of 4 corners will seem arbitrary and cannot easily be communicated to authors. I think we can keep the current strategy for placing floats in specific fragments and figuring out whether a specific fragment is "full", while still providing the ability to float along the other axis secondarily. That's what i tried to propose this morning [1].

Yeah, that just seemed more complicated and less clear, for what I imagine to be a less common use case. 

> 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. 

> 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. 

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's why I/we have spent the last few months trying to figure out how to do this.
>> 
>> And thank you for that. There is a lot to like, and it is an excellent start that got me thinking deeper about vertical floats. I'm sorry I didn't respond to it earlier. 
> 
> [1] https://lists.w3.org/Archives/Public/www-style/2015Nov/0101.html
> 
> -- 
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org