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

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

>
>
> On Nov 6, 2015, at 11:49 AM, Johannes Wilm <johannes@fiduswriter.org>
> wrote:
>
>
>
> On Fri, Nov 6, 2015 at 7:51 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>
>>
>>
>>
>>
>>
>> Brad Kemper
>> On Nov 6, 2015, at 10:09 AM, Johannes Wilm <johannes@fiduswriter.org>
>> wrote:
>>
>>
>>
>> On Fri, Nov 6, 2015 at 6:13 PM, Brad Kemper <brad.kemper@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Nov 6, 2015, at 8:26 AM, Johannes Wilm <johannes@fiduswriter.org>
>>> wrote:
>>>
>>> Ok, maybe I misunderstood. So "float: none top" will behave the same as
>>> "float: left top"? And "float: none bottom" will behave the same as "float:
>>> right bottom"?
>>>
>>> I really feel that you only read the bottom half of my earlier email. I
>>> explained all this in detail, including those two specifically in the very
>>> first part, and reading it is almost certainly going to be faster than how
>>> long it took me to type it on my phone.
>>>
>>
>> I have really read your emails. I promise. :)
>>
>>
>>>
>>> The short answer is that "float: none top" means you are moving it to
>>> the top line and blockifying it, but not floating to the left or right. So
>>> the text (and other floats) starts under it. "float: left top" means you
>>> are also floating to the left. So the text (and other floats) starts to the
>>> right of it.
>>>
>>
>> Ok, so by specifying "none" you are making the page float stop being an
>> Exclusion. Other than that it behaves like "float: left top".
>>
>> Given that page floats are exclusions,
>>
>>
>> Well, that brings up another point. The exclusions spec says that
>> exclusions only work on non-floats. My proposal is NOT making them
>> exclusions. It is keeping the left/right part as-is, and for block floating
>> only moving them to one end of a different line box (and making it a block
>> if there is no right or left floating).
>>
>
>
> Yes, but with floats they mean today's existing inline floats. Those
> behave like they do for historic reasons. But when we create something
> entirely new that will behave differently than inline floats anyway, I
> agree with Rossen, that there is no point in recreating what Exclusions
> already do.
>
> Exclusions seem to provide us with everything we need. Authors who know
> exclusions will be able to handle page floats with ease, instead of havign
> to learn entirely new new strategies to make certain things happen (such as
> doing "wrap-flow: clear" ).
>
>
>>
>> a more intuitive way (it would seem to me) of achieving that same result
>> would be to do "float: left top" and "wrap-flow: clear" (that is how you
>> would do it for exclusions, correct?).
>>
>>
>> To me, it is simpler and more intuitive to keep them as normal floats,
>> since it is the float property we are talking about.
>>
>
> Well, yes we use the property name. And that's why I have been thinking
> that maybe we should not do that. However, the feedback so far from other
> people in and around the CSSWG has been to keep the name and with that the
> property.
>
>
>> It seems more complicated to create a dependency on exclusions, which may
>> or may not work differently than floats for left and right. I'm less
>> familiar with exclusions. Even if they are meant to be a super-class of
>> floats (are they?), it seems odd to use 'wrap-flow: clear' when I
>> haven't 'wrap-flow' at all, just 'float'. I'd rather keep floats self
>> contained, without leaking in properties and dependencies from other
>> drafts-in-progress.
>>
>
> 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]

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. 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.


>
> 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.


> 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. To me current floats seem like something that
should just stay like they are due to legacy content, but that's it.



>
> 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."

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?


> 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 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? Should they have a
different name? 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. 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, and only can affect
subsequent content, has the current stacking behavior, etc. .


>
>
> 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. 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.

But given that there is interest, I think we should add an option to 2D
float in a single block element. We just then should also make clear which
parts of the spec do not make sense 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.


>
> 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. 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. If we rename it to "CSS positioned exclusions in
fragmentainer contexts spec" then it can keep the current content.

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.



>
>
>
>>
>>
>> If they are the same, then why do we have the "none" at all?
>>>
>>> They are not the same. The first value of 'none' or 'left' are not the
>>> same for existing 'float: left' or 'float: right'. I'm not changing that.
>>> The blockifying already happens with that, along with shrink-to-fit width.
>>>
>>> For 'float: none top', I'm keeping the blockification, but not the
>>> shrink-to-fit width. shrink-to-fit width would only be for left/right
>>> values other than none.
>>>
>>> If you have 'width:100%; box-sizing: border-box;' they would look about
>>> the same, aside from maybe how vertical margins collapse or something.
>>>
>>
>>
>> --
>> Johannes Wilm
>> Fidus Writer
>> http://www.fiduswriter.org
>>
>>
>
>
> --
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org
>
>
[1]
https://drafts.csswg.org/css-page-floats/#relation_to_absolutely_positioned_exclusions
[2] https://lists.w3.org/Archives/Public/www-style/2015Nov/0092.html

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