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

Re: [css-overflow] processing model of continue:discard

From: Brad Kemper <brad.kemper@gmail.com>
Date: Sat, 14 Mar 2015 09:51:45 -0700
Cc: www-style list <www-style@w3.org>
Message-Id: <5661B490-5D26-4F8D-BAAE-FA5259558983@gmail.com>
To: Florian Rivoal <florian@rivoal.net>

Brad Kemper

> On Mar 11, 2015, at 3:18 PM, Florian Rivoal <florian@rivoal.net> wrote:
> As noted in the associated issue[1], we need to define how ''continue: discard'' works when the element it is applied to isn't already a fragmentainer.
> Rather than defining a new model according to which things may become fragmentainers, I am thinking the I should use the same approach as "continue: fragments" and create a fragment box, the only difference being that you'd only get one, rather than a sequence of fragment boxes.
> This implies that ::nth-fragment(1) would work on it, which I think is fine.
> Can I go ahead and spec it this way, or does anyone think I should take another approach?

I like this approach, 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. 
Received on Saturday, 14 March 2015 16:52:14 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:49 UTC