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

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

Thanks,

Alan

Received on Friday, 6 November 2015 01:18:13 UTC