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

On Fri, Nov 6, 2015 at 10:43 AM, Brad Kemper <brad.kemper@gmail.com> wrote:

> On Nov 4, 2015, at 4:59 PM, L. David Baron <dbaron@dbaron.org> wrote:
> >
> >> On Wednesday 2015-11-04 16:27 -0800, Tab Atkins Jr. wrote:
> >> It's not a corner case.  All the *examples* have full-width elements
> >> being floated up or down, but that's irrelevant; in practice, a lot of
> >> top/bottom floats will be shrinkwrapped or otherwise sized to
> >> something other than 100%. Horizontal positioning is a requirement
> >> *now*.
> >
> > But even if they might not be full width doesn't mean that the
> > inline content flows around them on both sides.  It still seems like
> > there's a difference between "float to the top, place on the left
> > side, and have text flow underneath but not to the right" and "float
> > to the left, place on the top side, and have text flow on the right
> > but not underneath", even though both are top-left corner.
>
> I'm not so sure "prevent text from wrapping underneath when floating to
> the left" should be part of this. We already have left floats without this,
> and I don't thing floating to the top too changes that.
>
> > And
> > there's also the third option of wrapping on both sides.
>
> That should be the second option (if you mean connecting sides, such as
> right and bottom).
>
> The way I see this, 'float: left top' should be the same as 'float:left',
> except you first move it to the top of the first line line-box of its
> containing block (or of its reference containing block), instead of
> floating it at the line box of its float anchor. Move it up to the first
> line, then do normal float:left from there. It is simple and intuitive.
>
> 'float: none top' would move it to the top line, and make it
> 'display:block' as floating normally does. The result is, text or other
> floats (including subsequent top floats) would start below it, not wrapped
> to the side. If the floated item had 'width: auto', it would fill the space
> horizontally. If it had some other width, or if it was a replaced element,
> then there would be empty space to the right of it. If you wanted empty
> space to the left instead, just add 'margin-left: auto'. In other words,
> exactly the same as if you had moved the item to the beginning of the
> containing block and made it it display:block. No left/right floating
> taking place there (thus the 'none'), so no shrink-to-fit for width.
>
> This means that since it is pretty much the same as left/right/none
> floats, aside from what line box you start from, you've already got tons of
> edge cases solved. And it is easy to learn and understand, being such a
> simple extension of existing floats. Yet it covers most common use cases.
>
> > Or is the plan to have authors do the first two by using a mechanism
> > for the third, and requiring an extra containing element that is
> > width:100% or height:100%?
>
> Only if you don't want text or other floats to wrap underneath, such as
> for a sidebar. Of course, you still have the always confounding problem of
> that not working if the containing block is 'height:auto' (an existing
> problem that I would not fix here).
>
> So here is my list of the 8 compass point use cases (4 corners, and four
> sides), and variations, and the syntax to use (assumes horizontal
> left-to-right writing):
>
> -- Float to top left corner, wrap around right and bottom: 'float: left
> top'.
>
> -- Float to top left corner, start text or other floats underneath:
> 'float: none top').
>
> -- Float to top center, start text or other floats underneath:  'float:
> none top; margin: 0 auto'. Add 'width: 100%' and/or 'box-sizing:
> border-box' if needed/wanted (not necessary for non-replaced 'width: auto'
> items.
>
> -- Float to top right corner, wrap around left and bottom: 'float: right
> top'.
>
> -- Float to top right corner, start text or other floats underneath:
> 'float: none top; margin-left: auto').
>
> -- Float to right, full height, text and subsequent floats to the left:
> 'float: right top; height: 100%; box-sizing: border-box /* optional */;'.
>
> -- Float to bottom right corner, wrap around left and top: 'float: right
> bottom'.
>
> -- Float to bottom right corner, end text and most floats above:  'float:
> none bottom; margin-left: auto'. Subsequent 'none bottom' floats always go
> below all previous floats in the containing block. (Maintains source order
> stacking of bottom floats. See next use case...)
>
> -- Float to bottom center, end text or other non-bottom floats above:
> 'float: none bottom; margin: 0 auto'. Add 'width: 100%' and/or 'box-sizing:
> border-box' if needed/wanted. ***This could be useful for footnotes. ***
>
> -- Float to bottom left corner, wrap around right and top: 'float: left
> bottom'.
>
> -- Float to bottom left corner, end text and most floats above:  'float:
> none bottom;'.
>
> -- Float to left, full height, text and subsequent floats to the right:
> 'float: left top; height: 100%; box-sizing: border-box /* optional */;'.
>
> Note: if you add 100% width on top or bottom floats, then it doesn't much
> matter what you have as the horizontal value, except 'none' doesn't need
> clearing after. With 'float: none top', you don't need 'width: 100%' if you
> already have the initial 'width: auto', since it is a block that expands to
> fit.



>
> ------------------
> The single values for floats would expand thusly:
>
> -- 'float: top' = 'float: none top' (no left or right mentioned, so no
> left or right floating).
>
>
As was mentioned earlier, floating in the block direction and not the
inline direction will likely give us results of low value.

Take this example:

If we only float in the block direction and not in the inline direction, we
will get something like this: http://snag.gy/2Otfa.jpg (this is two top
floats. The red Xs are the page float anchors (call outs).

The floats are placed directly above the Xs to visualize that these are the
anchors. In practice it will be very hard to place them there though: When
the top floats are placed, they will push the text along. That means that
the Xs will move further right (until hitting a line break). SO in order to
get them to be placed exactly above the X, one will probably have to have a
loop of some sort that places the float, then checks where the float anchor
is now in the inline direction, moves the float, checks whether that has
caused the float anchor to move, move the float again, etc.  until the
float and float anchor are "close enough".

That is a lot of work. If we really want this, I think we should have a
solid use case for this.




> -- 'float: bottom' = 'float: none bottom ' (no left or right mentioned, so
> no left or right floating).
>
> -- 'float: left' = 'float: left none' (no top or bottom mentioned, so no
> top or bottom floating, matches existing).
>
> -- 'float: right' = 'float: right none' (no top or bottom mentioned, so no
> top or bottom floating, matches existing).
>


I think page floats will have to behave quite differently than inline
floats here. If one floats to the top, one expects the float to cover the
entire top, not to land at some arbiotrary place in the inline direction.
Same if one wants to float to the right or left of a column/page/region.


>
> ------------------
> If you accept that, and that the logical values should be in the spots
> equivalent to Western style writing (left to right, top to bottom), then
> the order of logical equivalents should be 'inline' then 'block'. So
> 'float: start none' would be the same as 'float: left none' (for me), which
> is 'float: left'. Very logical logical, to me.
>

As mentioned in my earlier emails, this will not do it. It creates problems
for stacking.


>
> So single word logical equivalents would be:
>
> -- 'float: start' = 'float: start none'
>
> -- 'float: end' = 'float: end none'
>
> Both of those are useful for the simple case of inline floating. For block
> floating, just use the 2 word version. E.g., 'float: none start', not
> 'float: block-start', and 'float: start start', not 'float: line-start
> block-start'.
>

inline floating only works along a single axis. The "page floats" that do
float along two axis will need to be able to specify if the top or the left
is prioritized. A syntax such as "float: start end" is not working for that.


>
> ----
> Vertical float clearing only matters if you have multiple fragments.
>

That's the conclusion I had with page floats, which is why the float
reference for all but inline floats only can some kind of fragment. Putting
the images to the top of a conventional DIV, etc. can also be achieved in
other ways.

However, the feedback I have received so far indicates that people would
also like to float in the block direction in block elements. They will just
lose a lot of features related to deferring floats, etc.



-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org

On Fri, Nov 6, 2015 at 11:06 AM, Brad Kemper <brad.kemper@gmail.com> wrote:

>
> On Nov 6, 2015, at 12:33 AM, Johannes Wilm <johannes@fiduswriter.org>
> wrote:
>
>
>
> On Fri, Nov 6, 2015 at 8:00 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>
>>
>> > On Nov 4, 2015, at 4:46 PM, Florian Rivoal <florian@rivoal.net> wrote:
>> >
>> > - I am not comfortable with deciding on the syntax of page floats
>> >  before we decide on the semantics. We've had semantics in a spec
>> >  for a while, and I am arguing for syntax based on these semantics.
>> >  If we want different semantics, let's have that discussion.
>>
>> I think we should. I'm concerned that the current semantics may limit our
>> choices of good 2D float semantics.
>>
>
> The conclusion of my last two emails  was that yes, we can have 2D light
> without having to write a lot of very complex placement logic, but their
> order will matter.
>
> "float: bottom left" means that the first priority is to float to the
> bottom. That first priority is used to determine what space in the given
> fragment is reserved for the page float in relation to other page floats.
> The second priority is "left". So it will be floated to the left most part
> of the area that has been reserved for it through means of the first
> priority floating.
>
> "float: left bottom" means the opposite.
>
> The results will differ once there are several floats within the same
> fragment.
>
>
> And if a 'float: left bottom' is followed by a 'float: bottom left',
> flowed by a 'float: left bottom', followed by a 'float: bottom left'? A
> stair step arrangement?
>
> This seems complicated and unnecessary to me, and breaks the normal
> expectations of horizontal coming first when two values represent two axes
> (X and Y, horizontal and vertical). And it is way too subtle to expect
> authors to easily figure out that this ordering is significant to float
> stacking.
>
> I expect top and bottom to indicate where the float is placed prior to any
> horizontal floating. don't see a great need to stack floats vertically, and
> then wrap text around all of them. If that's needed, then another property
> can be added, such as 'next-float: vertical'. But that needs a lot of
> thought, and I'm happy if that isn't added until later.
>
>
> So if we change it from:
>
> "float: inline-start block-end"
>
> to just
>
> "float: end start"
>
> then we have lost a vital piece of information. So I don't think that is a
> good idea.
>
> I agree with Tab that content should normally not overload fragments, but
> it is not uncommon to have more than one float in a fragment. And authors
> should be able to predict what happens then.
>
> --
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org
>
>


-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org