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

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

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

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

Jonathan, if you can wait, I suggest you do. If you can't "inline-start" seems
more future proof to me: if we end up deciding "start" is meaningful for page
floats, inline-start becomes merely redundant, but the other way around isn't true.

 - Florian

Received on Thursday, 5 November 2015 23:38:05 UTC