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

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.

> Yes, more use cases can be solved with a more expressive syntax. But that
> does not mean that the current syntax fails to solve anything.

I'm just saying you need two values, one for vertical and one for
horizontal.  Currently the spec has two inline values and two block
values, with the other axis always assumed, in a way that I'm arguing
is not expressive enough to address sufficient use-cases.

>>> I think in that case it would be good if we could try to define the list of
>>> restrictions of page floats (compared to regular floats) you would like to
>>> see that you mentioned in Paris, Tab. That may cut down in some of the
>>> complexity of trying to place them. That we can make sure that page floats
>>> do all we need them to do, without getting so complex that they no longer
>>> are interesting for browsers.
>>
>> Yeah, I'm happy to help here, but don't have a ton of time to work on
>> this topic. I'll see what I can write up in the next few weeks.
>
> If we can solve more use cases with a sufficiently small increase in complexity
> that it does not substantially change the chances of this getting implemented,
> then I'm all for it.
>
> In the meanwhile, this all started with a question from Jonathan about which of
> inline-start or start Mozilla should use. I don't think we have an answer to that
> question until we've discussed your upcoming proposal.

I already gave my proposal - [ start | end ]{2}.  Handling the other
values requires more complexity, but building around this core seems
necessary.  Unless you really are willing to argue that nobody ever
floats boxes in the top-right corner of some text.

~TJ

Received on Thursday, 5 November 2015 23:53:29 UTC