- From: Håkon Wium Lie <howcome@opera.com>
- Date: Wed, 12 Oct 2011 17:30:39 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Håkon Wium Lie <howcome@opera.com>, David Hyatt <hyatt@apple.com>, www-style@w3.org
Also sprach Tab Atkins Jr.: > > 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? > > Oh, I see. You're specifically saying that overflow is paged in that > direction, not that overflow in that direction is paged. Yes. > So, which direction of overflow becomes paged, the block or inline > axis? Or the horizontal or vertical axis? The fact that you used > large columns in your example implies that pages are always > generated from the overflow in the inline axis. Think of it as printed paper sheets. Say, a document is printed onto three sheets. Then you lay those sheets out onto the floor, either along the x/horizontal axis, or the y/vertical axis. The GCPM paged-* values don't specify how the content should be printed onto those three sheets, but it specifies that (a) there should be sheets and (b) which direction those sheets should be laid out. > > Opera has implemeted DOM access to the paged presentations, I attach a > > code example. > > I presume you meant to attach a code example, and not just fill the > latter half of your email with lorem ipsum. ^_^ It's an attachment, now available from here: http://lists.w3.org/Archives/Public/www-style/2011Oct/att-0403/ex-js.html (It doesn't degrade gracefully, view-source is the only thing it's useful for) -h&kon Håkon Wium Lie CTO °þe®ª howcome@opera.com http://people.opera.com/howcome
Received on Wednesday, 12 October 2011 15:31:32 UTC