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

On Wed, Nov 4, 2015 at 4:14 PM, Florian Rivoal <florian@rivoal.net> wrote:
>> 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.

I know. That's precisely the thing I'm saying is wrong.

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

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

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

Right, I'm saying they need to do so *now*.

~TJ

Received on Thursday, 5 November 2015 00:28:12 UTC