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

> On Nov 6, 2015, at 11:49 AM, Johannes Wilm <johannes@fiduswriter.org> wrote:
> 
> 
> 
>> On Fri, Nov 6, 2015 at 7:51 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> 
>> 
>> 
>> 
>> 
>> Brad Kemper
>> On Nov 6, 2015, at 10:09 AM, Johannes Wilm <johannes@fiduswriter.org> wrote:
>> 
>>> 
>>> 
>>>> On Fri, Nov 6, 2015 at 6:13 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>>>> 
>>>> 
>>>>> On Nov 6, 2015, at 8:26 AM, Johannes Wilm <johannes@fiduswriter.org> wrote:
>>>>> 
>>>>> Ok, maybe I misunderstood. So "float: none top" will behave the same as "float: left top"? And "float: none bottom" will behave the same as "float: right bottom"?
>>>>> 
>>>> 
>>>> I really feel that you only read the bottom half of my earlier email. I explained all this in detail, including those two specifically in the very first part, and reading it is almost certainly going to be faster than how long it took me to type it on my phone. 
>>> 
>>> I have really read your emails. I promise. :)
>>>  
>>>> 
>>>> The short answer is that "float: none top" means you are moving it to the top line and blockifying it, but not floating to the left or right. So the text (and other floats) starts under it. "float: left top" means you are also floating to the left. So the text (and other floats) starts to the right of it. 
>>> 
>>> Ok, so by specifying "none" you are making the page float stop being an Exclusion. Other than that it behaves like "float: left top". 
>>> 
>>> Given that page floats are exclusions,
>> 
>> Well, that brings up another point. The exclusions spec says that exclusions only work on non-floats. My proposal is NOT making them exclusions. It is keeping the left/right part as-is, and for block floating only moving them to one end of a different line box (and making it a block if there is no right or left floating). 
> 
> 
> Yes, but with floats they mean today's existing inline floats. Those behave like they do for historic reasons. But when we create something entirely new that will behave differently than inline floats anyway, I agree with Rossen, that there is no point in recreating what Exclusions already do.
> 
> Exclusions seem to provide us with everything we need. Authors who know exclusions will be able to handle page floats with ease, instead of havign to learn entirely new new strategies to make certain things happen (such as doing "wrap-flow: clear" ).
>  
>> 
>>> a more intuitive way (it would seem to me) of achieving that same result would be to do "float: left top" and "wrap-flow: clear" (that is how you would do it for exclusions, correct?).
>> 
>> To me, it is simpler and more intuitive to keep them as normal floats, since it is the float property we are talking about.
> 
> Well, yes we use the property name. And that's why I have been thinking that maybe we should not do that. However, the feedback so far from other people in and around the CSSWG has been to keep the name and with that the property.
>  
>> It seems more complicated to create a dependency on exclusions, which may or may not work differently than floats for left and right. I'm less familiar with exclusions. Even if they are meant to be a super-class of floats (are they?), it seems odd to use 'wrap-flow: clear' when I haven't 'wrap-flow' at all, just 'float'. I'd rather keep floats self contained, without leaking in properties and dependencies from other drafts-in-progress. 
> 
> Inline floats continue to be as they are.

Not according to your spec, and what you have said about exclusions. You are redefining what 'float:left' and 'float:right' mean, so that they are no longer floats; they are exclusions. It says that 'left' is the same as inline-start or inline-end when it has the initial float-reference of 'inline'. inline-start or inline-end don't say anything about them not being exclusions. 

Section 6 says that [all] floats have their wrap-flow set to 'both' initially. That is definitely different from existing float:left. It will break existing layouts. There is nothing that says any of the new float properties don't apply to inline floats (though section 9 does contradict section 6's statement). 

Are some float properties not supposed to apply to inline? It seems like 'float-offset' could apply, 'float-defer' could theoretically work if the inline float happened to exist within a region chain or multi-col. Snapping could be useful in a single fragment environment. But all the examples only show other float-references, and you say "Inline floats continue to be as they are". 

If page floats are actually exclusions, do properties like 'float-offset' affect all exclusions, or only non-inline "floats"? What happens if I try to absolutely position something that is page floated? Does it become a "regular" exclusion, and does that cause some of the float properties to no longer apply? Does creating a page float change the computed value of 'wrap-flow' (it seems like it). Does changing 'wrap-flow' to 'auto' turn off page floats? 

I find it utterly bizarre that some float values other than 'none' can make it a non-float, and have it ignore all the 2.1 rules about floats, while an entirely new and different set of rules are substituted. This is a big problem, to me. 


> I don't think anyone is planning on touching them. Page floats are a slightly different animal. Then there is the third thing which has come up a few times which is basically "page floats that float into the four corners of a non-fragmenting block element".

Yeah, the restriction against that is bizarre to me too. If I want to float something to the top of its container, I have to hack the container into being a region?

.container {
     flow-into: me content;
     flow-from: me;
     /* now I can float a child to the top of this */
}

>> 
>> I'm not opposed to also allowing float-reference, float-defer, etc. from affecting other exclusions, I guess, but I think it would maybe need a different name (float-or-exclusion-reference?). 
> 
> I am not sure I can follow you there. Exclusions that the user places manually that are not page floats are not affected by page float placement, as far as I know.

Well that isn't mentioned in the spec. 

But what I meant was: The spec says page floats are exclusions. If the new properties were moved into Exclusions, and stopped pretending to be real floats, then they would need to be renamed. But many of them would be useful to regular floats too. So the name should be neutral to work with real floats AND exclusions, and it should say how it affects each. 

> 
>  
>> 
>>> 
>>>>> If they are the same, then why do we have the "none" at all?
>>>>> 
>>>> 
>>>> They are not the same. The first value of 'none' or 'left' are not the same for existing 'float: left' or 'float: right'. I'm not changing that. The blockifying already happens with that, along with shrink-to-fit width. 
>>>> 
>>>> For 'float: none top', I'm keeping the blockification, but not the shrink-to-fit width. shrink-to-fit width would only be for left/right values other than none. 
>>>> 
>>>> If you have 'width:100%; box-sizing: border-box;' they would look about the same, aside from maybe how vertical margins collapse or something. 
>>> 
>>> 
>>> -- 
>>> Johannes Wilm
>>> Fidus Writer
>>> http://www.fiduswriter.org
> 
> 
> 
> -- 
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org