W3C home > Mailing lists > Public > www-style@w3.org > November 2015

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

From: Johannes Wilm <johannes@fiduswriter.org>
Date: Fri, 6 Nov 2015 11:33:46 +0100
Message-ID: <CABkgm-Taqp0StOm936DDNd_zCvWUrt3EsuLdzfz1Ri0p+AFJiQ@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: Florian Rivoal <florian@rivoal.net>, "Tab Atkins Jr." <jackalmage@gmail.com>, Jonathan Kew <jfkthame@gmail.com>, fantasai <fantasai.lists@inkedblade.net>, Koji Ishii <kojiishi@gmail.com>, "www-style@w3.org" <www-style@w3.org>, Rossen Atanassov <ratan@microsoft.com>, "Elika J. Etemad" <fantasai@inkedblade.net>
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
Received on Friday, 6 November 2015 10:34:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:58 UTC