- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Wed, 18 Mar 2015 09:36:35 -0700
- To: Florian Rivoal <florian@rivoal.net>
- Cc: www-style list <www-style@w3.org>
> 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