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

On Nov 8, 2015, at 6:10 AM, Johannes Wilm <johannes@fiduswriter.org> wrote:
> 
> 
> 
>> On Sun, Nov 8, 2015 at 10:23 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> On Nov 7, 2015, at 10:20 AM, Johannes Wilm <johannes@fiduswriter.org> wrote:
>> 
>>>> So apparently traditional floats can be involved with these properties somewhat, though it isn't clear to what extent. Does floating an inline float to a column turn it into an exclusion?
>>> 
>>> Inline floats stay inline floats. They don't change. They behave as they do now.
>>> 
>>> Floats with a float reference of a column are not inline floats. They are page floats. 
>> 
>> OK, I wasn't getting that. It is explained pretty subtly for such a major thing. Now I see that what you've been calling 'inline floats' in your emails are those with 'float-reference:inline', not just those with 'float: inline-left' and 'float: inline-right' (or the physical versions). 
> 
> Did you read the first few paragraphs of the specification? They should make it pretty clear. 

Of course I did. It didn't. The overview mentions "whether a float floats to align with a float reference inline box...", but doesn't define that as "inline float". There is an "Issue 1" that mentions "inline floats and page floats", but doesn't define either. It seems to assume that I know what these mean, but it never clears it up. Turns out, my own assumption about what it meant by "inline floats" was incorrect. We could have saved a lot of noise if that had been more clear in both the overview and the normative text.

The abstract starts with "This document describes floats that move to the top or bottom of content passages". But "floats" is a term defined in CSS 2.1, so that doesn't help.

> As for the name: "page floats" is the name it originally had before I started editing it. The first issue in the spec is about that it should probably be changed.

I don't see how there is any "probably" about it. Pages are only one third of the things these things are positioned within with the 'float-reference' property. Continuing to call them page float just doesn't make sense. 

> But I agree, that it would be even better if in the list of definitions there were an entry for "page float" and one for "inline float". That way it should be harder to get confused about it.
>  
>> The text saying 'Floats that are not inline floats should behave the same as absolutely positioned exclusions...' is very far away from the float-reference property, almost at the end of the spec. (I don't think the term "inline floats" is ever defined as those with 'float-reference:inline'. It wasn't obvious to me.) You should put that whole sentence into the 'float-reference' property description, but instead of "Floats that are not inline floats" it should be "when float-reference is not 'inline'". 
>> 
>> Also, in section 6, the beginning of the sentence should be  "When float-reference is not 'inline'", instead of just "Floats". I'd move that to the float-reference definition too. 
>> 
> I will change that to "Page floats".
>  
>> 
>> I still don't like the idea of an inline float becoming an exclusion just because I wanted to move it to the top or bottom of the page or container, or that the container must be a fragment, but at least this would at least go far towards making the spec more clear. 
>> 
>> Also, I do not see anything that says 'float-offset' only applies to non-inline-reference floats.  'Float defer' does say it is for "page floats", but that term isn't defined either, and is mislead anyway, since it presumably works with columns and regions too. 
>> 
> 
> I will make sure to add that the float-offset also specifies that it only applies to page floats. 
> 
> 
> 
> -- 
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org