Re: [css3-exclusions] Issue 15183

On Mon, 30 Jul 2012 21:10:57 +0200, Rossen Atanassov
<Rossen.Atanassov@microsoft.com> wrote:

>> We have pretty much the same discussion every face-to-face meeting.
>
> Correct, and we would like to resolve that since there is another f2f  
> coming and it will be optimal if this issue is behind us.

I have an idea on a possible way forward, but let's first agree on
what the issue is about.

>> Floats provide both a exclusion model (wrapping text around the
>> float) collision-handling model (moving a float to the side or down  
>> when it
>> would intersect another float).  CSS exclusions provide only the  
>> exclusion
>> model, which means that authors will get page-size-specific layouts when
>> they use it with a layout model without a collision-handling model  
>> (i.e., every
>> layout model that they might use it with).
>
> This is correct and this is why this spec is about exclusions not  
> floaters and/or collision handling. If and when there is CSS3 (or 4)  
> floaters spec then I would too expect to see collision handling of  
> exclusions into it.
>
> I want to outline once again that this spec doesn't insist on any  
> particular positioning (or sizing for that matter) scheme.

I think we're all clear about that, but it seems to me that you are
missing the essence of David's complaint. The problem is not that you are
introducing an exclusion system that doesn't handle collision. You're not
doing that. You you're introducing an exclusion system that is orthogonal
to collision handling.

So yes, collisions can be handled perfectly fine *if* you chose a
positioning mechanism that deals with them. But the problem is that you
*can* chose a positioning mechanism that doesn't.

When designing css features, we usually try to make them robust, so that
careless authors can't shoot themselves in the foot too easily. For
instance, on flexbox, we spent quite a bit of time discussing the default
values of properties, so that if an author doesn't bother setting things
up too well, he still gets sensible behavior in diverse environments.

The exclusion mechanism is expressive, and it can be used to do a lot of
nice things that couldn't be done before. But
as it is, it isn't robust. Simple ways of using it will results in broken
pages when the environment is a little different from what the author was
using.

What compounds the problem for me, is that I expect this will be available
through GUI editors. In non-web GUI layout programs, making a box, filling
it with some kind of content, manually positioning it somewhere, and
ticking the "flow around me" check box is a very natural thing to do. If
we introduce exclusions, GUI web layout programs will doubtless offer this
too. The result will be pages with exclusions on absposed elements.


*******

So, here's how I think we could get out of this problem. Consider this new
property:

collision: auto | allow | avoid

The property is not inherited.

Initial value is 'auto'. The computed value of 'auto' is 'allow' on
everything except floated elements, and abspos / fixpos elements for which
‘wrap-flow’ is set to something other than 'auto', in which case it is
'avoid'.

'allow': the UA shall not take any special steps to prevent things from
colliding with eachother if the laying them out normally (according to
whichever layout model they're using) causes overlap.

'avoid': if a box with a computed value of 'avoid' ends up overlapping
another box also with a computed value of 'avoid', the first one
(according to document order) shall stay where it is, and the second one
shall be moved out of the way. How it is moved depends on its layout
mechanism.


The behavior of collision:avoid for various layout modes:

* Floats keep there current behavior, which needs to be generalized a bit
so that we know what to do when a float collides with something else than
a float.

* Abspos can be defined to do something similar: move towards the end of
the inline direction if there is enough room, or forward in the block
progression direction otherwise.

* inlines can be moved forward in flow until they reach a position that
wouldn't collide

* ...

If for some layout modes we cannot find a sensible behavior for 'avoid',
we can have it compute to 'allow'.


Benefits of this approach:

* It preserves historical behavior

* Absolutely positioned elements with an exclusion would get better
collision behavior by default, which is good if we expect these to
proliferate due to the introduction of exclusions

* Absolutely positioned elements without an exclusion can opt into a
better collision system

* Other than influencing the computed value of auto on the collide
property, everything that is currently in the exclusion spec can remain as
it is, orthogonal to the problem of handling collisions

* This does not prevent us from later introducing new properties to
defined advanced clearance behavior

Downsides:

* We actually need to define in detail what collision:avoid does on the
various layout modes

* Exclusions cannot be (correctly) implemented before the collision
property



    - Florian

Received on Tuesday, 31 July 2012 11:01:09 UTC