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

Brad Kemper
> On Nov 12, 2015, at 12:56 AM, Johannes Wilm <johanneswilm@vivliostyle.com> wrote:
> 
> 
> 
>> On Thu, Nov 12, 2015 at 8:55 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> Hopefully I won't be the only one to reply, but I wanted to clarify a few things.... 
>> 
>> 
>> 
>> Sent from my iPad
>> On Nov 11, 2015, at 10:09 AM, Johannes Wilm <johanneswilm@vivliostyle.com> wrote:
>> 
>>> 
>>> Hey again,
>>> I have looked a bit more at the different specs. And I have some questions to better understand the concerns Brad came with.
>>> 
>>> 
>>> On Exclusions vs. Visuren
>>> 
>>> Both the part about floats in CSS 2.1 Visuren [1] and the CSS Exclusion spec [2] have instructions exactly how to do the placement process of the float. As far as I can tell, the one in Visuren only works for floats that relate to subsequent content, whereas the exclusion one is more general for something that can be placed in some other part of the site.
>>> 
>>> Now if we want to float up, as far as I can tell, we can't really use the rules from Visuren, because we have to influence previous content.
>> 
>> The rules from Visuren don't have the feature for forcing the float to the top or bottom, but that doesn't mean it can't be added in a way that otherwise keeps everything else described there the same. 
> 
> As I read the rules, they talk about how subsequent content should behave. But this would not be enough, one would also have to describe how previous content behaves which in turn would affect the float itself, if one does not describe in what way it is exempt from the rules.

When it is at the top of the containing block, there is no previous content. 

Step 1: move it to the start start of the containing block. 

Step 2: left it be a left float or right float or none float (in the inline direction), to affect subsequent content. 

Step 3: There is no step three. 

For putting it at the bottom it would just make the containing block taller or cause overflow if it couldn't. For fragmenting containers it's a little trickier, because it needs to be placed just high enough to fit. The UA would probably have to compose bottom floats offscreen first to determine fit, in order to know what line to start them on. And they might need a nudge down of less than a line height, in order for their bottom margin to align with the bottom of the page/column/region. 


>> The basic thing I suggested was to move the left/right/none float to the beginning of the first line box of the containing block when a new property (aka 'block-start', 'top', etc.) of 'float' told it to. If something else had already been put there by the same value, then you'd put it right after it. But the left and right floating would still work exactly the same. 
>> 
>> This can even be simulated with JavaScript, or by moving a float around using the Inspector in your browser. Once you move it to being the first thing in the box, it is still a left float or right float, in exactly the way described in Visuren. Or if the inline direction part was 'none', it still would be after moving it to the block start.
> 
> You seem to be suggesting top/down movement within one container element.

Yes, that would be the default containing block for property values that moved the floats in the block direction. 

> So that is only for that case, not for page floats that locate over a series of fragments, correct? 

Not correct. I thought I described a property called 'float-to' that would combine the general effects of 'float-reference' and 'float-defer'. It's possible I haven't sent that yet. 

It would be a two part value, with the second value optional. The first part would allow you to choose between containing-block, column, page, and region. It would move it to the first ancestor that matches. This is what I originally imagined 'float-reference' would do. 

The second part would be a number or 'last', to move it to a different subsequent column, page, or region of the same chain. 

> What about a recipe for the stacking of such floats? 

I think I already suggested a property and how it would work. 

>>> Then there is the section of the CSS Exclusion spec that talks about differences between exclusions and floats [3]:
>>> 
>>> "
>>> scope. While floats apply to content that follows in the document, exclusions apply to the  content in their containing block.
>>> positioning. Floats are part of the inline flow and float on the line box. Authors can control how the floats move on the line box, to the right or to the left. By contrast, exclusions can be positioned using any positioning scheme such as grid layout ([CSS3-GRID-LAYOUT]), flexible box ([CSS3-FLEXBOX]) or any other CSS positioning scheme.
>>> separation of concerns. Making an element a float determines both its positioning scheme and its effect on inline content. Making an element an exclusion only determines its impact on inline content and does not impose constraints on its positioning method.
>>> "
>>> 
>>> The first of those three would not apply to page floats and top floats anyway.
>> 
>> Doesn't it? Can't a tall float starting on the first line  (or exclusion positioned at the top) be sticking out of the bottom of a short (fixed height) column, and affecting (or not) the content below it?
> 
> 
> Two parts here:
> 
> 1. Do the mentioned restrictions for floats apply ("apply to content that follows in the document")?

For what I've been describing? Yes. 

> No, because it could also affect content that comes before it.

Incorrect. It is moved first, then affects only the content that comes after it in its new position. It also affects content in blocks that follow after its own containing block, which exclusions don't. 

> 2. Do the mentioned restrictions for exclusions apply ("apply to the  content in their containing block")?
> 
> Yes, at least according to the current spec.

Only to content in the same containing block. Floats can affect content outside the containing block. 

> Non-overlapping is only guaranteed for other floats with the same float reference and the bfc has the same dimensions as the float reference. This means one cannot simply make a column float overlap the next column by setting the width to 200% or some such thing. The point of this is mainly to cut down on the complexity needed.

I don't think a float can cross columns that way either. They get clipped. They can flow from one column to the next in the block direction, if the column height is restricted (they basically get sliced in two). 

>>> The remaining two issues just seem to basically explain how exclusions work and that they don't determine positioning. 
>> 
>> There are other significant differences too. For instance, z-index changes the wrapping in exclusions. This can affect page floats as exclusions too, since negative margins can still cause them to overlap each other. 
> 
> negative margins... ok, possibly that would be doable. Either we forbid negative margins for placement calculation, or we keep them. If we keep them, we have the advantage of already having a pre-defined behavior.

Real floats can have negative margins. Either way, your results with exclusions, even in the inline direction, are going to be noticeably different than traditional floats.  

I don't think you should restrict against negative margins. It's just a different model than floats, though, and should be recognized as such. 

>>> Given that the point of the page float spec would be to describe positioning and leave the description of how that influences text flow of the content behind it to the exclusion spec, it doesn't seem like this would make it incompatible either.
>>> 
>>> 
>>> So my question now is: What difference would it make if we would try to define the same page floats as we have them now without pointing to the CSS Exclusion spec? Would we not have to end up having to describe much of the same of how content flows around it as is now in the CSS Exclusion spec?
>> 
>> In my view, no, not if we went with something like I suggested (where the vertical component just changed the line box, but kept inline floating the same). We would have to describe the floats-clearing-other-floats-only behavior that I suggested for a separate property, which would give us vertical columns of single left floats or right floats. Even this one though, is basically just like changing the order of the floats in the document a little prior to applying the rules of Visuren. Conceptually it is not too different from 'order' in flexbox. 
> 
> Ok, my udnerstanding is that your proposals are meant for top/down single box floats, not page floats, right?

That depends on how one defines page floats. It's using the float property to move an item to the block start or end) of a containing-block, column, page, and region, where it can then float or not in the inline direction. 

>> Moving left/right floats to the bottom is a maybe little trickier, because after you move several things to the same line box, their margin boxes will be aligned along the top, and more line boxes could theoretically be created under them, but I think this too could be spec'ed in a useful but simple way that didn't change what it means to be a left/right float, as described in Visuren. 
>> 
>> For the exclusions version you've been working on, I don't think you'd have to repeat a lot of what is in the Exclusions spec. Once you say that the "floats" are actually exclusions, and that they follow all the rules of the Exclusions spec, then basically you are creating syntax for positioning things. I don't think you'd have to redefine anything that is in that spec already. It already avoids talking about where to put the exclusions. 
> 
> Exactly. That was the point of referring to the exclusion spec. Just keep it to placement.
>  
>> 
>>> On inline-start vs. start
>>> 
>>> I was thinking: One solution that could work with all the models would be if "start" and "end" simple referred to the inline directions, and one would still have to use "block-start" and "block-end" for the block directions. Maybe even have "start" and "inline-start".
>>> 
>>> Or would that break with the general naming scheme?
>> 
>> I think it is inconsistent with the general strategy of how we use these in other things, but I'll let others speak to that. 
>> 
>>> On logical directions
>>> 
>>> 
>>> I worked some on this, but had input from Shinyu and Elika, and our internal review at Vivliostyle made us think we are correct with the current formulation (which also seems to be in line with what Elika and Florian have said on the mailing list). Does anyone disagree with the current formulation? And if yes, what do you think it should say instead?
>> 
>> Just this:
>> 
>> If one value page floats were expandable into two values (as I believe they should), then 'start start' is better than 'inline-start block-start'. 
> 
> 
> To me it would seem that if we extend the current algorithm for placement, the easiest would be to add a secondary direction that is applied only after the first axis placement has taken place already. "inline-start" currently already means "inline-start block-start" and "block-start" means "block-start inline-start" where the second one is the secondary direction. The important thing is that "block-start inline-start" and "inline-start block-start" do not mean the same thing.

Typically, the horizontal direction comes first, and the vertical one second, when the values represent 2d axes. Given the western-centric preference in CSS (for initial values, etc), this would translate to inline direction first and block direction second. 

We don't typically change what each position represents to indicate order of execution. That would be very unusual and surprising. And writing four words instead of one or two would be author-hostile. 

With my scheme, you could still write 'float: left' and it would mean the same as 'float: left none'. In the same vein, 'float: top' would mean the same as 'float: none top'. This is consistent with other CSS constructions, and the rules for the other values fall out from there. 'Float:start' would be the same as 'float: start none' (floating inline only, which I expect would still get more use than block-direction floats). 

>> And in the case that page floats were created via a separate property, instead of just a value of 'float' (as I feel they should be), then even if we don't yet add a new vertical (or bock direction) movement value to 'float' itself, we should have 'start' and 'end' values for the inline direction, and that should be added to an edit of the existing float spec language of Visuren. Then if we ever added a block direction to 'float' itself, it could be start, end, top, or bottom, to go into the second position of the value. A single start or stop would indicate inline direction only, just as left and right do now.
>> 
>>> On the name of the spec
>>> 
>>> I am fine with changing the name. Or keeping it. I would in general be in favor of describing both inline floats and page floats in the same spec, because they both use the same properties, but I don't have a very strong opinion on this. But besides Brad
>> 
>> Sorry, I just want to be clear. I don't feel strongly about the name of the spec itself, or if there is one spec or two specs or which ones appear together. What I do feel strongly about is that the property itself should not be 'float' if it works close to what is described. I don't think 'float:left' should ever change to a completely different alternative model of wrapping text and positioning, due to the presence of another property like 'float-reference'. When it does that, almost everything Visuren says about floats no longer applies, and is replaced by exclusions and the text that you have for placement and collision avoidance. 
> 
> but having "float: top" will already break the placement model mentioned in Visuren because it affects previous content, right?

Nope. Just one step to move it to the start of the first line box, then everything else in the model remains the same. The only things we are adding is that one step at the very beginning of the model processing. I keep saying this...

>> I have suggested 'wrap-float' as an alternative property name that leaves 'float' alone, if you want to continue with an exclusion-based version of float-like positioning, in two dimensions. It's a little weird still, since floats wrap too, but exclusion properties all start with 'wrap-'. Maybe 'wrap-stack' would be better, since the new spec describes how to stack exclusions' margin boxes against each other vertically and horizontally. 
>> 
>> By the way, we should also change the term "page float" regardless. It isn't just pages anymore. 
> 
> "fragmentation floats"?

Yeah, maybe. 

> We could have three types of floats in that spec:
> 
> 1. inline floats (behave as usual)
> 
> 2. fragmentation floats (behave similar to what we currently call "page floats", with adjustments)
> 
> 3. block floats (have many of the same features as fragmentation floats, but cannot be deferred to subsequent containers, and "clear: top/bottom" may also have a different meaning or no meaning).

Just two:

1. inline floats (behave as usual, but can be moved to top or bottom first). A new property is also added for vertical floating:  Prevents two same-value floats from being next to each other on a line, so second one moves down to a new line (like clearing), but still letting other inline content to flow around both. This is still just a "move vertically, then inline float as normal" kind of thing). 

2. fragmentation floats (behave similar to what we currently call "page floats", with adjustments). Might need to have 'wrap-clear' or something to avoid conflict with similar vertical clearing of regular floats. Uses 'wrap-float' property and 'wrap-*' for other related properties, instead of 'float' and 'float-*'. 

But yes, this is the way I see it. And if you want to do #2 first, I don't mind. 

> And then if I understand your proposal right, you would not want to refer to exclusions for "block floats" but are ok with them being used for "fragmentation floats"?

Yes, unless a better name is found. 

>  
>> 
>>> and myself, what do other people think?
>>> 
>>> 
>>> [1] http://www.w3.org/TR/CSS21/visuren.html#floats
>>> [2] http://www.w3.org/TR/css3-exclusions/#exclusions-processing-model
>>> [3] http://www.w3.org/TR/css3-exclusions/#floats-and-exclusions-differences
>