W3C home > Mailing lists > Public > www-style@w3.org > July 2014

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

From: L. David Baron <dbaron@dbaron.org>
Date: Mon, 21 Jul 2014 17:32:00 -0700
To: Håkon Wium Lie <howcome@opera.com>
Cc: www-style@w3.org
Message-ID: <20140722003200.GA4608@crum.dbaron.org>
On Thursday 2014-06-12 15:05 +0200, Håkon Wium Lie wrote:
> 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.

Sorry for the long lag in responding.

> -----------
> 
> 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

These seem reasonable to me, although I'm a little queasy about the
"invisible controls" bit of the first two.  I tend to think that the
spec ought to require that the author provide controls when using
the first two, but can note that the UA might provide gestures or
keyboard mappings in all 4 cases.

Otherwise I think there's a significant risk that the user will
either have no idea that there are more pages, or know that there
are more pages but not know how to get to them.

> -----------
> 
> 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/

Yes, I think this probably makes more sense in the paged media spec.
I haven't considered it closely, but it seems reasonable at first
glance.

> -----------
> 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.]

Yeah, I'm a bit hesitant to add these to all elements.  It seems a
bit misleading to do that when they only work on a small fraction of
elements.  But I don't yet have a better idea, and I agree they're
necessary.

> Events
[...]
> 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.]

I'd hope that as much as possible about scroll events can go it
cssom-view.

There might also (both here and elsewhere) be a need for
overflow/underflow events or similar, to indicate when an area that
was previously not overflowing changes to overflowing, or
vice-versa.  I think Gecko implements overflow/underflow and WebKit
implements overflowchanged (though there was an Intent to Remove
thread for blink, but I'm not sure if it was removed).

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)

Received on Tuesday, 22 July 2014 00:32:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:23 UTC