Re: [css3-gcpm] paged presentations, page floats, paged navigation between documents

David Hyatt wrote:

 > >  html {
 > >    overflow: paged-x;
 > >    height: 100%;
 > >    columns: 20em;
 > >  }

 > I like using overflow (Robert O'Callahan and I shared that idea in
 > a discussion years ago), but it's a bit weird given that overflow
 > is a shorthand. What does it mean to set overflow-y: paged-x? It
 > seems to me that it should be sufficient to simply have a value,
 > "paged" and the author can set it using the appropriate overflow
 > property, e.g.,
 > 
 > overflow-x: paged

This is where Opera started. The current 'overflow: paged-x' was
introduced to avoid making nonsensical statements like the one you
mention: 'overflow-y: paged-x'. From the perpective of paged
presentations, it only makes sense to set values on the shorthand
'overflow' -- not on 'overflow-x' or 'overflow-y', no?

 > I also think given that overflow was resolved to be physical, that
 > you very much need to avoid using -x and -y to mean logical
 > directions. -x and -y need to be physical only.

In my mind, x and y are physical: x is horizonatal as in how the
horizon looks, and y is vertical as in how an apple falls (no pun
intended). 

There is a "logical" component, though: by saying x/horizontal, the
writing mode will determine whether pages are laid out to the right or
left.

 > I would not have separate overflow values for showing controls.
 > Ultimately I think built-in controls are not going to be very
 > popular for this and that people are going to want to roll their
 > own. There's going to need to be some DOM API for this feature I
 > think (to avoid making people have to do all the math to figure out
 > where columns are and to have to count pages themselves).

Opera has implemeted DOM access to the paged presentations, I attach a
code example.

 > >  .ad {
 > >     float: top next-page;
 > >     column-span: all;
 > >     width: 100%;
 > >     height: 100%;
 > >  }
 > > 
 > 
 > For the new float values, I really hope these are reconciled with
 > positioned floats. For example, I would really like:
 > 
 > float: top
 > 
 > to be equivalent to:
 > 
 > float: positioned
 >
 > position: column (or whatever term we come up with to mean nearest
 > enclosing pagination context if we want to be more general)
 >
 > top: 0
 > 
 > I'm fine with the new float values but feel like we need to evolve
 > positioned floats to be the general mechanism for having control
 > over positioning within a page/column/region and then let these
 > keywords be syntactic sugar for common positioning schemes.

I agree that the models must be reconciled. From my side, it's
important that floats can thrive in a paged enviroment -- figures and
such are foten floated to the top/bottom of pages.

Where is the current spec on positioned floats?

 > > The @navigation rule is used to position other documents around the
 > > current document. This way, user gestures can be used to navigate to
 > > the. As such, the "point-and-click" metaphor of the web is extended
 > > with "navigate-through-gestures". E.g.:
 > > 
 > >  <link rel=index href="...">
 > >  <link rel=next href="...">
 > > 
 > >  @-o-navigation {
 > >    nav-up: -o-link-rel(index);
 > >    nav-right: -o-link-rel(next);
 > >  }
 > > 
 > > I think these proposed features address some important aspects of
 > > layout and navigation that CSS can and should address.
 > 
 > I saw some -o- vendor prefixes in your examples still, so you may
 > want to search for that in your document and replace.

Good point. In our implementation we have prefixed everything, down to
this level:

  column-span: -o-integer(2)

instead of the rather more simple:

  column-span: 2

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome