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

On Wed, Nov 4, 2015 at 6:44 PM, Brad Kemper <brad.kemper@gmail.com> wrote:

>
> > On Nov 4, 2015, at 8:13 AM, Jonathan Kew <jfkthame@gmail.com> wrote:
> >
> >> On 6/10/15 21:14, fantasai wrote:
> >>> On 10/05/2015 10:21 AM, Jonathan Kew wrote:
> >>>> On 5/10/15 14:25, Koji Ishii wrote:
> >>>>
> >>>> I'm personally in mild preference to use 'start' and 'end' for inline
> >>>> regardless of 1 or 2 dimensional. That's another way not to regret,
> >>>> isn't that?
> >>>
> >>> For 2-dimensional properties, however, it may be unclear to authors
> >>> whether 'start' and 'end' refer to the inline or block direction.
> >>>
> >>> In the case of 'text-align', which already accepts 'start' and 'end'
> >>> values, it's pretty clear that only the inline direction is relevant.
> >>> But I think it's much less obvious that 'float: start' would
> necessarily
> >>> refer to inline-start. We don't currently have block-direction options
> >>> for 'float', but in principle they seem like a reasonable possibility.
> >>>
> >>> If we use 'start' and 'end' now, and later extend 'float' to two
> >>> dimensions, I could see us ending up with 'float: start | end  |
> >>> block-start | block-end', which seems unfortunate. ISTM that using
> >>> the inline-prefixed names from the beginning is preferable. Or would
> >>> you suggest some entirely different names for the block-direction
> >>> analogs of inline 'start' and 'end'?
> >>
> >> I think this makes sense. I'll note though, that for <position>, I
> >> ended up concluding that unprefixed keywords and requiring a particular
> >> order was much cleaner: easier to read and author.
> >>   https://drafts.csswg.org/css-backgrounds-4/#the-background-position
> >
> > Returning to this thread.... where are we now with regard to the logical
> values for 'float' and 'clear'?
> >
> > We're ready to land an implementation of these logical values in Gecko
> -- indeed, we have been for some time now -- but face the question of
> whether to proceed with 'inline-start' and 'inline-end', as per the current
> draft text at [1], or to use plain 'start' and 'end' as suggested by Issue
> 1 there.
> >
> > Opinions have been expressed on both sides, but it's still unclear to me
> what the CSSWG's conclusions are.
> >
> > Help?
> >
> > Thanks,
> >
> > JK
> >
> > [1] https://drafts.csswg.org/css-logical-props/#float-clear
>
> I am ambivalent. I like the simpler, shorter values, but agree it would be
> odd if later we got 'float:block-start'.
>
> But here is another possibility: float axis could be determined by
> property name, instead of value. Thus, 'float' would be longhand for
> 'float-x' ('float-inline' in horizontal writing), and eventually we could
> have 'float-v' ('float-block' in horizontal writing). That would allow us
> to keep start and end as values for all.
>
This would be in line with logical equivalents of overflow-x and
> overflow-y, and could extend to background-position-x and
> background-position-y.
>
> The full longhand for float would take two values, either logical or
> physical. So 'float: left' would really be the same as 'float: left none',
> 'float: top' would be the same as 'float: none top', 'float: start' would
> be the same as 'float: start none', and (maybe?) 'float: start top' would
> be the same as 'float-inline: start; float-y: top' (possibly causing
> float-y to override float-inline' in vertical writing?).
>
>
Have you looked at the parts about the float-reference in the page float
spec [2]?

Initially it seemed logical that floats should float the same way in the
block direction as they already float in the inline direction. But when
looking further into it, it became apparent that the use cases of 'float:
none top' would be rather limited, and also that the floating would have to
happen in relation to some type of container in  order to make sense.

The most common use case for floating in the block direction that if
something floats to the top (in Latin text) it should cover the entire
length of the line. Other use cases may be that it floats into the upper
right or upper left corner. Maybe several floats in the block direction
will together fill the entire width of the container they are floating in
relation to. But seldom/never does it seem to make sense to float to the
block-start while keeping the inline position.

Or can you find a use case for this?


Btw, the current page float spec lacks the ability to do 2 dimensional
floating. We probably want 2D floating eventually, but initially we wanted
to keep it as simple as possible and get the float stacking right.
Vivliostyle is currently working on an implementation, which likely will
result in us finding issues with the current spec.

Also, I am still waiting for a list of issues/simplifications of the
current spec that the Chrome team was/is working on.



> Snapping, as in the page floats draft [1], could be with a 'float-snap'
> property added to the longhand. So, for example:
>
> float-inline: start;
> float-block: start;
> float-snap-inline: 2em;
>
> ...could also be written as this:
>
> float: start start;
> float-snap: 2em 0;
>
> ...or:
>
> float: start 2em start 0;
>
> ...or just:
>
> float: start 2em start;
>
>
> 1) https://drafts.csswg.org/css-page-floats
>

[2] https://drafts.csswg.org/css-page-floats/#float-reference-property