As of my updates from yesterday, it more clearly states what properties do
not apply to inline floats and it defines inline and page floats at the top.
As for the logical directions: They are described as if they apply to both
types of floats and as having the meaning as Florian stated it.
I have looked through past emails, and I have not found an alternative
proposal that describes how a series of page floats will interact with
oneanother taking into account their float-defer and clear properties as
well as fragments not being "filled up". Those things would have to be
described in an alternative proposal if it is to be usable for creating
page floats as we know them from print.
Thanks everyone for the input, but before we start getting very repetitive
here, may I suggest we try to find out where we don't understand oneanother
via phone call or possibly meeting in person?
On 9 Nov 2015 4:24 am, "Florian Rivoal" <florian@rivoal.net> wrote:
>
> >> As already stated, I agree that we should probably move all floats to
> this spec.
> >
> > Yes, I agree too. The details from 2.1 should be revised to include the
> 'start' and 'end' values for inline floats. Or that 'left' always means
> 'inline-start'.
>
> inline-start and (line-)left are different. both mean left in english,
> both mean top in vertical japanese, but in horizontal arabic, left means
> left, while inline-start means right.
>
> - Florian