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

On Sat, Nov 7, 2015 at 5:40 PM, Brad Kemper <brad.kemper@gmail.com> wrote:

>
> Inline floats continue to be as they are.
>>
>>
>> Not according to your spec, and what you have said about exclusions. You
>> are redefining what 'float:left' and 'float:right' mean, so that they are
>> no longer floats; they are exclusions. It says that 'left' is the same as
>> inline-start or inline-end when it has the initial float-reference of
>> 'inline'. inline-start or inline-end don't say anything about them not
>> being exclusions.
>>
>
> It has a disclaimer prose about that: "Floats and absolutely positioned
> exclusions share some common traits, but in the case of inline floats they
> are not the same. Floats that are not inline floats should behave the same
> as absolutely positioned exclusions with positions and sizes manually set
> to prevent overlap between floats and to prevent floats from moving beyond
> the edges of the float reference, with the float reference being grown as
> much as needed up to its maximum extend to accommodate all containing
> floats." [1]
>
>
> And yet inline floats are redefined in this spec, including with some new
> values (logical equivalents of left and right). The new inline values and
> the old ones have different definitions than in CSS 2.1, yet doesn't go
> into the detail of 2.1, or say which parts of 2.1 need to be changed to
> support the new values.
>

It is clearly stating at the top that this is about page floats and it
explains what page floats are.

As already stated, I agree that we should probably move all floats to this
spec. Alternatively it should clearly state even more clearly that inline
floats are not specified in this spec.



> And your example for float-offset shows something with float: left also
> having float-reference and float-offset.
>

Page floats can also float to the left and right. Different from inline
floats, they do not keep their block position when floating to the sides.
Instead they are floating to the block-end/start.



> So apparently traditional floats can be involved with these properties
> somewhat, though it isn't clear to what extent. Does floating an inline
> float to a column turn it into an exclusion?
>

Inline floats stay inline floats. They don't change. They behave as they do
now.

Floats with a float reference of a column are not inline floats. They are
page floats. The same applies to all other floats that have a float
reference set to something else than 'inline'.


> Or does it "continue to be what it is" in 2.1 somehow, in spite of no
> longer floating on its original line box the way 2.1 describes? Or does it
> stay in its line box, which might be inside a 'display:inline-block'
> element or table that has no edges aligning with the column, which indeed
> may be visually outside the column due to negative margin or absolute
> positioning on that parent, yet is still somehow aligned with one edge of
> the column? Nothing in the spec describes how something can remain inline
> according to all the rules of 2.1, yet somehow align with the edges of a
> different box that might be completely separated from it by empty space. I
> had originally assumed the item would move to the reference box, but I
> don't see how that would work for an inline float that is connected to the
> linebox of its float anchor according to CSS 2.1. That's why my idea was to
> move it to a different line box for floating vertically or when floating to
> a different reference box.
>


Same as above.


>
> But besides that, the spec was until now just the "page float" spec, not
> the "float spec". I talked to David Baron about whether it should also
> cover the behavior of inline floats at the F2F in new Yoprk, and his advice
> was to add notices of "This section is not normative." to make sure noone
> could think that this spec would also cover inline floats.
>
>
> It does normatively define them, though, and in a way that is different
> than in 2.1. Then it goes on to say that floats are exclusions, with no
> qualification about inline floats until the next section. I don't see how
> you can define six values for float that are or can be inline floats,
> without saying normative statements about how they change the old or relate
> to the new.
>
> It would be so much simpler is floats and exclusions were kept separate,
> aside from properties that applied to both in similar but different ways.
>

You have made the argument that page floats should have a different name. I
can see some validity to that, although I don't think it is a problem.
Maybe this is something we should have the input on from others.



>
> However, the question came up recently again, and it seems Tab advises to
> have this spec take over all types of floats [2]. If we do that, then
> probably the name should change to the "CSS Floats or some such thing.
>
>
> I could be wrong, but I took his comment to mean the float spec needed to
> be re-described in full, in light of how the new properties change and add
> to it. I wonder if he realized that it is not intended to change actually
> floating behavior, aside from using the property name to create a special
> kind of exclusion instead.
>
> We do need to work logical properties into an updated float spec, for
> inline start and end, at least.
>

The spec has reached FPWD status and people have had time to review. The
idea to make page floats just positioned exclusions is not something I came
up with myself, but has been a suggestion by other CSSWG members, most of
which I remember Rossen. CSS Floats were also discussed at the F2F meeting
in New York and it was made clear that page floats are a combination of
positioning and exclusions. You can find some discussion about that in the
minutes related to "position-fragment".


>
> Section 6 says that [all] floats have their wrap-flow set to 'both'
>> initially. That is definitely different from existing float:left. It will
>> break existing layouts. There is nothing that says any of the new float
>> properties don't apply to inline floats (though section 9 does contradict
>> section 6's statement).
>>
>>
> Well, see above.
>
>
> Section 9 doesn't say if, how, or to what extent the new properties  apply
> to inline floats. It just says a little about how inline floats and
> exclusions are different.
>
> Are some float properties not supposed to apply to inline? It seems like
>> 'float-offset' could apply, 'float-defer' could theoretically work if the
>> inline float happened to exist within a region chain or multi-col. Snapping
>> could be useful in a single fragment environment. But all the examples only
>> show other float-references, and you say "Inline floats continue to be as
>> they are".
>>
>
> The definition of inline floats should just be followed as hitherto. If we
> move that definition into this spec as well, then it should stillbe the
> same and not be changed.
>
>
> I don't see how that's possible, since you are already giving new inline
> values for the logical 'float' properties. And this answer is still
> inconsistent with example 18 in section 7, in which an inline float is
> apparently aligned with another box and offset, which hitherto has not been
> part of inline floats.
>

In the example you mention, the float-reference is "column", so it is not
an inline float.


>
> To me current floats seem like something that should just stay like they
> are due to legacy content, but that's it.
>
>
> It is yet to be proven whether or not exclusions can effectively replace
> current floats, or whether in use some tradeoffs will become apparent.
> Until then, I want a real inline float (or float:none in the inline
> direction) that, generally, can move to the top or bottom of the container
> (or another container) while pushing aside any content that's already
> there. I want some of your other new capabilities to apply to real floats
> too.
>


There are many things one could work on. We decided to work on page floats
and have followed the general advice of various central CSSWG members. One
of the main principles of this seemed to be to use current specs that
describe behavior we need, in this case exclusions, and build on top of
that instead of trying to reinvent the wheel. That's what has been done.



>
> If page floats are actually exclusions, do properties like 'float-offset'
>> affect all exclusions, or only non-inline "floats"?
>>
>
> To me this sounds a bit like:
>
> "There is a new type of car called "police vehicles" which are cars with
> sirens on them. Ergo all cars now have sirens on them."
>
>
> Not to me. It is more like someone saying "this siren turns a car into a
> special kind of police vehicle." And "here are some other accessories that
> can be used alongside sirens to enhance those vehicles." But not saying if
> they work on other police vehicles (the ones that don't have sirens). It's
> a reasonable question to ask about that, since the spec is silent about it.
> Is silent about what applies to exclusions in general and it is silent
> about what applies to actual inline floats as we've always known them.
>

The point is page floats are a way of combining exclusions with specific
positioning patterns. It is therefore building on exclusions, the same way
floats are building on top of the display property.


>
> So no. Page floats are positioned exclusions. Anything that is in the page
> floats spec does not in any way affect exclusions in general.
>
>
>> What happens if I try to absolutely position something that is page
>> floated?
>>
> Does it become a "regular" exclusion, and does that cause some of the
>> float properties to no longer apply?
>>
>
> I guess the absolute position wins over the float property and with that
> it also loses all aspects of being a page float. But to be honest, I am not
> sure what the common practice for such cases is. What is your suggestion?
>
>
> Absolute positioning kills floating normally, so I guess it should kill
> float-like behavior of exclusions too. So yeah, I agree with you on this
> much.
>
> So then, 'not-actually-a-float: top' creates an exclusion with float-like
> characteristics, and  allows some other related properties to apply to it,
> but once you add positioning, it loses those characteristics and the other
> new properties cease to have an effect. Sounds about right.
>
> Does creating a page float change the computed value of 'wrap-flow' (it
>> seems like it). Does changing 'wrap-flow' to 'auto' turn off page floats?
>>
>
> The initial value, in the current proposal, would be "clear". So I guess
> that means "auto" = "clear" for page floats. But I am actually unsure if
> that is a good idea and what the common practice is in such cases.
>
>
> I'm not sure either.
>
> I find it utterly bizarre that some float values other than 'none' can
>> make it a non-float, and have it ignore all the 2.1 rules about floats,
>> while an entirely new and different set of rules are substituted. This is a
>> big problem, to me.
>>
>
>
> Well, it depends a bit what you understand by "float". Page floats, no
> matter how you define them, will have some seriously different behavior
> from today's inline floats. Are they still the same?
>
>
> Not if they are actually exclusions. Exclusions are defined to not exist
> when 'float' is not 'none'. They are a very separate thing. For 2D floats,
> there is no way to be a float in one direction and an exclusion in another,
> unless you go into much, much more detail about which parts you're using
> from each and how it changes what we know about each once (including the
> float baggage) when they are used together. It seems untenable to me, which
> is one reason why I think they should be kept separate.
>

They are not inline floats in any direction. When they are page floats,
they are page floats in all directions.


>
> If it is something that can remain a regular float and is tightly coupled
> with the way floats work, but in the 90deg direction, then it makes sense
> to have it part of a 'float' value.
>
> Should they have a different name?
>
>
> Yes, if one value is creating a float  and another is preventing a float
> and creating something that fundamentally different but superficially
> similar, then that second thing should not be called a float or be
> generated from the 'float' property, IMO.
>

> I am not sure myself. But also, I don't see any major issues with this. To
> me positioned exclusions seem more consistent and easier to work with while
> inline floats have the historic baggage they have.
>
>
> Some of that baggage is due to features that someone thought was useful
> when they were designing floats. Some of that will be gone in exclusions,
> and some things will just work in surprising ways for people used to floats
> and expecting float behavior/baggage/features. I think less surprising is
> generally better.
>
> I can see how one could try to define some top/bottom floats by only
> extending the behavior of current floats, although it would not seem like
> great to handle if one doesn't have a float reference,
>
>
> Why can't it have a float reference?
>

Because inline floats only relate to the box formatting context they are
in. If you extend them to do something else, they are no longer today's
inline floats.

>
> and only can affect subsequent content,
>
>
> That isn't what I described.
>

No, but that's how current inline floats work.


>
>

> has the current stacking behavior, etc. .
>
>
> Something I have said could be cured with an additional property if it was
> deemed important.
>
> I consider the simplicity of my approach to be an advantage. With just a
> few tweaks, regular, familiar floats can fulfill most of the use cases. And
> things like deferred floats and float reference can be adapted to be useful
> in more situations with regular floats.
>


I don't think what you described so far would be enough solve any of the
use cases we are thinking of when we think of page floats, which mainly
about these things that take up an entire column or page top or side, and
sometimes only a part. But also, we are missing the description of stacking
and deferring strategy.

If we had those extra parts, then maybe it could work.



>
> I don't think anyone is planning on touching them. Page floats are a
>> slightly different animal. Then there is the third thing which has come up
>> a few times which is basically "page floats that float into the four
>> corners of a non-fragmenting block element".
>>
>>
>> Yeah, the restriction against that is bizarre to me too. If I want to
>> float something to the top of its container, I have to hack the container
>> into being a region?
>>
>> .container {
>>      flow-into: me content;
>>      flow-from: me;
>>      /* now I can float a child to the top of this */
>> }
>>
>> I don't think you can float into yourself.
>
>
> You mean "flow" into yourself, right?
>

yes, you are right


>
> You can flow your own content into yourself with the 'content' keyword.
> That would create a single region, where I'm suddenly allowed to float a
> child to the top or bottom of it.
>
> But you could try to make a multi col environment and only have one column
> (visible). Of course you would have the problem that by artificially
> restricting the number of columns to 1, if the column has a
> max-height/width, and not all floats fit, then the extra floats will
> disappear into nothingness.
>
> The restriction here is not that one arbitrarily has chosen not to support
> single elements for no good reason. It is because logically, page floats
> will not be able to make use of a lot of their properties that there is a
> question of to what degree it makes sense to do this at all.
>
>
> I think floating to the top or bottom can be extremely useful, in and of
> itself, even if you don't always have a need to fragment into pages or or
> columns or regions. Defer needs those to be useful, but they wouldn't need
> to be the same fragmentainer as the float-reference in order to be useful.
>
> But given that there is interest, I think we should add an option to 2D
> float in a single block element.
>
>
> How would that work, if inline values create traditional floats, and block
> values create exclusions. An element can't be both of those at the same
> time.
>

same as above. Either a float is an inline float or a page float. If it is
a page float, it will lose the block position of the float anchor as well
as the inline position.


>
> We just then should also make clear which parts of the spec do not make
> sense for such floats.
>
>
> Yeah, or design sensible alternative behaviors for such floats.
>
> I'm not opposed to also allowing float-reference, float-defer, etc. from
>>> affecting other exclusions, I guess, but I think it would maybe need a
>>> different name (float-or-exclusion-reference?).
>>>
>>
>> I am not sure I can follow you there. Exclusions that the user places
>> manually that are not page floats are not affected by page float placement,
>> as far as I know.
>>
>>
>> Well that isn't mentioned in the spec.
>>
>
>
> See above logic about police cars.
>
>
> It is far from obvious with the way it is currently worded.
>
> But what I meant was: The spec says page floats are exclusions. If the new
>> properties were moved into Exclusions, and stopped pretending to be real
>> floats, then they would need to be renamed. But many of them would be
>> useful to regular floats too. So the name should be neutral to work with
>> real floats AND exclusions, and it should say how it affects each.
>>
>
>
> I think page floats are just as "real" as inline floats, they just work
> differently.
>
>
> Very differently. Inline floats are defined in CSS 2.1, and described
> there as "floats". Exclusions are described in the Exclusions spec as being
> incompatible with those traditional floats, and not doing anything if
> 'float' is not 'none'. The two concepts are mutually exclusive. This means
> that what everyone currently understands to be a float cannot be also an
> exclusion. Exclusions were designed to be similar to floats, but not
> floats. Therefore, exclusions are not real floats. I'd say they are
> float-like.
>
> I don't think there is any reason to move anything into the exclusion
> spec. The themes covered in the page float spec are not overlapping those
> mentioned in the exclusions spec and they are fine where they are. If we
> rename the spec to the "CSS Floats" spec, we will add more about inline
> floats.
>
>
> My stronger objection is to using a value of 'float' to create exclusions,
> which by definition are not floats. It just muddies the waters, and
> prevents solutions that are all-float or all exclusion. 'Float' should have
> a block direction component that doesn't prevent 2.1-style inline floating.
> And 'exclusion-float' or whatever it would be called for the float-like
> positioning of exclusions, should have an inline direction value that still
> creates an exclusion with 'wrap-flow'. Inline floating and wrap-flow can't
> be mixed on the same element, because they have different side effects, and
> inline floating prevents wrap-flow from working.
>

I think things should either be completely page-floats or completely
inline-floats, the way it is specified in the spec as of today. Just
floating in one direction and beign positioned in the other just seems to
make everything a lot more complicated.


>
> If we rename it to "CSS positioned exclusions in fragmentainer contexts
> spec" then it can keep the current content.
>
>
> You could actually call it whatever you want, but the inline floats and
> exclusions can't be mixed in the same element. So it should be made clear
> with every property definition which apply to floats and which applies to
> exclusions. Supposedly, most of the new properties do not apply to anything
> with any inline direction floating (the 'float-offset' example is a
> mistake?), so it confuses the situation to use 'float-*' for them, instead
> of maybe 'wrap-*', or maybe no prefix for properties that could actually
> apply to both. 100% of everything we've known as a float in the past is
> excluded from participating in these new properties that begin with
> 'float-', and that isn't right. It's like having a 'table-*' prefix for
> properties that only apply to grid.
>
> Personally, I think we should go for "CSS Floats", accept inline floats
> for what they are due to their historic background and not fiddle around
> with how they behave too much. We should then use positioned exclusion
> based floats for everything new we invent. But I'm open for other
> suggestions.
>
>
> I've given suggestions. Or did you mean for the module title only?
>
> yes


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