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

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

From: Johannes Wilm <johanneswilm@vivliostyle.com>
Date: Sat, 19 Dec 2015 14:30:30 +0100
Message-ID: <CABkgm-QBd5bxVzBqjDXo92ympkD2mBnoM7mF57N6df_3fsE=MQ@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: Florian Rivoal <florian@rivoal.net>, www-style list <www-style@w3.org>, Koji Ishii <kojiishi@gmail.com>, fantasai <fantasai.lists@inkedblade.net>, Rossen Atanassov <ratan@microsoft.com>, Jonathan Kew <jfkthame@gmail.com>, "Elika J. Etemad" <fantasai@inkedblade.net>, "Tab Atkins Jr." <jackalmage@gmail.com>
On Sat, Dec 19, 2015 at 12:07 AM, Brad Kemper <brad.kemper@gmail.com> wrote:

> On Nov 14, 2015, at 1:47 AM, Johannes Wilm <johanneswilm@vivliostyle.com>
> wrote:
> Typically, the horizontal direction comes first, and the vertical one
>>> second, when the values represent 2d axes. Given the western-centric
>>> preference in CSS (for initial values, etc), this would translate to inline
>>> direction first and block direction second.
>> Well, but we need to be able to stack in both directions.
>> Ah, I think I see the problem. 'Right top' puts it in the top right
>> corner,  but doesn't say where to put the next 'right top' float.
>> Underneath, or to the left? Is this the issue?
> Yes
>> I think word order is too subtle to use for that, and is an anti-pattern.
>> You instead need another value, either to add as a third part ('wrap-stack:
>> right top inline', if 'wrap-stack' is the property name for creating
>> float-like positioned exclusions) or in a separate property
>> (wrap-stack-direction: inline).
> I think that could work. This is another point we should discuss in
> December.
> So I was thinking:
> Supposing the main property name is ‘wrap-stack’ instead of ‘float’, and
> it could take 2 values, one for vertical and one for horizontal (or logical
> equivalents)…
> By default, items moved to the corners would stack in the block direction
> away from that corner. So, ‘wrap-stack: start start’ would start in the top
> left corner (if we assume English or other Latin-based written language)
> and subsequent items with that same value would stack downwards.

> This default would be expressed in CSS as an initial value of ‘block’ for
> a property called ‘wrap-stack-direction’ on the containing block. Then if
> you wanted to change it, you would do ‘wrap-stack-direction:inline’, and
> the exclusions would stack in the inline direction away from the corners.
> Because the wrap-stack-direction’ is set on the containing block, not the
> floater (“stacker”?), we would avoid weird stair-step arrangements. All
> stacking within a page (or other fragmentainer) would be either horizontal
> or vertical.

The problem is that you don't know how many pages you have, so it's hard to
target them correctly.

Say I have a book that flows into 200 A4 pages with a 2 column layout. Some
specific floats have a shape that mean that I need to stack them in the
inline direction. Some others I need to stack in the block direction.

I notice that the ones I need to stack inline are on pages 65, 189 and 195.
So I target those pages explicitly using a selector such as like

Then I change the page size to A5, single column. Now I need to go in
manually to find those floats again and change the css to target the
correct pages.

> Would this also be enough to allow all four corners to have floaters in
> them, stacking in two directions along the same axis (either up and down,
> or right and left, but not both)? If one stack would overlap another stack
> as the stackers are placed in source order, then that stacker that would
> have caused it is moved to the next fragmentainer.

I don't think that the four stacks overlapping is the only problem. You can
have say 15 different floats of different shapes all float into the
top-left corner, with different stacking directions until both the entire
left and the entire top side are full. Then you get another top float that
goes top-left. Should this float now be placed in a second row of floats or

In general, I would prefer to go from being very restrictive (and
interoperable across browsers) using a few simple rules, and then possibly
be less restrictive in a future version. I think that is much better rather
than opening up for all kinds of floats only to discover that they end up
working very different from browser to browser and OS to OS with floats
ending up in very strange places so that authors end up using JavaScript
instead to get somewhat similar behavior across browsers.

Just having floats stack either vertically or horizontally within a single
fragment is already covering a very large percentage of common design. If
we add now add the ability to float into all four corners, I think this
could be useful for a lot of content. For very advanced layouts, one
probably won't get around using scripting anyway ever. But it may be that
we can go further than that, even now. Just let's make sure not to rush to
something that ends up not useful.
Received on Saturday, 19 December 2015 13:31:07 UTC

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