W3C home > Mailing lists > Public > www-style@w3.org > November 2012

AW: [css3-multicol/...] Pagination of (block) elements needed in CSS

From: <Cedric.Sodhi@dlr.de>
Date: Tue, 6 Nov 2012 07:48:04 +0000
To: <howcome@opera.com>
CC: <www-style@w3.org>
Message-ID: <7EB1AAE5CC83CC49986920A3DDB85AB2011581AE@DLREXMBX01.intra.dlr.de>
This is very interesting, indeed. Let me try to summarize and put it into context

1) CSS-overflow allows for pagination in the sense of the subject [1]. Basically emulating paged media. The following steps are then performed as if we were to deal with actual paged media:
2) CSS-break qualifies how and where exactly the content which is paginated is broken.
3) CSS-page & CSS-gcpm specify how pagination is "decorated" and rendered.

It strikes me, though, that while CSS-page (or page in CSS21) is a consistent specification in the context of paged media, it becomes somewhat inconsistent as soon as we consider paginated content.

If we assume what I described in the 4 points above, CSS-page suddenly allows to style simple containers, because they *act* as pages. How is the apparent overlap in responsibility of CSS-page and, e.g. CSS-background resolved?

Furthermore (althought I haven't fully studied the specs of CSS-gcpm and CSS-overflow, yet), aren't GCPM and Overflow somewhat randomly separated? GCPM is said to provide means to "offers two ways to achieve [fetch headers and footers from elements in the document]" while Overflow is meat to "specify that an element of a page should handle overflow through pagination rather than through scrolling". Yet, GCPM specifies paged-x and paged-y [2].

Consider

<div>
  Lorem Ipsum long text
  <p>Dolor sit amet more text</p>
  Continuation of Lorem Ipsum
</div>

where the DIV is meant to be paginated (is that how overflow works?), but the break would fall right between "sit" and "amet" - does CSS-overflow properly break between "sit" and "amet", resulting in something similar to

<div>
  Lorem Ipsum long text
  <p>Dolor sit</p>
</div>
<div>
  <p>amet more text</p>
  Continuation of Lorem Ipsum
</div>

in the DOM? I wrote a Javascript which does this kind of recursive pagination, once, and it worked pretty well - so I wonder whether this is also the goal for CSS, it just seems a bit more difficult to decide how CSS allows for styling the breaks (to what I understand CSS-overflow is not meant for "continuous presentation" , anyway). Anyway, I think these considerations are reflected by the amount of ISSUEs in the draft of CSS-overflow...


regards,
Cedric

[1] Tab Atkins: The subject is how to render something in a paginated fashion. It is *not*, how to handle paged media, which is what the CSS-page module is adressing.

[2] Kyung-Tae Kim: I think this is what you're looking for.

-----Ursprüngliche Nachricht-----
Von: Håkon Wium Lie [mailto:howcome@opera.com] 
Gesendet: Montag, 5. November 2012 22:52
An: Sodhi, Cedric
Cc: www-style@w3.org
Betreff: Re: [css3-multicol/...] Pagination of (block) elements needed in CSS

Also sprach Cedric.Sodhi@dlr.de:

 > ... I find it important that CSS should allow for pagination of (arbtirary) content ...

+1

 > I therefore propose that CSS3 is equipped with means to paginate
 > arbitrary block-elements in a fashion similar to the following:
 > 
 > One may specify the pagination-width and -height for such elements.
 > Their values act similar to max-width and max-height values, only
 > that the block is then duplicated and the remaining content (broke
 > at breakable whitespace and block children) is put into the
 > duplicate, repeating the procedure.

Did you see these?:

   http://dev.w3.org/csswg/css3-gcpm/#paged-presentations
   http://dev.w3.org/csswg/css3-overflow/
   http://people.opera.com/howcome/2011/reader

This approach is still debated and universal support is not yet
ensured. Input from designers is most welcome.

Cheers,

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Tuesday, 6 November 2012 07:48:34 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:02 GMT