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

Back up a bit, the original request was "is it safe to ship
1-dimensional floats with logical directional values?" and while it'd
be ideal to figure out the final syntax for 2-dimensional floats to
answer to that question, I don't think it's absolutely required, as
long as we can agree that:

1. If no other 2-dimensional-related properties are set (e.g.,
float-reference), and
2. If either 'start' or 'end' is specified

we will handle it as 1-dimensional logical direction.

I think this makes sense given the consistency with 1-dimensional
properties such a text-align, and shipping 1-dimensional logical
directional values before we finalize 2-dimensional syntax is
beneficial. Tab's response reads to me that Tab and fantasai are fine
with this.

Can we conclude on this point first?

/koji

2015-11-13 9:29 GMT-08:00 Johannes Wilm <johanneswilm@vivliostyle.com>:
>
>
> 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

Received on Friday, 13 November 2015 19:21:12 UTC