- From: <Cedric.Sodhi@dlr.de>
- Date: Tue, 6 Nov 2012 07:48:04 +0000
- To: <howcome@opera.com>
- CC: <www-style@w3.org>
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 UTC