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

On Thu, Nov 5, 2015 at 1:59 AM, L. David Baron <dbaron@dbaron.org> wrote:

> On Wednesday 2015-11-04 16:27 -0800, Tab Atkins Jr. wrote:
> > It's not a corner case.  All the *examples* have full-width elements
> > being floated up or down, but that's irrelevant; in practice, a lot of
> > top/bottom floats will be shrinkwrapped or otherwise sized to
> > something other than 100%. Horizontal positioning is a requirement
> > *now*.
>

If browsers are interested even in 2D floating, then all the better!

I think in that case it would be good if we could try to define the list of
restrictions of page floats (compared to regular floats) you would like to
see that you mentioned in Paris, Tab. That may cut down in some of the
complexity of trying to place them. That we can make sure that page floats
do all we need them to do, without getting so complex that they no longer
are interesting for browsers.


2D floats may still be definable reasonably easily, although one will
probably have to say something about whether it is more important that a
"top left" float is at the top or to the left, but at some stage we will
hit a level of complexity I doubt you will want to handle in a browser.
Things like making smaller floats move on top of larger ones to fill out
existing spaces, etc. are things one may want to do in printed output
though.


>
> But even if they might not be full width doesn't mean that the
> inline content flows around them on both sides.  It still seems like
> there's a difference between "float to the top, place on the left
> side, and have text flow underneath but not to the right" and "float
> to the left, place on the top side, and have text flow on the right
> but not underneath", even though both are top-left corner.  And
> there's also the third option of wrapping on both sides.
>

Currently page floats are defined as exclusions who's initial wrap-flow
value is 'both'. So the author can change the wrap-flow property's value
and thereby obtain a different result. It also means that they will behave
quite differently than inline-floats in many contexts.


>
> Or is the plan to have authors do the first two by using a mechanism
> for the third, and requiring an extra containing element that is
> width:100% or height:100%?
>


The simplified plan looked line this:

simple version:
-- only allow flowing up/down or right/left within a simple fragment
-- for the purpose of deciding how many and which floats can be placed
within the same fragment, assume that they are 100% wide/high in the
direction they are not floating in
-- if they are actually under 100% in width/height, place them in the
block-start or inline-start corner
-- to make the float have more advanced forms and take on slightly more
complex placements, use shape-outside (could be hackish)


more complex versions:
-- use 2D placement

But if the browsers all want 2D placement and don't think it will have much
of a performance cost, we can try to go there right away.


We went through some book material with Alan and Dave at the Paris F2F and
found that we could probably recreate most used book designs that the
simple version

>
> -David
>
> --
> 𝄞   L. David Baron                         http://dbaron.org/   𝄂
> 𝄢   Mozilla                          https://www.mozilla.org/   𝄂
>              Before I built a wall I'd ask to know
>              What I was walling in or walling out,
>              And to whom I was like to give offense.
>                - Robert Frost, Mending Wall (1914)
>



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