W3C home > Mailing lists > Public > www-style@w3.org > November 2015

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 5 Nov 2015 19:06:35 -0800
Message-ID: <CAAWBYDA=SudrxrZBuCZRjvjnfjdMDnFeK_8ZMQBsX1wFgpyj_A@mail.gmail.com>
To: Johannes Wilm <johanneswilm@vivliostyle.com>
Cc: Florian Rivoal <florian@rivoal.net>, "L. David Baron" <dbaron@dbaron.org>, Jonathan Kew <jfkthame@gmail.com>, fantasai <fantasai.lists@inkedblade.net>, Koji Ishii <kojiishi@gmail.com>, "www-style@w3.org" <www-style@w3.org>, Rossen Atanassov <ratan@microsoft.com>, "Elika J. Etemad" <fantasai@inkedblade.net>
On Thu, Nov 5, 2015 at 6:55 PM, 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.

Yup, more detail is needed.  But none of that detail can be avoided
*today*.  Being able to float in only 2 of the 4 corners doesn't
answer "how do I stack if multiple floats are around"; or if it does,
the same logic will reasonably extend to floating in all 4 corners.

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

I'm fine with real simple stacking rules for now.  Most of the time,
page floats should be singular in a given context/location; that's how
they are in practice in controlled layouts, at least.  I believe we
can come up with reasonable defaults for stacking when they do end up
colliding.  For example, "if this is a top float, stack downwards",
etc.

~TJ
Received on Friday, 6 November 2015 03:07:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:58 UTC