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

On Fri, Nov 6, 2015 at 3:55 AM, Johannes Wilm <johanneswilm@vivliostyle.com>
wrote:

>
>
> On Fri, Nov 6, 2015 at 12:52 AM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>
>> On Thu, Nov 5, 2015 at 3:37 PM, Florian Rivoal <florian@rivoal.net>
>> wrote:
>> >> On 06 Nov 2015, at 08:10, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> >> On Wed, Nov 4, 2015 at 6:00 PM, Johannes Wilm <
>> johannes@fiduswriter.org> wrote:
>> >>> On Thu, Nov 5, 2015 at 1:59 AM, 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*.
>> >>>
>> >>> If browsers are interested even in 2D floating, then all the better!
>> >>
>> >> It's not that "browsers are interested even in 2D floating", it's that
>> >> page floats *are* 2d floating.  Restricting the author to only
>> >> specifying the position in one axis doesn't make it 1d unless there's
>> >> a natural and appropriate value for the other axis that can always be
>> >> determined automatically.  (For line floats there is - the line they
>> >> appear on, or as close as they can get to that if they wrap.)
>> >
>> > Page floats are certainly not positioned on a single straight line, so
>> > in that sense they are not 1D, and you can call they 2D if you want.
>> > But they do not move to arbitrary positions in a 2D plane (or even to
>> > arbitrary positions along the edges of a 2D shape). The positioning
>> > of floats is more logical than geometric. I don't think it is reasonable
>> > to assume a syntax made for arbitrary 2D positioning will just work,
>> > without figuring out what it actually means. Maybe it does, but
>> > that needs to be shown, not assumed.
>>
>> I didn't say you needed a syntax for *arbitrary* 2d positioning.  I
>> agree that's probably overkill; real-world examples tend to position
>> on the 8 compass points of the box's boundary.
>>
>> But it's still 2d positioning.  You still need to be able to specify
>> whether you want the top-left or the top-right corner.  "float: top;"
>> is ambiguous; while we can and should define a default horizontal
>> position for that, we need to enable people to declare it themselves
>> too.
>>
>> I'm not sure what's confusing or controversial about this, so I assume
>> there's a communication breakdown here. :/
>>
>
> "float: top left"; may work for one float. But what if we have a second
> float that also wants to go to "float:top left"? Does it stack to the right
> of the first float or below it? Both types of stacking can be found in
> magazines and books.
>
> So if we do "float: top left" and want to cover all that is common and
> natural, then we also have to have some way of saying whether it is more
> important for the float to be at the left edge or at the top edge.
>
> And if we do that, and we have a float that has prioritized the left edge
> ("float: top left left") where does it stack if the entire left edge of the
> float-reference is filled up by other floats? Does it then try to stack on
> the top edge instead? What if both the entire left and top edges are filled
> with floats? Does it defer to the next fragment or does it try to stack in
> top-left most corner that is still unoccupied? etc.
>
> These are some of the questions which made me think that this may end up
> being too complex for anything browsers will want to implement, and we do
> need to make the cut-off not just before edge cases but also some book
> designs may be too complex to be supported by browsers.
>
> But I can see how we could get some 2D-seeming functionality. For example,
> instead of just having the bottom right and top left corners, as we do now,
> we could have a way of saying:
>
> - "This is a top float. If it doesn't fill the entire width, make it move
> to the left most edge."
> - "This is a right float. If it doesn't fill the entire height, make it
> move to the top edge."
>
> That would only introduce two new floating locations and thereby give some
> light 2D support and one would be able to float to all four corners,
> without really making placement more complex. It would still be assumed to
> be 100% in width/height for the purpose of figuring out where tho place it,
> and the stacking direction would still be clear.
>
> Sorry. Actually we would need a total of eight options:

The first value is the float direction and the second is the preferred edge
to align to if it doesn't fill 100%:

float: top left; (a top float that is assumed to be 100% wide for purposes
of figuring out in which fragment to put it, but if it actually is less
than that in width is placed left-most)
float: top right;
float: bottom left;
float: bottom right;
float: left top;
float: left bottom;
float: right top;
float: right bottom;

So that is 4 more directions than what we have today, but we should be able
to use the current, simplified logic to figure out where to place the
floats. This still doesn't cover a lot of book/magazine layouts, and it may
decide to defer floats to a subsequent fragment if even if there is still
space in the current fragment. But when that happens, authors can figure
out why it happens.



>
>
>
> --
> Johannes Wilm
>