W3C home > Mailing lists > Public > www-style@w3.org > March 2015

[css-overflow] overflow vs continue (Was: [css-overflow] processing model of continue:discard)

From: Florian Rivoal <florian@rivoal.net>
Date: Wed, 18 Mar 2015 13:07:04 +0100
Cc: www-style list <www-style@w3.org>
Message-Id: <57EE76E2-BDD3-4917-BC6F-1EA4F37E1D20@rivoal.net>
To: Brad Kemper <brad.kemper@gmail.com>
> On 14 Mar 2015, at 17:51, Brad Kemper <brad.kemper@gmail.com> wrote:
> [...] but I still think that these should all be values of 'overflow' instead of a new property. Then region boxes (those using a valid 'flow-from') get the computed value of 'fragments' (or 'clone' if that's the new name) for overflow if they are not last box. If they are the last box of the region chain then they get the specified value for overflow (which might be authored as 'overflow: discard' and have the behavior you describe above for things that aren't otherwise fragmentainors). 
> Then we don't really need a new 'auto' value, and we no longer need 'region-fragment'. This reduces three properties down to one, and simplifies the conceptual load. 
> We'd have to say how -x and -y overflow works with something overflowing in a logical direction (as 'overflow: fragments | discard | paginate' only applies to the block stacking direction), but IMO we should really do that anyway. 

The overflow property seemed to be the obvious place for this, which is why overflow fragments/clone and page were initially specified this way, but it turns out it doesn't work that well.

Overflow and fragmentation are different.

Figure 5 in http://dev.w3.org/csswg/css-regions/#the-region-fragment-property gives a hint. Even if you fragment, you may have to deal with overflow, and want to use the overflow property to control what happens then. Here's a little demo showcasing that controlling overflow and controlling fragmentation are orthogonal (view in Firefox or Presto Opera).


Also, as you point out, the fragmentation values, if applied through overflow, are essentially about what happens in the block direction, which is a poor match for a property that is split into an -x/-y longhands.

These things can be worked around, and we could shoehorn both concept into a single property, but the result would be convoluted or limiting or both, and keeping separate things separate keeps the model simple, which is more important than keeping the property count low.

 - Florian
Received on Wednesday, 18 March 2015 12:07:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:52 UTC