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

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.




--
Johannes Wilm