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

On Fri, Nov 6, 2015 at 11:06 AM, Brad Kemper <brad.kemper@gmail.com> wrote:

>
> On Nov 6, 2015, at 12:33 AM, Johannes Wilm <johannes@fiduswriter.org>
> wrote:
>
>
>
> On Fri, Nov 6, 2015 at 8:00 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>
>>
>> > On Nov 4, 2015, at 4:46 PM, Florian Rivoal <florian@rivoal.net> wrote:
>> >
>> > - I am not comfortable with deciding on the syntax of page floats
>> >  before we decide on the semantics. We've had semantics in a spec
>> >  for a while, and I am arguing for syntax based on these semantics.
>> >  If we want different semantics, let's have that discussion.
>>
>> I think we should. I'm concerned that the current semantics may limit our
>> choices of good 2D float semantics.
>>
>
> The conclusion of my last two emails  was that yes, we can have 2D light
> without having to write a lot of very complex placement logic, but their
> order will matter.
>
> "float: bottom left" means that the first priority is to float to the
> bottom. That first priority is used to determine what space in the given
> fragment is reserved for the page float in relation to other page floats.
> The second priority is "left". So it will be floated to the left most part
> of the area that has been reserved for it through means of the first
> priority floating.
>
> "float: left bottom" means the opposite.
>
> The results will differ once there are several floats within the same
> fragment.
>
>
> And if a 'float: left bottom' is followed by a 'float: bottom left',
> flowed by a 'float: left bottom', followed by a 'float: bottom left'? A
> stair step arrangement?
>


The spec's placement logic does that any particular fragment can only host
either top/bottom or left/right floats.

So in the case you mention, the first one will be placed in one fragment,
which will be able to host other left/right floats. The second will then be
deferred to the next fragment. The third is also a left-float, so it can be
placed in the current fragment. Because the left-floating is the
prioritized direction, it will be placed to the right of the first float at
the bottom of the page.


>
> 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. That's why I/we have spent the last few months trying to
figure out how to do this.




> I expect top and bottom to indicate where the float is placed prior to any
> horizontal floating. don't see a great need to stack floats vertically, and
> then wrap text around all of them. If that's needed, then another property
> can be added, such as 'next-float: vertical'. But that needs a lot of
> thought, and I'm happy if that isn't added until later.
>

One option is indeed to take away the four floats that have the inline
float direction prioritized. This is a used feature that will have to be
supported in print, but may be too complex for browsers.

However if your point just is to make the syntax be "float: start end" then
that's not a good solution -- it will break for those of us who have to
support a float on the right and a float on the left in the same fragment
anyway. That is a very common usage in print, and I suspect anyone wanting
to have these types of floats for ebooks will also want them.




>
>
> So if we change it from:
>
> "float: inline-start block-end"
>
> to just
>
> "float: end start"
>
> then we have lost a vital piece of information. So I don't think that is a
> good idea.
>
> I agree with Tab that content should normally not overload fragments, but
> it is not uncommon to have more than one float in a fragment. And authors
> should be able to predict what happens then.
>
> --
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org
>
>


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