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

Brad Kemper
> On Nov 6, 2015, at 12:15 PM, Johannes Wilm <johannes@fiduswriter.org> wrote:
> 
> 
> 
>>> On Fri, Nov 6, 2015 at 8:43 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>>> 
>>> 
>>> 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. 
> 
> This looks close to what I started out with. But then I started to factor in stacking, deferring, etc. . 
> 
> If you have two floats that go to the left and one that goes to the right, and all three floats have height: 100% then I have a hard time seeing how that would work, if on other pages you also need to provide two top floats stacking underneath one another.

I'm not following. Why do they all have to be 100% height?

> The current proposal takes care of all that.
> 
>  
>> 
>> 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 it's fairly easily explained. And the second direction can be optional. If it is not given, it is simply line-start for block-start and vice-versa. 
> 
> More importantly though, it gives us most 2D options, while still not breaking when you have several within a fragment and we can use the recipe for stackign and deferring that we currently have.
> 
> 
> 
>  
>>> 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. 

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

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

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

> maybe it would make sense to try to define that as an extension of existing floats.

Maybe with the word "Floats" in the title? One might reasonable expect something called "CSS Page Floats" to be an extension of existing floats.

> Or oen could just say that we do all the new exclusion-alike things on top of the exclusions spec to be consistent. Not sure.

Or a spec called "Level 2 Floats and Exclusions". 

>  
>>>  
>>>> 
>>>>> 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
> 
> 
> 
> -- 
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org