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

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. 

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.

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

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

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

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. 

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

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. 

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. 

> 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