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

On Fri, Nov 6, 2015 at 5:38 PM, Brad Kemper <brad.kemper@gmail.com> wrote:

>
> On Nov 6, 2015, at 2:54 AM, Johannes Wilm <johannes@fiduswriter.org>
> wrote:
>
>
>
>> -- 'float: bottom' = 'float: none bottom ' (no left or right mentioned,
>> so no left or right floating).
>>
>> -- 'float: left' = 'float: left none' (no top or bottom mentioned, so no
>> top or bottom floating, matches existing).
>>
>> -- 'float: right' = 'float: right none' (no top or bottom mentioned, so
>> no top or bottom floating, matches existing).
>>
>>
>
> I think page floats will have to behave quite differently than inline
> floats here. If one floats to the top, one expects the float to cover the
> entire top, not to land at some arbiotrary place in the inline direction.
> Same if one wants to float to the right or left of a column/page/region.
>
>
>>
>> ------------------
>> If you accept that, and that the logical values should be in the spots
>> equivalent to Western style writing (left to right, top to bottom), then
>> the order of logical equivalents should be 'inline' then 'block'. So
>> 'float: start none' would be the same as 'float: left none' (for me), which
>> is 'float: left'. Very logical logical, to me.
>>
>>
> As mentioned in my earlier emails, this will not do it. It creates
> problems for stacking.
>
>
> The part of my email that you are quoting is about how in this two value
> property (horizontal and vertical) a single value is actually just hiding
> the initial second value of 'none' for vertical, and how to make the
> logical versions consistent with that. I fail to see how to translate
> single values into double values creates stacking problems.
>



Ok, I probably just haven't quite understood your proposal yet.

In your first example you mention "'float: none bottom' (no left or right
mentioned, so no left or right floating)". So what I am wondering here is
what happens if the float is not floating to the right nor the left if it
is not stretching across the entire width of the float reference.

I assumed that if it is not floating right nor left, it would just keep the
line position of the float reference, but as I understand now, you are not
proposing that. So what line position will it then have?


>
> So single word logical equivalents would be:
>>
>> -- 'float: start' = 'float: start none'
>>
>> -- 'float: end' = 'float: end none'
>>
>> Both of those are useful for the simple case of inline floating. For
>> block floating, just use the 2 word version. E.g., 'float: none start', not
>> 'float: block-start', and 'float: start start', not 'float: line-start
>> block-start'.
>>
>>
> inline floating only works along a single axis. The "page floats" that do
> float along two axis will need to be able to specify if the top or the left
> is prioritized.
>
>
> Again, not so with my proposal.   The mechanics of inline floating is
> unchanged, and block direction "floating" is really just moving it to a
> different line box. There is no prioritization needed, vertically you are
> not doing anything similar to inline floating (unless you also provide a
> non-none value for inline floating).
>
> If you really want to go further and provide a way for floats to stack up
> underneath each other along the right or left sides (and logical versions
> of that), then this could be handled by a separate property that we don't
> need to include now.
>

When you say "not so with my proposal", if I understand you right, you will
simply cut out four of the eight directions I proposed yesterday [1],
correct?

Taking out four of them may be OK for browsers for now, but certainly not
for print engines, so we need to make sure that the syntax can cover that.
Vertically stacking top/bottom floats seem like one of the more basic
features of floats in books and ebooks. The point of [age floats was
initially to serve books/ebooks and I've tried to adapt it to browsers as
much as possible, but taking out such vertical stacking would seem to
diminish the value of page floats a little too much for print, I am afraid.

If I may give an example from my own book, which was created using LaTeX,
in which I almost only use top floats. I tried to keep the floats separate,
on page 14, there are two top floats that stack vertically [2].


Also, that seems kind of like a basic feature if one wants to have page
floats in ebooks or in columns or regions on the web.



> A syntax such as "float: start end" is not working for that.
>
>
> Only because I don't think vertical stacking is a must-have for the first
> level, and that when we do add it, it should be through a separate property
> that is much more clear than what you proposed.
>

Same as above.


>
> ----
>> Vertical float clearing only matters if you have multiple fragments.
>>
>>
> That's the conclusion I had with page floats, which is why the float
> reference for all but inline floats only can some kind of fragment.
>
>
> The lack of utility of vertical clearing when there is only a single
> fragment does not negate the utility of floating within that single
> fragment. It just isn't necessary, is all, until you go to print the page
> or let it overflow into regions.
>
> Putting the images to the top of a conventional DIV, etc. can also be
> achieved in other ways.
>
>
> Not with the same benefits.
>
> I really don't understand why we should have to have this unnecessary
> restriction. It is useful to have this within a single fragment of the
> containing block. It would be even more useful to be able to specify any
> ancestor as the float reference, but I can wait for that feature.
>

Well, it's just that this is a third, and somewhat different way of using
floats.

1. The current inline-floats are specced in a way that they can affect
subsequent content but not prior content. They behave differently then
absolutely positioned exclusions in certain situations.

2. Page floats are all about stacking, and moving to certain fragments of a
flow of fragments and about trying to find out how to stack them correctly.
They are working like absolutely positioned exclusions.

3. 2D floats within single blocks will be able to move into all four
corners, similar to 2, but the usage of clear on them does not seem to make
sense. Nor does all the logic about moving to other containers.



>
>
> However, the feedback I have received so far indicates that people would
> also like to float in the block direction in block elements.
>
>
> Me too, but with much simpler mechanics of what that really means.
>
> They will just lose a lot of features related to deferring floats, etc.
>
>
> With what I have proposed, they would not lose deferring. I don't know
> where you get that. I was only discussing the top, bottom, and block
> direction values of 'float' and what they would do.
>
>
"Deferring" as the term is used in the CSS Page Float spec [3] refers to
the movement a float from the fragment that the float reference is in to
another fragment within that same fragmentation flow. This can happen both
be author specified with the 'float-defer' and 'clear' properties, and it
is something that is happening automatically when it is determined that a
particular fragment does not have the required space to host a particular
float.

Any change to prior fragments will potentially cause for the float
reference to move to another fragment of the flow, so there is a lot of
description exactly in what order the varies properties are taken into
account and when automatic deference is kicking in.

If, on the other hand, we don't have a series of fragments and just want to
float to the top of a particular block element, as far as I can see, we
have don't really have use for all this. So in that sense, floats with a
float reference set to a block element will behave somewhat differently.



[1] https://lists.w3.org/Archives/Public/www-style/2015Nov/0101.html
[2]
https://www.academia.edu/8883387/Nicaragua_back_from_the_dead_An_anthropological_view_of_the_Sandinista_movement_in_the_early_21st_century
[3] https://drafts.csswg.org/css-page-floats/#deferring_floats


-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org