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

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

And your example for float-offset shows something with float: left also having float-reference and float-offset. 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? Or does it "continue to be what it is" in 2.1 somehow, in spite of no longer floating on its original line box the way 2.1 describes? Or does it stay in its line box, which might be inside a 'display:inline-block' element or table that has no edges aligning with the column, which indeed may be visually outside the column due to negative margin or absolute positioning on that parent, yet is still somehow aligned with one edge of the column? Nothing in the spec describes how something can remain inline according to all the rules of 2.1, yet somehow align with the edges of a different box that might be completely separated from it by empty space. I had originally assumed the item would move to the reference box, but I don't see how that would work for an inline float that is connected to the linebox of its float anchor according to CSS 2.1. That's why my idea was to move it to a different line box for floating vertically or when floating to a different reference box. 

> But besides that, the spec was until now just the "page float" spec, not the "float spec". I talked to David Baron about whether it should also cover the behavior of inline floats at the F2F in new Yoprk, and his advice was to add notices of "This section is not normative." to make sure noone could think that this spec would also cover inline floats.

It does normatively define them, though, and in a way that is different than in 2.1. Then it goes on to say that floats are exclusions, with no qualification about inline floats until the next section. I don't see how you can define six values for float that are or can be inline floats, without saying normative statements about how they change the old or relate to the new. 

It would be so much simpler is floats and exclusions were kept separate, aside from properties that applied to both in similar but different ways. 

> However, the question came up recently again, and it seems Tab advises to have this spec take over all types of floats [2]. If we do that, then probably the name should change to the "CSS Floats or some such thing.

I could be wrong, but I took his comment to mean the float spec needed to be re-described in full, in light of how the new properties change and add to it. I wonder if he realized that it is not intended to change actually floating behavior, aside from using the property name to create a special kind of exclusion instead. 

We do need to work logical properties into an updated float spec, for inline start and end, at least. 

>> 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). 
> 
> Well, see above.

Section 9 doesn't say if, how, or to what extent the new properties  apply to inline floats. It just says a little about how inline floats and exclusions are different. 

>> 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". 
> 
> The definition of inline floats should just be followed as hitherto. If we move that definition into this spec as well, then it should stillbe the same and not be changed.

I don't see how that's possible, since you are already giving new inline values for the logical 'float' properties. And this answer is still inconsistent with example 18 in section 7, in which an inline float is apparently aligned with another box and offset, which hitherto has not been part of inline floats. 

> To me current floats seem like something that should just stay like they are due to legacy content, but that's it.

It is yet to be proven whether or not exclusions can effectively replace current floats, or whether in use some tradeoffs will become apparent. Until then, I want a real inline float (or float:none in the inline direction) that, generally, can move to the top or bottom of the container (or another container) while pushing aside any content that's already there. I want some of your other new capabilities to apply to real floats too.  

>> If page floats are actually exclusions, do properties like 'float-offset' affect all exclusions, or only non-inline "floats"?
> 
> To me this sounds a bit like:
> 
> "There is a new type of car called "police vehicles" which are cars with sirens on them. Ergo all cars now have sirens on them."

Not to me. It is more like someone saying "this siren turns a car into a special kind of police vehicle." And "here are some other accessories that can be used alongside sirens to enhance those vehicles." But not saying if they work on other police vehicles (the ones that don't have sirens). It's a reasonable question to ask about that, since the spec is silent about it. Is silent about what applies to exclusions in general and it is silent about what applies to actual inline floats as we've always known them. 
> So no. Page floats are positioned exclusions. Anything that is in the page floats spec does not in any way affect exclusions in general.
>  
>> 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?
> 
> I guess the absolute position wins over the float property and with that it also loses all aspects of being a page float. But to be honest, I am not sure what the common practice for such cases is. What is your suggestion?

Absolute positioning kills floating normally, so I guess it should kill float-like behavior of exclusions too. So yeah, I agree with you on this much. 

So then, 'not-actually-a-float: top' creates an exclusion with float-like characteristics, and  allows some other related properties to apply to it, but once you add positioning, it loses those characteristics and the other new properties cease to have an effect. Sounds about right. 

>> 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? 
> 
> The initial value, in the current proposal, would be "clear". So I guess that means "auto" = "clear" for page floats. But I am actually unsure if that is a good idea and what the common practice is in such cases.

I'm not sure either.  

>> 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. 
> 
> 
> Well, it depends a bit what you understand by "float". Page floats, no matter how you define them, will have some seriously different behavior from today's inline floats. Are they still the same?

Not if they are actually exclusions. Exclusions are defined to not exist when 'float' is not 'none'. They are a very separate thing. For 2D floats, there is no way to be a float in one direction and an exclusion in another, unless you go into much, much more detail about which parts you're using from each and how it changes what we know about each once (including the float baggage) when they are used together. It seems untenable to me, which is one reason why I think they should be kept separate. 

If it is something that can remain a regular float and is tightly coupled with the way floats work, but in the 90deg direction, then it makes sense to have it part of a 'float' value. 

> Should they have a different name?

Yes, if one value is creating a float  and another is preventing a float and creating something that fundamentally different but superficially similar, then that second thing should not be called a float or be generated from the 'float' property, IMO.  

> I am not sure myself. But also, I don't see any major issues with this. To me positioned exclusions seem more consistent and easier to work with while inline floats have the historic baggage they have.

Some of that baggage is due to features that someone thought was useful when they were designing floats. Some of that will be gone in exclusions, and some things will just work in surprising ways for people used to floats and expecting float behavior/baggage/features. I think less surprising is generally better. 

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

> and only can affect subsequent content,

That isn't what I described. 

> 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 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 don't think you can float into yourself.

You mean "flow" into yourself, right?

You can flow your own content into yourself with the 'content' keyword. That would create a single region, where I'm suddenly allowed to float a child to the top or bottom of it. 

> But you could try to make a multi col environment and only have one column (visible). Of course you would have the problem that by artificially restricting the number of columns to 1, if the column has a max-height/width, and not all floats fit, then the extra floats will disappear into nothingness.
> 
> The restriction here is not that one arbitrarily has chosen not to support single elements for no good reason. It is because logically, page floats will not be able to make use of a lot of their properties that there is a question of to what degree it makes sense to do this at all.

I think floating to the top or bottom can be extremely useful, in and of itself, even if you don't always have a need to fragment into pages or or columns or regions. Defer needs those to be useful, but they wouldn't need to be the same fragmentainer as the float-reference in order to be useful. 

> But given that there is interest, I think we should add an option to 2D float in a single block element.

How would that work, if inline values create traditional floats, and block values create exclusions. An element can't be both of those at the same time. 

> We just then should also make clear which parts of the spec do not make sense for such floats. 

Yeah, or design sensible alternative behaviors for such floats. 

>>>> 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. 
> 
> 
> See above logic about police cars.

It is far from obvious with the way it is currently worded.  

>> 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. 
> 
> 
> I think page floats are just as "real" as inline floats, they just work differently.

Very differently. Inline floats are defined in CSS 2.1, and described there as "floats". Exclusions are described in the Exclusions spec as being incompatible with those traditional floats, and not doing anything if 'float' is not 'none'. The two concepts are mutually exclusive. This means that what everyone currently understands to be a float cannot be also an exclusion. Exclusions were designed to be similar to floats, but not floats. Therefore, exclusions are not real floats. I'd say they are float-like. 

> I don't think there is any reason to move anything into the exclusion spec. The themes covered in the page float spec are not overlapping those mentioned in the exclusions spec and they are fine where they are. If we rename the spec to the "CSS Floats" spec, we will add more about inline floats.

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. 

> If we rename it to "CSS positioned exclusions in fragmentainer contexts spec" then it can keep the current content. 

You could actually call it whatever you want, but the inline floats and exclusions can't be mixed in the same element. So it should be made clear with every property definition which apply to floats and which applies to exclusions. Supposedly, most of the new properties do not apply to anything with any inline direction floating (the 'float-offset' example is a mistake?), so it confuses the situation to use 'float-*' for them, instead of maybe 'wrap-*', or maybe no prefix for properties that could actually apply to both. 100% of everything we've known as a float in the past is excluded from participating in these new properties that begin with 'float-', and that isn't right. It's like having a 'table-*' prefix for properties that only apply to grid. 

> Personally, I think we should go for "CSS Floats", accept inline floats for what they are due to their historic background and not fiddle around with how they behave too much. We should then use positioned exclusion based floats for everything new we invent. But I'm open for other suggestions.

I've given suggestions. Or did you mean for the module title only?