Re: [css-overflow] fragments vs paginate

> On Mar 18, 2015, at 7:13 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> On Wed, Mar 18, 2015 at 6:21 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>>> On Mar 18, 2015, at 2:02 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> I don't know if we really need a separate property for this.  It's not
>>> an independent concern; it only applies when you're fragmenting.  We
>>> could probably just (later) allow an <integer> argument after the
>>> "paginate" keyword, so you'd write "continue: paginate 2;" rather than
>>> "continue: fragments; n-up: 2;".
>> 
>> Hmm. Maybe, but that seems odd to me. The '2' would only apply if it was paginate, so it's mere presence would indicate that that your fragments required a control to see them all (which is mainly how paginate differs from fragment). So, I don't know how it would be better than 'continue: fragments 2;'.
> 
> "fragments 2" doesn't indicate "this stuff is paginated", while
> "paginate 2" does.  

That's why I don't think adding a number to that property adds clarity, while giving it its own property does. "paginate 2" makes me wonder what "fragments 2" does, if fragments and paginate are valid choices for the first spot, and a number is valid for the second spot. If the number is only useful for triggering one of the component values, and two of the component values are identical aside from what the number does to them, then that just makes it confusing.  

> And "paginate" is definitely better than
> "fragments 1".

Sure, because there is no hint what the number is for. But it seems like a logical construction of a number is OK to have in that spot, and 'fragments' or 'paginate' are ok to have in the first spot. 

> It also feels better to reserve the "fragments" syntax space for any
> future fragments-related options we might need, rather than
> immediately merging it with the "paginate" case.

I'm not sure I understand. You wouldn't also have a 'fragments' value? If you mean you would call it something else, like 'clone', then I agree. I was using the term from the draft for this part of the conversation, because I was trying to make one point at a time. 

If you are saying 'continue: fragments' is not a useful value at all, then I disagree, but at least your logic makes a little more sense. 

>> And if it's only advantage over 'continue: fragments; n-up: 2;' is saving some space, it doesn't seem worth it. Having a separate property seems more clear, and allows that property to be set independently.
> 
> If two things aren't realistically useful to cascade separately,

I think it is useful to cascade separately because it is more clear, and it is not realistically useful to the author to have the separate ideas squeezed into the same property. The idea that the remainder after the break should generate  cloned boxes to flow into is one idea. The idea that  all but some number of these boxes should be hidden, with page "turning" controls is a different idea, and deserves its own property with a clear name. As a separate property, it wouldn't need to be tied to this particular way of generating fragment chains, but could be used on region chains, however the boxes are generated, even of different sizes. 

> there's not much reason to make them separate properties. 

I obviously disagree. Since 'n-up' would be substantially what made an onscreen page different from other types of fragments, there's not much reason to make 'continue: fragments' and 'continue: paginate' into two separate values. 

> If you want
> an easy switch between 1 and 2 pages, you just do "continue:
> paginate;" vs "continue: paginate 2;"; using "continue:paginate;" and
> "n-up: 2;" doesn't help you any.

I was suggesting 'continue: fragment; n-up:2' (not 'continue: paginate; n-up:2) with the assumption (like the spec) that 'continue: fragment' had value on its own, and that the thing to turn those fragments into pages (in which at any one time most of the fragments are hidden off-screen) was a separate useful thing. 

I also think there are plenty of authors who would prefer not to have to set two or more values at a time within a single property, just to change one of them. Don't you get that sort of complaint from devs who want to change, say, a shadow blur value, without changing the rest of the value at the same time?

> We can always add subproperties in the future, of course, if
> pagination gets another knob to twiddle or something.  That would make
> it more useful to be able to cascade the bits independently.  Right
> now, though, the "number of pages" is the sole control in the
> pagination mode, so it doesn't add any new abilities to make it a
> separate property.

It's only the sole control so far because we haven't gotten very deep into what else is highly desirable. 

I would certainly hope to see a property for determining the transition from one page to another. For instance 'page-transition: [ flip | turn | push | slide ]+ [ horizontal | vertical | inline-direction | block-direction. ]*'. 'page-transition: push vertical' would give the effect of Håkon's 'overflow: paged-y', in which changing pages means the next page pushes the old one away from the bottom (or from the top, for the previous page). 

We might also want a property to say what default page to open to (which fragment to show in the first non-hidden position). That might be something like 'up-first: <positive-integer>' (that property name entirely tentative).

Received on Thursday, 19 March 2015 14:36:28 UTC