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

> On Nov 7, 2015, at 10:20 AM, Johannes Wilm <johannes@fiduswriter.org> wrote:
> 
>> On Sat, Nov 7, 2015 at 5:40 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> 
>>>>> 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. 
>>> 
>>> It has a disclaimer prose about that: "Floats and absolutely positioned exclusions share some common traits, but in the case of inline floats they are not the same. Floats that are not inline floats should behave the same as absolutely positioned exclusions with positions and sizes manually set to prevent overlap between floats and to prevent floats from moving beyond the edges of the float reference, with the float reference being grown as much as needed up to its maximum extend to accommodate all containing floats." [1]
>> 
>> And yet inline floats are redefined in this spec, including with some new values (logical equivalents of left and right). The new inline values and the old ones have different definitions than in CSS 2.1, yet doesn't go into the detail of 2.1, or say which parts of 2.1 need to be changed to support the new values. 
> 
> It is clearly stating at the top that this is about page floats and it explains what page floats are.

And yet inline floats are redefined in this spec, including with some new values (logical equivalents of left and right). Or do you mean that 'float: inline-start/stop don't apply to inline floats? I don't see anything that says that. 

> As already stated, I agree that we should probably move all floats to this spec.

Yes, I agree too. The details from 2.1 should be revised to include the 'start' and 'end' values for inline floats. Or that 'left' always means 'inline-start'.
 
> Alternatively it should clearly state even more clearly that inline floats are not specified in this spec.

If you do that, you should say that 'inline/block-start/stop don't apply to inline floats.

>> We do need to work logical properties into an updated float spec, for inline start and end, at least. 
> 
> The spec has reached FPWD status and people have had time to review. The idea to make page floats just positioned exclusions is not something I came up with myself, but has been a suggestion by other CSSWG members, most of which I remember Rossen. CSS Floats were also discussed at the F2F meeting in New York and it was made clear that page floats are a combination of positioning and exclusions. You can find some discussion about that in the minutes related to "position-fragment".

If I had been there, I would have said something, but I have no travel budget and often have difficulty getting away from work for that many days on the weeks chosen. And personal matters in the last couple years have prevented me from spending as much time on CSS communications as I would have liked. But now I have read it, and I'm voicing my concerns.

> There are many things one could work on. We decided to work on page floats and have followed the general advice of various central CSSWG members. One of the main principles of this seemed to be to use current specs that describe behavior we need, in this case exclusions, and build on top of that instead of trying to reinvent the wheel. That's what has been done.

It's using a completely different wheel, an alternative to floats, but calling it the same one. My proposal didn't reinvent the wheel either. It was a very simple scheme that kept floats inline, while solving the use cases. I don't mind if you want to use exclusions to solve the use cases, but I don't think it should be be a property of 'float' or use 'float-' as a prefix.

>>> I can see how one could try to define some top/bottom floats by only extending the behavior of current floats, although it would not seem like great to handle if one doesn't have a float reference,
>> 
>> Why can't it have a float reference? 
> 
> Because inline floats only relate to the box formatting context they are in.

Only because of the way you defined 'float-reference'. If it was called 'float-to', you could get the same effect with the same values by just moving the float to the first line box (or last, if the block component was 'end') of the containing column, region, or page, or to a subsequent column, region, or page for the "defer" effect (by adding a number or 'last' to the value). If you didn't want that, leave 'float-to' at the initial value of 'containing-block', then block component moving would target the first or last line box instead (or an adjacent one, if that one was is already full of floats moved that way).

> If you extend them to do something else, they are no longer today's inline floats. 

Sure they are. With my proposal, they are still positioned themselves on the end of a line box, but it is just not the original line box. Once there, they act exactly like today's floats (if the horizontal value is not 'none', same as today's floats, otherwise they are just blocks). The property I described for vertical stacking would be a new capability, sort of a partial clearing for subsequent floats in the same bfc, but otherwise would be identical to today's floats. 

>>> and only can affect subsequent content,
>> 
>> That isn't what I described.
> 
> No, but that's how current inline floats work.

If the current inline float is on the first line of the containing block, then all the content is the subsequent content, and that's where my proposal puts it, for the 'top' value. 

>>> has the current stacking behavior, etc. .
>> 
>> Something I have said could be cured with an additional property if it was deemed important. 
>> 
>> I consider the simplicity of my approach to be an advantage. With just a few tweaks, regular, familiar floats can fulfill most of the use cases. And things like deferred floats and float reference can be adapted to be useful in more situations with regular floats. 
> 
> 
> I don't think what you described so far would be enough solve any of the use cases we are thinking of when we think of page floats, which mainly about these things that take up an entire column or page top or side, and sometimes only a part.

I think it does.

> But also, we are missing the description of stacking and deferring strategy.

I have described both.

> If we had those extra parts, then maybe it could work. .
>> My stronger objection is to using a value of 'float' to create exclusions, which by definition are not floats. It just muddies the waters, and prevents solutions that are all-float or all exclusion. 'Float' should have a block direction component that doesn't prevent 2.1-style inline floating. And 'exclusion-float' or whatever it would be called for the float-like positioning of exclusions, should have an inline direction value that still creates an exclusion with 'wrap-flow'. Inline floating and wrap-flow can't be mixed on the same element, because they have different side effects, and inline floating prevents wrap-flow from working. 
> 
> I think things should either be completely page-floats or completely inline-floats,

Then we agree on that, though it wasn't obvious to me before, due to the use of the undefined term "inline float".

> the way it is specified in the spec as of today. Just floating in one direction and beign positioned in the other just seems to make everything a lot more complicated.

My proposal keeps it very simple. The "positioned in the other" part is just putting in a different line box, which is WHY it isn't complicated. All the rules and edge cases and so on for floats still remain unchanged.