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

On Fri, Nov 13, 2015 at 4:46 PM, Brad Kemper <brad.kemper@gmail.com> wrote:

>
>
>
>
>
> Brad Kemper
> On Nov 12, 2015, at 12:56 AM, Johannes Wilm <johanneswilm@vivliostyle.com>
> wrote:
>
>
>
> On Thu, Nov 12, 2015 at 8:55 AM, Brad Kemper <brad.kemper@gmail.com>
> wrote:
>
>> Hopefully I won't be the only one to reply, but I wanted to clarify a few
>> things....
>>
>>
>>
>> Sent from my iPad
>> On Nov 11, 2015, at 10:09 AM, Johannes Wilm <johanneswilm@vivliostyle.com>
>> wrote:
>>
>>
>> Hey again,
>> I have looked a bit more at the different specs. And I have some
>> questions to better understand the concerns Brad came with.
>>
>>
>> *On Exclusions vs. Visuren*
>>
>> Both the part about floats in CSS 2.1 Visuren [1] and the CSS Exclusion
>> spec [2] have instructions exactly how to do the placement process of the
>> float. As far as I can tell, the one in Visuren only works for floats that
>> relate to subsequent content, whereas the exclusion one is more general for
>> something that can be placed in some other part of the site.
>>
>> Now if we want to float up, as far as I can tell, we can't really use the
>> rules from Visuren, because we have to influence previous content.
>>
>>
>> The rules from Visuren don't have the feature for forcing the float to
>> the top or bottom, but that doesn't mean it can't be added in a way that
>> otherwise keeps everything else described there the same.
>>
>
> As I read the rules, they talk about how subsequent content should behave.
> But this would not be enough, one would also have to describe how previous
> content behaves which in turn would affect the float itself, if one does
> not describe in what way it is exempt from the rules.
>
>
> When it is at the top of the containing block, there is no previous
> content.
>
> Step 1: move it to the start start of the containing block.
>
> Step 2: left it be a left float or right float or none float (in the
> inline direction), to affect subsequent content.
>
> Step 3: There is no step three.
>
> For putting it at the bottom it would just make the containing block
> taller or cause overflow if it couldn't. For fragmenting containers it's a
> little trickier, because it needs to be placed just high enough to fit. The
> UA would probably have to compose bottom floats offscreen first to
> determine fit, in order to know what line to start them on. And they might
> need a nudge down of less than a line height, in order for their bottom
> margin to align with the bottom of the page/column/region.
>


The Visuren document mentions 9 rules to determine the placement of a float
[4].
The Exclusion spec mentions 4 steps + 2 rules to figure out how the flowing
of text around the exclusion works [5].
The Page Float draft spec mentions about 8 steps + 2 rules to place the
float [6].

I think we need something at least of this type of level of specificity if
it is to work as alternative proposal.

Now I would just extend the page float model to also work for block floats.


>
>
> The basic thing I suggested was to move the left/right/none float to the
>> beginning of the first line box of the containing block when a new property
>> (aka 'block-start', 'top', etc.) of 'float' told it to. If something else
>> had already been put there by the same value, then you'd put it right after
>> it. But the left and right floating would still work exactly the same.
>>
>> This can even be simulated with JavaScript, or by moving a float around
>> using the Inspector in your browser. Once you move it to being the first
>> thing in the box, it is still a left float or right float, in exactly the
>> way described in Visuren. Or if the inline direction part was 'none', it
>> still would be after moving it to the block start.
>>
>
> You seem to be suggesting top/down movement within one container element.
>
>
> Yes, that would be the default containing block for property values that
> moved the floats in the block direction.
>
> So that is only for that case, not for page floats that locate over a
> series of fragments, correct?
>
>
> Not correct. I thought I described a property called 'float-to' that would
> combine the general effects of 'float-reference' and 'float-defer'. It's
> possible I haven't sent that yet.
>


In that, case I think you need to write instructions that cover the area of
the 4 steps + 2 rules in the Exclusion spec and 8 steps and 2 rules from
the page float spec. That does not necessarily mean you have to write 12
steps + 4 rules, some things may be combinable, but we will need the
preceise instructions on how to place things. Not just a vague description
saying we "nodge" the float this or that way.


>
> It would be a two part value, with the second value optional. The first
> part would allow you to choose between containing-block, column, page, and
> region. It would move it to the first ancestor that matches. This is what I
> originally imagined 'float-reference' would do.
>
> The second part would be a number or 'last', to move it to a different
> subsequent column, page, or region of the same chain.
>
> What about a recipe for the stacking of such floats?
>
>
> I think I already suggested a property and how it would work.
>
> Then there is the section of the CSS Exclusion spec that talks about
>> differences between exclusions and floats [3]:
>>
>> "
>>
>>    - scope. While floats apply to content that follows in the document,
>>    exclusions apply to the  content in their containing block.
>>    - positioning. Floats are part of the inline flow and float on the
>>    line box. Authors can control how the floats move on the line box, to the
>>    right or to the left. By contrast, exclusions can be positioned using any
>>    positioning scheme such as grid layout ([CSS3-GRID-LAYOUT]), flexible box
>>    ([CSS3-FLEXBOX]) or any other CSS positioning scheme.
>>    - separation of concerns. Making an element a float determines both
>>    its positioning scheme and its effect on inline content. Making an element
>>    an exclusion only determines its impact on inline content and does not
>>    impose constraints on its positioning method.
>>
>> "
>>
>> The first of those three would not apply to page floats and top floats
>> anyway.
>>
>>
>> Doesn't it? Can't a tall float starting on the first line  (or exclusion
>> positioned at the top) be sticking out of the bottom of a short (fixed
>> height) column, and affecting (or not) the content below it?
>>
>
>
> Two parts here:
>
> 1. Do the mentioned restrictions for floats apply ("apply to content that
> follows in the document")?
>
>
> For what I've been describing? Yes.
>

As far as I read your suggestion, that is not the case. If you have a
top-float in the third paragraph of a container, and the float floats to
the top of that container, then you are affected the first two paragraphs,
that came before the float in document order.


>
> No, because it could also affect content that comes before it.
>
>
> Incorrect. It is moved first, then affects only the content that comes
> after it in its new position. It also affects content in blocks that follow
> after its own containing block, which exclusions don't.
>

What do you mean by "moved first"?


Are you saying that you will have a step 0, which is to happen before any
other part of layouting, in which you move all top floats in the layouting
order so that they appear as if they were the first childNodes of a given
block element, and all the bottom floats as if they were the last
childNodes of that block element? And then you want the exception mentioned
in the exclusion doc only apply from step 1, because your step 0 will
happen before anything else?


I think that should work for top floats, but for bottom floats, that are
also floating right/left, this would not work, AFAICT. The bottom floats
would be placed after all other content and therefore the text would not
flow into the cracks between the bottom floats.

So this is a nut to crack -- if you want to propose an alternative.


> 2. Do the mentioned restrictions for exclusions apply ("apply to the
>  content in their containing block")?
>
> Yes, at least according to the current spec.
>
>
> Only to content in the same containing block. Floats can affect content
> outside the containing block.
>

Can you explain in what sense you mean here? And in what sense this should
apply to page floats as they are currently defined?


>
> Non-overlapping is only guaranteed for other floats with the same float
> reference and the bfc has the same dimensions as the float reference. This
> means one cannot simply make a column float overlap the next column by
> setting the width to 200% or some such thing. The point of this is mainly
> to cut down on the complexity needed.
>
>
> I don't think a float can cross columns that way either. They get clipped.
> They can flow from one column to the next in the block direction, if the
> column height is restricted (they basically get sliced in two).
>
>
Are you talking about the inline floats? The page floats should be defined
in a way that they should not get clipped across fragments like that.


> The remaining two issues just seem to basically explain how exclusions
>> work and that they don't determine positioning.
>>
>>
>> There are other significant differences too. For instance, z-index
>> changes the wrapping in exclusions. This can affect page floats as
>> exclusions too, since negative margins can still cause them to overlap each
>> other.
>>
>
> negative margins... ok, possibly that would be doable. Either we forbid
> negative margins for placement calculation, or we keep them. If we keep
> them, we have the advantage of already having a pre-defined behavior.
>
>
> Real floats can have negative margins. Either way, your results with
> exclusions, even in the inline direction, are going to be noticeably
> different than traditional floats.
>
> I don't think you should restrict against negative margins. It's just a
> different model than floats, though, and should be recognized as such.
>

The page floats should never affect content outside of their float
reference. That is the way the spec is currently written and that is the
behavior that is requested for our purposes at least.


>
> Given that the point of the page float spec would be to describe
>> positioning and leave the description of how that influences text flow of
>> the content behind it to the exclusion spec, it doesn't seem like this
>> would make it incompatible either.
>>
>>
>> So my question now is: What difference would it make if we would try to
>> define the same page floats as we have them now without pointing to the CSS
>> Exclusion spec? Would we not have to end up having to describe much of the
>> same of how content flows around it as is now in the CSS Exclusion spec?
>>
>>
>> In my view, no, not if we went with something like I suggested (where the
>> vertical component just changed the line box, but kept inline floating the
>> same). We would have to describe the floats-clearing-other-floats-only
>> behavior that I suggested for a separate property, which would give us
>> vertical columns of single left floats or right floats. Even this one
>> though, is basically just like changing the order of the floats in the
>> document a little prior to applying the rules of Visuren. Conceptually it
>> is not too different from 'order' in flexbox.
>>
>
> Ok, my udnerstanding is that your proposals are meant for top/down single
> box floats, not page floats, right?
>
>
> That depends on how one defines page floats. It's using the float property
> to move an item to the block start or end) of a containing-block, column,
> page, and region, where it can then float or not in the inline direction.
>

If you want to define page floats without using the exclusion spec, then I
think in order to be able to evaluate such an alternative proposal, we need
those instructions.



>
> Moving left/right floats to the bottom is a maybe little trickier, because
>> after you move several things to the same line box, their margin boxes will
>> be aligned along the top, and more line boxes could theoretically be
>> created under them, but I think this too could be spec'ed in a useful but
>> simple way that didn't change what it means to be a left/right float, as
>> described in Visuren.
>>
>> For the exclusions version you've been working on, I don't think you'd
>> have to repeat a lot of what is in the Exclusions spec. Once you say that
>> the "floats" are actually exclusions, and that they follow all the rules of
>> the Exclusions spec, then basically you are creating syntax for positioning
>> things. I don't think you'd have to redefine anything that is in that spec
>> already. It already avoids talking about where to put the exclusions.
>>
>
> Exactly. That was the point of referring to the exclusion spec. Just keep
> it to placement.
>
>
>>
>> *On inline-start vs. start*
>>
>> I was thinking: One solution that could work with all the models would be
>> if "start" and "end" simple referred to the inline directions, and one
>> would still have to use "block-start" and "block-end" for the block
>> directions. Maybe even have "start" and "inline-start".
>>
>> Or would that break with the general naming scheme?
>>
>>
>> I think it is inconsistent with the general strategy of how we use these
>> in other things, but I'll let others speak to that.
>>
>> *On logical directions*
>>
>>
>> I worked some on this, but had input from Shinyu and Elika, and our
>> internal review at Vivliostyle made us think we are correct with the
>> current formulation (which also seems to be in line with what Elika and
>> Florian have said on the mailing list). Does anyone disagree with the
>> current formulation? And if yes, what do you think it should say instead?
>>
>>
>> Just this:
>>
>> If one value page floats were expandable into two values (as I believe
>> they should), then 'start start' is better than 'inline-start block-start'.
>>
>
>
> To me it would seem that if we extend the current algorithm for placement,
> the easiest would be to add a secondary direction that is applied only
> after the first axis placement has taken place already. "inline-start"
> currently already means "inline-start block-start" and "block-start" means
> "block-start inline-start" where the second one is the secondary direction.
> The important thing is that "block-start inline-start" and "inline-start
> block-start" do not mean the same thing.
>
>
> Typically, the horizontal direction comes first, and the vertical one
> second, when the values represent 2d axes. Given the western-centric
> preference in CSS (for initial values, etc), this would translate to inline
> direction first and block direction second.
>


Well, but we need to be able to stack in both directions.


>
> We don't typically change what each position represents to indicate order
> of execution. That would be very unusual and surprising. And writing four
> words instead of one or two would be author-hostile.
>
> With my scheme, you could still write 'float: left' and it would mean the
> same as 'float: left none'. In the same vein, 'float: top' would mean the
> same as 'float: none top'. This is consistent with other CSS constructions,
> and the rules for the other values fall out from there. 'Float:start' would
> be the same as 'float: start none' (floating inline only, which I expect
> would still get more use than block-direction floats).
>

With what you have proposed so far:

We lose the information about stacking direction, which is vital for our
purposes.

I wonder what exactly the use case is for having an easier way of doing
"float: none top" differentiating it from "float: left top"? To me it does
not seem intuitive that one of them left the text flow to the right of it
while the other one doesn't, and I'm not sure why we would have a way to
have the float at the top with no content to the right of it and not the
equivalent to have it in the upper right corner.

The current proposal allows for:

"float: block-start" which means "block-start" as the primary direction and
"inline-start" as the secondary direction.

If we add 2D as I proposed, it would also allow us to float in the other
top corner:

"float: block-start inline-end".






>
> And in the case that page floats were created via a separate property,
>> instead of just a value of 'float' (as I feel they should be), then even if
>> we don't yet add a new vertical (or bock direction) movement value to
>> 'float' itself, we should have 'start' and 'end' values for the inline
>> direction, and that should be added to an edit of the existing float spec
>> language of Visuren. Then if we ever added a block direction to 'float'
>> itself, it could be start, end, top, or bottom, to go into the second
>> position of the value. A single start or stop would indicate inline
>> direction only, just as left and right do now.
>>
>> *On the name of the spec*
>>
>> I am fine with changing the name. Or keeping it. I would in general be in
>> favor of describing both inline floats and page floats in the same spec,
>> because they both use the same properties, but I don't have a very strong
>> opinion on this. But besides Brad
>>
>>
>> Sorry, I just want to be clear. I don't feel strongly about the name of
>> the spec itself, or if there is one spec or two specs or which ones appear
>> together. What I do feel strongly about is that the property itself should
>> not be 'float' if it works close to what is described. I don't think
>> 'float:left' should ever change to a completely different alternative model
>> of wrapping text and positioning, due to the presence of another property
>> like 'float-reference'. When it does that, almost everything Visuren says
>> about floats no longer applies, and is replaced by exclusions and the text
>> that you have for placement and collision avoidance.
>>
>
> but having "float: top" will already break the placement model mentioned
> in Visuren because it affects previous content, right?
>
>
> Nope. Just one step to move it to the start of the first line box, then
> everything else in the model remains the same. The only things we are
> adding is that one step at the very beginning of the model processing. I
> keep saying this...
>
>
see above.


> I have suggested 'wrap-float' as an alternative property name that leaves
>> 'float' alone, if you want to continue with an exclusion-based version of
>> float-like positioning, in two dimensions. It's a little weird still, since
>> floats wrap too, but exclusion properties all start with 'wrap-'. Maybe
>> 'wrap-stack' would be better, since the new spec describes how to stack
>> exclusions' margin boxes against each other vertically and horizontally.
>>
>> By the way, we should also change the term "page float" regardless. It
>> isn't just pages anymore.
>>
>
> "fragmentation floats"?
>
>
> Yeah, maybe.
>
> We could have three types of floats in that spec:
>
> 1. inline floats (behave as usual)
>
> 2. fragmentation floats (behave similar to what we currently call "page
> floats", with adjustments)
>
> 3. block floats (have many of the same features as fragmentation floats,
> but cannot be deferred to subsequent containers, and "clear: top/bottom"
> may also have a different meaning or no meaning).
>
>
> Just two:
>
> 1. inline floats (behave as usual, but can be moved to top or bottom
> first). A new property is also added for vertical floating:  Prevents two
> same-value floats from being next to each other on a line, so second one
> moves down to a new line (like clearing), but still letting other inline
> content to flow around both. This is still just a "move vertically, then
> inline float as normal" kind of thing).
>
> 2. fragmentation floats (behave similar to what we currently call "page
> floats", with adjustments). Might need to have 'wrap-clear' or something to
> avoid conflict with similar vertical clearing of regular floats. Uses
> 'wrap-float' property and 'wrap-*' for other related properties, instead of
> 'float' and 'float-*'.
>


So you want to add vertical clearing to inline floats? How would that work?



>
> But yes, this is the way I see it. And if you want to do #2 first, I don't
> mind.
>
> And then if I understand your proposal right, you would not want to refer
> to exclusions for "block floats" but are ok with them being used for
> "fragmentation floats"?
>
>
> Yes, unless a better name is found.
>
>
Ok, I think I now really understand what you are proposing so far. Thanks
for that! If you can define the text flow and placement recipe, then I
think it could turn into an alternative proposal.

>
>
>>
>> and myself, what do other people think?
>>
>>
>> [1] http://www.w3.org/TR/CSS21/visuren.html#floats
>> [2] http://www.w3.org/TR/css3-exclusions/#exclusions-processing-model
>> [3]
>> http://www.w3.org/TR/css3-exclusions/#floats-and-exclusions-differences
>>
>>
> [4] http://www.w3.org/TR/CSS21/visuren.html#float-position
[5] http://www.w3.org/TR/css3-exclusions/#exclusions-processing-model
[6] https://drafts.csswg.org/css-page-floats/#page-float-placement