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: Florian Rivoal <florian@rivoal.net>
Date: Thu, 5 Nov 2015 09:14:35 +0900
Cc: 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>
Message-Id: <09968E2A-011E-4BDB-9A66-E0EF694C3F83@rivoal.net>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

> On 05 Nov 2015, at 09:03, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Wed, Nov 4, 2015 at 3:35 PM, Florian Rivoal <florian@rivoal.net> wrote:
>>> On 05 Nov 2015, at 04:02, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> fantasai and I discussed this a bit today after reading Brad's email,
>>> and concluded that we did want to stick with just "start" and "end".
>>> Details:
>>> For today's simple 1-axis floats, "start" and "end" are unambiguous
>>> and simple, and consistent with text-align/etc.
>>> In the future when we have 2-axis floats (as in the Page Floats
>>> module), 'float' can become a 2-value property, consistent with the
>>> proposals for background-position and scroll-snap-align.  If you
>>> specify one value, it will duplicate to the second value (as normal
>>> for CSS).  The default float-reference (inline) will only pay
>>> attention to the inline-axis value, so the extraneous block-axis value
>>> is ignored (similar to how scroll-snap-align only pays attention to
>>> the relevant axis).  For the 2d float references (column, region,
>>> page), saying "float: start" will just put you in the start/start
>>> corner, which seems fine.
>> For the moment, page floats are not 2D, they are 2x1D. As in, they can be
>> floating either in the inline direction or in the block direction, but not
>> both, so your proposal wouldn't quite work. float-reference, as currently
>> specified, does not solve this. It does for float-reference:inline, as you
>> described, but not for the other values, since the current behavior allows
>> either block or inline, and your syntax would also allow for 2D floating.
> This is the wrong thing.  Current floats are definitely 1d - they only
> float in the inline axis (or get pushed along the block axis, but
> that's irrelevant to specifying their desired position).  Page floats
> and similar, though, are definitely 2d. You can't specify just one
> axis.  If you float to the top, you need to know whether to go left or
> right when you're not the full width.

I suggest you have a look at the page-float spec. Currently you can
specify float:top, but not float: top left. Of course the spec
needs to say what happens when you don't take the full width (and it
does), but that's not the same as saying that the author needs to
be able to position arbitrarily in 2d.

There are use cases for full 2d positioning, but so far, that had
been pushed to level 2.

>> We can solve this with more values on float-reference or more properties,
>> but I don't really want to conclude on start/end vs inline-start/inline-end
>> as values to the float property before we answer that question.
>> Quick proposal in that direction:
>> float-axis: auto | inline | block | both
>> float-reference: bfc | page | column | region
>> auto would compute to inline for bfc, and to block for for the other values.
> No need for this.  Just let float takes 1 or 2 values, with the
> 1-value duplicating to fill the missing one.  Then the float-reference
> dictates whether the float cares only about inline, or about both,
> similar to scroll-snap.
> (scroll-snap-type is more explicit about axises, because they're
> independently valuable.  Floats, at least currently, dont' do that -
> the two types of floats imply either "inline" or "both" axises.)

No, they don't. At least not as currently specified. Not saying we
shouldn't extend to support "both" later (we should), but so far
we don't have it.

 - Florian
Received on Thursday, 5 November 2015 00:15:03 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:54 UTC