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

> 
> On 06 Nov 2015, at 10:17, Alan Stearns <stearns@adobe.com> wrote:
> 
> On 11/5/15, 3:52 PM, "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.


While the 8 point compass might work, I am not actually sure it does.

As hinted by the name, page floats work best in paged/fragmented
context, and then you need more than the 8 point compass to say things
like "top of the last column of the left page", "bottom, taking the width
of n-2 columns of this n column layout, centered", "top/left of any of these
3 slots in this 7-slot page template"...

Maybe an 8 point compass gets you all the way there in some way I don't
see. Maybe it gets us some of the way there, and we'll need further
extensions to get the rest. Or maybe (and that's my worry), it solves
a marginally larged set of use cases that what the spec currently has,
while at the same time locking us out of a different design that would
actually solve the rest well.

I find it plausible that the 8 point compass would works, and that
we may be able to deal with the rest of what I suggested using more
values in float-reference, but I don't think that's the only
approach possible, and I don't know if it is the best. For instance,
even if we restrict the float property to 2x1D (and various extensions
to deal with which column of which page, etc), we could also answer
the question of which side floats whose width is less than 100% go to
using various other properties such as left/right, flow-wrap, etc.

Or maybe the solution is something else entirely, possibly using
grid layout as Alan suggests below. It just seems to me that
what is currently specified is a subset of everything that's been
suggested so far, and therefore is safe to start with.

>> 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 think there is a significant share of use cases which are indifferent
to top vs top-left vs top-right because they are top/width:100%.

>> I'm not sure what's confusing or controversial about this, so I assume
>> there's a communication breakdown here. :/
>> 
>>>> Since page floats move you in 2d, and I don't think there's a natural
>>>> answer for where they should be placed in the inline axis (looking at
>>>> examples, they appear to be common in all four corners, at least),
>>>> allowing people to specify both axises is necessary.
>>> 
>>> I don't know if there's a "natural answer", but there is a specified
>>> answer (perhaps insufficiently clearly, but that's a separate question),
>>> and that answer is so far believed to solve a decently large set of use
>>> cases.
>> 
>> I don't think you can argue with a straight face that restricting
>> boxes to floating to the top-left and bottom-right corners (for
>> English) addresses a sufficient number of use-cases.  It seems plain
>> to me that top-right and bottom-left are both useful and common in
>> practice; I see both plenty in magazines and newspapers.
> 
> The current proposal isn’t really restricting to top left and bottom right, it’s restricting to handle the case of the top float spanning the entire column, with a top-left or bottom-right fallback if the element isn’t big enough.
> 
> I’m worried that coming up with a 4-corner syntax might merely be a bandage. Just in this reply alone you went from asserting that 8 compass points covered the real-world examples you were thinking of, to saying 4 positions would be sufficient. I doubt that real-world cases are limited to the 8 compass points. Just discussing 2 versus 4 versus 8 reminds me of the limitations of the 16 margin boxes in paged media. I would rather not re-create another complicated-yet-still-inadequate system in page floats.
> 
> So I think it may be OK to limit page floats to take up the entire column as currently specified. For the more complex cases, I think it may be more promising to find solutions in future extensions to grid layout, which would not have ratcheted limitations on alignment.

Completely agree to each of the three paragraphs form Alan.

 - Florian

Received on Friday, 6 November 2015 09:21:18 UTC