Re: [css3-exclusions][css3-gcpm] Reconciling exclusions and floats

On Feb 18, 2012, at 4:51 AM, Håkon Wium Lie wrote:

> Rather, positioning of the exclusion should be done wrt. columns.

I agree.

> When
> there are two columns, you should be able to have an exclusion between
> column 1 and column 2 -- which is what your code above achives. When
> there are three columns, you also want the exclusion between two
> columns -- most newspapers put it between column 1 and column 2.
> 
> This use case cannot be handled with the current
> exclusions/positioning proposals from MS/Adobe. As such, GCPM is the
> more powerful alterative; in GCPM, this is handled with floats and
> float-offset:
> 
>   http://dev.w3.org/csswg/css3-gcpm/#the-float-offset-property
> 

I think that property is valuable for positioning as well. Right now with positioning you have no way of controlling how to shift a child with respect to its containing block. This is especially true if we add center positioning, where you could imagine aligning the top right point of a box with the center of the containing block, or the center point with the center of the containing block, or the bottom left point with the center of the containing block etc.

So conceptually we agree. It's just a question of syntax. You need to be able to position relative to both columns and pages and you also need control over how the child aligns to the containing block. This can be done either with an additional offset like you suggest, or with some kind of syntax that changes the alignment point of the child with the parent.

One viable approach is to add the common cases to the float syntax and hope you get enough coverage. The problem I have with that is just that it feels like we should rally behind one particular positioning scheme and beef it up, rather than keeping these two different positioning schemes (floats and positioning) and having to worry about how to add the same features to both.

>> You could imagine also allowing column based positioning too to do
>> floating to the top and bottom of columns.
>> 
>> #myImage { float: positioned; position: column; top:0 }
> 
> Yes. This seems identical to:
> 
>   #myImage { float: top }
> 
> in GCPM. If you need offsets, you can e.g. use
> 
>   #myImage { float: top left; float-offset: 10px 10px }
> 
> I'm not tied to a specific syntax, and using properties/values from
> positioning may make sense. But positioning wrt. columns and pages
> must be part of a solution.

One issue with the float syntax right now when compared with positioning is that positioning is physical, but float (because of the lack of a top and bottom keyword) is weird and has left/right meaning line-left and line-right. That means right now at least float:left and float:right map to physical top and bottom in vertical text mode. If we did add top and bottom keywords, one of the first things i would want to do is make left/right/top/bottom all be physical and then add logical keywords to represent line-left, line-right, before and after.

Since your proposal is dealing with floating in logical directions, e.g., to the "before" side of a column, you might want to consider fixing the keywords in your examples. Either introduce both the physical keywords and the logical keywords, or just introduce logical keywords. I'd hate to see us only introduce new physical keywords, though, that ended up being wrong just like the current float keywords are.

> 
> I think this is a sensible approach. But, what happens in your
> implementaiton if you position a float into a table, thereby
> overshadowing (parts of) several cells? 

I think we have a few options, and we'd probably need to explore use cases. Options include:
(1) Don't intrude into any object that doesn't let normal left/right floats intrude in.
(2) Always intrude into everything.
(3) Use a special keyword, e.g., something like your 'intrude' suggestion to indicate whether or not a positioned float aggressively goes into objects that would normally avoid floats.

Received on Monday, 20 February 2012 18:03:39 UTC