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

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

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


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.

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.


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