Re: [css-overflow][css-overflow-3] logical overflow

> On 18 Mar 2015, at 13:56, Brad Kemper <brad.kemper@gmail.com> wrote:
> 
> 
>> On Mar 18, 2015, at 5:14 AM, Florian Rivoal <florian@rivoal.net> wrote:
>> 
>> I generally think that overflow-x and overflow-y should have been overflow-inline and overflow-block, but unfortunately, that ship has sailed, and I also agree with you that having both -x/-y and -inline/-block is confusing. So I am not opposed to a property like the one you suggest.
>> 
>> However, I was much more interested in either fixing -x/-y into -inline/-block or having a switch when the fragmentation values were part of the overflow property, since they are about what happens in the block direction.
>> 
>> As you know, they have now been moved off to a new property, called continue, with good reasons (TL;DR: overflow and fragmentation are different things. See https://lists.w3.org/Archives/Public/www-style/2015Mar/0292.html).
> 
> My main difference then is that I find the reasons less compelling for moving them into a new property, instead of fixing -x/-y to work better with the new values. I think for the author it is better to have one property. 

I made the same proposal in the past for the same reasons (https://lists.w3.org/Archives/Public/www-style/2012May/1197.html), so I definitely see where you're coming from. But I've changed my mind since seing that overflow and fragmentation were different things.

> The values are different things, sure, but they don't overlap (a box either overflows or fragments, not both, at least in the block stacking direction). 

They do overlap. A box can both overflow and fragment in the block direction.

Look at this example in Firefox or Presto-Opera:
http://jsbin.com/hubiri/1/edit?output

When the first column is full, we fragment and continue into the second one. But we also overflow in the block direction, in two ways:
- the text-shadow overflows in all directions, including block
- the relatively positioned "ipsum" overflows in the block direction.

The fact that we fragment does not inform what we should do with the overflow, and vice versa.

> Fixing -x/-y AND integrating the fragmentation values into the same overflow property is a double win for the author. Having two properties to set how a box either overflows or fragments is more complicated and confusing. It is also more limiting, if fragmenting means an author cannot control overflow in the other direction.

If we keep fragmentation in overflow, I agree that fixing -x and -y is important to make things sane. But I don't think we should, as discussed above. And if we don't, I am ok with still trying to get an overflow-inline and overflow-block (especially if we're going to get margin-start, padding-end, and friends), but it seems less important.

 - Florian

Received on Wednesday, 18 March 2015 13:12:11 UTC