[css-overflow][css-page] paged media

Below are comments to the Editor's draft of CSS Overflow. 

  http://www.w3.org/TR/css-overflow-3/
  http://dev.w3.org/csswg/css-overflow-3/

Some comments also refer to CSS Paged Media:

  http://www.w3.org/TR/css3-page/
  http://dev.w3.org/csswg/css-page/

Comments are from several Opera employees, including implementors.

-----------

The paged-* keywords need descriptions. We propose:

  paged-x 

 overflow content is paged, and the pages are laid out along
 the x axis, in the x axis component of the writing direction.
 The UA must provide invisible controls (like gestures or
 keyboard mappings) to change pages.

  paged-y 

 overflow content is paged, and the pages are laid out along
 the y axis, in the the y axis component of the writing
 direction. The UA must provide invisible controls (like
 gestures or keyboard mappings) to change pages.

  paged-x-controls 

 as ‘paged-x’, but with added UA-specific visible controls to change pages 

  paged-y-controls 

 as ‘paged-y’, but with added UA-specific visible controls to change pages

-----------

When paged is set on the root element, we'd like for @page to be honored so that one can set margins:

@page {
  margin: 40px;
}

Perhaps this is better expressed in Paged Media?:

  http://www.w3.org/TR/css3-page/
  http://dev.w3.org/csswg/css-page/

----------

Further, to support centering the page in the viewport, it should be possible to say:

@page {
  margin: auto; 
  size: 200px 300px;
}

That is, 'auto' centers the page both horizontally and vertically.
But, perhaps this should be part of css-paged, and not css-overflow?

-----------
We think the DOM interface should be described. E.g. (with some inline
comments in square brackets):

DOM support

Two element properties that defined for paged containers:

 - currentPage (read / write): The current page being displayed. 0 is
   the first page, 1 is the second page and so on. This value is 0 if
   the element is not a paged container (but see below for root and
   BODY elements).

 - pageCount (read-only): The total number of pages in the document.
   This value is 1 if the element is not a paged container (but see
   below for root and BODY elements).

[We're not sure how ideal it is to add these properties to Element,
but that's where scrollLeft, scrollWidth & co are.]

Events

When the current page changes, or when the total number of pages
changes, a PageChangeEvent event (onpagechange) is fired. It has two
properties, exactly the same as the two element properties mentioned
above (only that both are read-only). The event is fired *after* the
page change action and is not cancelable.

If the overflow*: paged* property has been applied to the viewport
(because it was specified on root or BODY), using currentPage or
pageCount properties with the root or HTML nodes will apply to the
viewport's paged container. PageChangeEvent will in such cases be
fired on both BODY and root, first BODY, then root.

[there may be better ways to do this; we should probably do the same
as onscroll does)

Scroll events are also fired, when the user grabs a page and drags it,
and when the current page number changes. If the page change is
animated, a scroll event is fired for each animation frame. See
CSSOM-View notes below for scroll values.

[The interval between scroll event are currently left up to the UA.
Firing a scroll event for each animation frame seems like a
performance killer if the page actually uses the event for something
that happens to trigger layout or so. We may want to limit the number
of events to one per page change.]

---------------

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

Received on Thursday, 12 June 2014 13:05:51 UTC