Re: [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 11:13 PM, Brad Kemper <brad.kemper@gmail.com> wrote:

>
> 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]?
>
>
> I glanced before writing, and looked more closely after.
>
> 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,
>
>
> 'float: none top' should make it stretch all the way across the top,
>  which I think would be very common. This is assuming 'width: auto', and
> that shrink-to-fit width only occurs when there is horizontal floating.
> Floating already turns inline elements into display:block.
>


I will try to explain my issue here in another way.

Say the float anchor is at position (15, 20)  (line, block) in a coordinate
system using some arbitrary unit of measurement. If we set the block to top
( top = 0 ) and don't influence the line-coordinate, we end up with
coordinates (15, 0) to place the float. But do we really want that? That
would mean that the float is at the top, but will start somewhere further
in the line, not at the start.


>
> and also that the floating would have to happen in relation to some type
> of container in  order to make sense.
>
>
> Sure: The containing block, or nearest containing fragment of it. This was
> my intuitive expectation, even before reading the spec (or Håkon's earlier
> spec).
>

Ok, so in case of this:

<div id="zero">
<p id="one">The first sentence</p>
<p id="two">Some sentence <span style="float:left"><img ...></span> some
more text</p>.
<p id="three">Some more text</p>
</div>

The float will per today relate to the block formatting context which
includes the entire div#zero. So the rest of the contents of p#two and
p#three will be placed so they don't overlap the float, and div#zero will
be enlarged, if necessary, so that it contains the entire float.


Now if I understand you right, you are saying that if it were "float: top"
instead, it should float to the top of the containing block, which in this
case would be p#two, not div#zero, correct? That would mean that it would
behave somewhat different than the right/left floats. And what if the
floated image is really high and slim? should the div#zero still be
enlarged so that it contains the entire float?



>
> Kind of like 'float-reference: column', if that were to also work with
> single-column parents.
>


So it would only use the column/page/region if there are no block level
elements between the column/page/region and the float? Wouldn't that mean
it would only work for columns if one chooses not to use paragraphs inside
a multicol?


> 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.
>
>
> Right. So, 'float: none top'.
>

As I understand "none" it means that it will stay at the height of the
float anchor, correct? So that "float: right none" means it will float
directly to the right of the where the float anchor is placed?

If that is the case, then "float: none top" seems like it would float to
the line position of the float anchor and the top. That's the position I
don't think is very useful most times.


>
> Other use cases may be that it floats into the upper right or upper left
> corner.
>
>
> 'float: right  top' or 'float: left top'
>


If the width of the float is 100%, both of these should give the same
result, right? This is how I would have placed the floats at the top.


>
> 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.
>
>
> I see what you're saying, given a replaced element or something with a
> non-auto width. In that case, perhaps 'float: none [start | end | top |
> bottom]' should be as though the element is wrapped in an auto-width block
> box before floating. That would put it on the inline-start side, unless
> auto margins are used on one or two sides (or 'justify-self', etc.).
>





>
> Or can you find a use case for this?
>
>
> Centering across the top when width:auto and not replaced is the main one.
>

Right, centering would make sense. But just floating it to the same inline
position of the float anchor does not seem like it would center the float.
It would just put it at the inline position of the float anchor -- which is
the thing I haven't found much use for.


>
> 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.
>
>
> I think that would be hard to separate out and change later, because then
> you need to specify a direction in the single value.
>

Until a few hours ago we had inline-start inline-end block-start and
block-end and that was therefore not an issue. It is only an issue if both
block-start and inline-start have to be called "start" only.

Besides making the float placement logic much more complex, I fear that if
we add the ability of two dimensional floats now, then the float stacking
logic will get so complex that placing floats will have an impact on
rendering speed and will no longer of interest to browsers, just us book
people who don't mind waiting 15 minutes to get output. But maybe I'm
wrong.

Even the XSL-FO version of floats [3] didn't get two dimensional floats,
correct?


Maybe we can figure out how to extend it even with using "start" and "end"
so that it will work even when we get 2D floats in a higher level of the
spec? For most content I can think of, if one can only float in a single
direction, it will likely be: top/bottom with width: 100% or right/left
with a height of 100%. So it would make sense to have those four options
easily available through a simple syntax.


> Vivliostyle is currently working on an implementation, which likely will
> result in us finding issues with the current spec.
>
>
> Experimental, right? I'm worried that you might convert a lot of content
> to doing it this way, and it would be hard to change to a better 2-value
> system later.
>

Vivliostyle is still in beta, and we are trying our best to follow
standards.


>
> Also, I am still waiting for a list of issues/simplifications of the
> current spec that the Chrome team was/is working on.
>
>
> OK.
>
> Snapping, as in the page floats draft [1], could be with a 'float-snap'
>> property added to the longhand.
>
>
> I meant "as a longhand", which could be included in the shorthand. And it
> would itself be a shorthand, taking one or two values.
>
> 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;
>
> Thoughts on this part?
>
>
>>
>> 1) https://drafts.csswg.org/css-page-floats
>>
>
> [2] https://drafts.csswg.org/css-page-floats/#float-reference-property
>
> [3] http://www.w3.org/TR/xsl11/#float