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

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


> 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... maybe it would make
sense to try to define that as 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.


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