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

> On Mar 18, 2015, at 6:11 AM, Florian Rivoal <florian@rivoal.net> wrote:
> 
> 
>> 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

That's a pretty good proof. I'll have to give this some more thought in light of that, but I'll reply to my other thread for that. I do still want to fix -x/-y overflow, which is what this thread is about. 

...

>> 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.

Mostly agree. It would be less urgent in that case, perhaps, though for authoring I would still want my decision to overflow in one direction to be informed by knowing the direction of fragmentation.

Received on Wednesday, 18 March 2015 16:37:06 UTC