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

On Sat, Nov 7, 2015 at 1:12 AM, Brad Kemper <brad.kemper@gmail.com> wrote:

>
>
>
>
>
> Brad Kemper
> On Nov 6, 2015, at 12:15 PM, Johannes Wilm <johannes@fiduswriter.org>
> wrote:
>
>
>
> On Fri, Nov 6, 2015 at 8:43 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>
>>
>>
>> On Nov 6, 2015, at 10:26 AM, Johannes Wilm <johannes@fiduswriter.org>
>> wrote:
>>
>>
>>
>> On Fri, Nov 6, 2015 at 6:39 PM, Brad Kemper <brad.kemper@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Nov 6, 2015, at 2:33 AM, Johannes Wilm <johannes@fiduswriter.org>
>>> wrote:
>>>
>>> This seems complicated and unnecessary to me, and breaks the normal
>>>> expectations of horizontal coming first when two values represent two axes
>>>> (X and Y, horizontal and vertical). And it is way too subtle to expect
>>>> authors to easily figure out that this ordering is significant to float
>>>> stacking.
>>>>
>>>>
>>> Well, floats are a complex thing, and we are trying to get it right
>>> rather than provide a lot of features that will just end in content
>>> breaking for no good reason.
>>>
>>>
>>> My proposal keeps most of the complexity confined to what we already
>>> have in inline floats, and vastly limits the vertical and block direction
>>> effects to something much simpler than that. They just move the float to
>>> the beginning of a different line box (or to the end of the line box if
>>> it's 'bottom', I guess, probably), and turn it into a block.
>>>
>>
>>
>> The part that I haven't figured out about your proposal is the recipe for
>> stacking the floats and which fragment to place them in (deferring).
>>
>>
>> OK, I don't really have built in vertical stacking with text wrapping
>> around it, as such. That is where I was suggesting a separate property in
>> the future to handle that as a switch. However, I think an author should be
>> able simulate it anyway. So, to get floats stacked along the right side, do
>> something like this:
>>
>> article-content {
>>     width: 80%;
>>     float: left top;
>> }
>> sibling-floaters {
>>     width: 20%;
>>     float: right top;
>> }
>>
>> ...which you can pretty much do anyway without 'top'. But I would keep
>> 'float-defer' and 'float-reference' (as long as the initial value was 'float-reference:
>> containing-block' or whatever we call it). I don't think my proposal is
>> incompatible with those.
>>
>
> This looks close to what I started out with. But then I started to factor
> in stacking, deferring, etc. .
>
> If you have two floats that go to the left and one that goes to the right,
> and all three floats have height: 100% then I have a hard time seeing how
> that would work, if on other pages you also need to provide two top floats
> stacking underneath one another.
>
>
> I'm not following. Why do they all have to be 100% height?
>


Just as an example. The point is you have to stack them horizontally. In a
different fragment, you want to stack two or more floats vertically,

>
> The current proposal takes care of all that.
>
>
>
>>
>> So you could also have an absolutely positioned side bar to float-defer
>> floats into, which would get you a stack of floats along the side of the
>> page, with nothing under them. That would just combine 'float: top' with
>> your 'float-defer' value to float it into the top line-box of that sidebar.
>>
>> I think we have both of those points figured out pretty well in the
>> current proposal, although I am waiting for feedback from Toru Kawakubo,
>> who is trying to implement it in Vivliostyle and may find problems with
>> this proposal.
>>
>>
>> But I do accept the criticism that essentially restricting authors to
>> float to 2 of 4 corners will seem arbitrary and cannot easily be
>> communicated to authors. I think we can keep the current strategy for
>> placing floats in specific fragments and figuring out whether a specific
>> fragment is "full", while still providing the ability to float along the
>> other axis secondarily. That's what i tried to propose this morning [1].
>>
>>
>> Yeah, that just seemed more complicated and less clear, for what I
>> imagine to be a less common use case.
>>
>>
> I think it's fairly easily explained. And the second direction can be
> optional. If it is not given, it is simply line-start for block-start and
> vice-versa.
>
> More importantly though, it gives us most 2D options, while still not
> breaking when you have several within a fragment and we can use the recipe
> for stackign and deferring that we currently have.
>
>
>
>
>
>> I think one problem may be the name. "page floats" suggests they behave
>> much like our current inline floats. At one stage I was wondering if we
>> should simply change the name entirely to make it clear that page floats
>> behave differently and have a different meaning in many ways.
>>
>>
>> That's where we diverge philosophically. I want floats to be floats, but
>> left them start at the top or bottom of their block container (or some
>> other container), instead of only starting on the line box they originated
>> from. That seems way simpler to me, and probably easier to implement by
>> using existing float code. I don't think adding new values to 'float'
>> should make it into an entirety different animal, especially if we have to
>> then explain how the 'left' and 'right' values possibly behave differently
>> than before whenever you also move the float to the top or bottom.
>>
>
>
> I can see our philosophical difference there.
>
>
>
>>
>> Also the relation to Exclusions wasn't clear initially. When I started on
>> this, one of the first questions other people in the CSSWG came with was
>> whether this was going to be some kind of alternative proposal to CSS
>> Exclusions.
>>
>> Which it is not supposed to be. It's merely a way of placing exclusions
>> in relation to a fragment series. We already have exclusions, so there is
>> no need to redo the part about page floats that can evenly well be
>> explained be handled by letting them be exclusions.
>>
>>
>> But floats are not exclusions, and exclusions are not floats. Exclusions
>> don't have collision avoidance, their scope is different, they aren't part
>> of the inline flow or connected to line boxes, and they can be positioned
>> without becoming non-floats. Something that only applies to exclusions
>> while loosing all uniquely float-like behavior should not be part of the
>> 'float' property, they should be part of the Exclusions spec.
>>
>
>
> Well, page floats, as currently defined, are exclusions that are
> positioned in a specific way. Exclusions are not page floats though.
>
> Exclusions are not about placement or collision avoidance. It therefore
> makes sense not to have this in the exclusions spec, but rather to depend
> on it and not redefine everything from scratch.
>
>
> If it is only a special kind of exclusion, it should be in the exclusion spec,
> and 'float' should not contain properties that create exclusions
> masquerading as floats. I would protest that.
>


I think we just have to accept that we disagree on that point. One could
also say that "floats change the display property of elements, ergo floats
should be put into a spec together with the display property".



>
> But if many more think that page floats should be named something else,
> then I would find that ok.
>
> From my perspective: Today's inline floats, seem to be less than perfect,
> especially when it comes to stacking.
>
>
> Sure. But many authors have a lot of experience and expectations with
> them. Their behavior is familiar and well used.
>

And those floats can only move along one axis in the current block
formatting context. There is no float-reference, no 2D floating, no
deferring, no complex relation to the float anchor, etc. . In short: they
are not the  same and noone can know how to use page floats just from
having using right/left floats, no matter how you define them.



> But I understand that this is not something we can do anything about,
> because so much content exists that depends on them being like they are. I
> just think that for something new, we should not let us lock down by that.
>
>
> I think that whether you use floats or exclusions, you should have the
> ability to move it to the top or bottom or corners, and then have behave in
> predictable, easy to understand ways. My proposal does this with floats, in
> a very simple but valuable way.
>

An alternative proposal would probably need to address stacking and
deferring. There not to be concrete rules how to handle these, as the
current proposal has, so that output is predictable for authors.

Just saying that something floats to the top left will work for one single
float, but doesn't give us enough information once we have more floats.

We would need to be able to do at least what we can do with the current
proposal in terms of page designs: we need to be able to stack horizontally
on some pages and vertical on others.



> And btw, I am not against having a way of placing exclusions in relation
>> to a fragment series too. But I also want that as a capability of real
>> floats, and to have a way to move a real float to the top or bottom.
>>
>>
> That would be the third type of float. As mentioned, it would not be able
> to make sue of deferring and the clear property...
>
>
> Why not? An inline float can be in a fragment chain.
>

I am talking about floats with flat references to a single block element.


> maybe it would make sense to try to define that as an extension of
> existing floats.
>
>
> Maybe with the word "Floats" in the title? One might reasonable expect
> something called "CSS Page Floats" to be an extension of existing floats.
>
> Or oen could just say that we do all the new exclusion-alike things on top
> of the exclusions spec to be consistent. Not sure.
>
>
> Or a spec called "Level 2 Floats and Exclusions".
>
>
>
>>
>>
>>>
>>> That's why I/we have spent the last few months trying to figure out how
>>> to do this.
>>>
>>>
>>> And thank you for that. There is a lot to like, and it is an excellent
>>> start that got me thinking deeper about vertical floats. I'm sorry I didn't
>>> respond to it earlier.
>>>
>>
>> [1] https://lists.w3.org/Archives/Public/www-style/2015Nov/0101.html
>>
>> --
>> Johannes Wilm
>> Fidus Writer
>> http://www.fiduswriter.org
>>
>>
>
>
> --
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org
>
>


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