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

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.


>
> 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.
So that is only for that case, not for page floats that locate over a
series of fragments, correct?

What about a recipe for the stacking of such floats?


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

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

2. Do the mentioned restrictions for exclusions apply ("apply to the
 content in their containing block")?

Yes, at least according to the current spec. 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.


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


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


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


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


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

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


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


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