Re: [css-figures][css-multicol][css-overflow] Ten CSS One-Liners to Replace Native Apps

Bobby Mozumder wrote:

 > > Yes. Ultimately, the author needs control as to how much goes into a page.
 > > (And that page may not be full screen)
 > 
 > Manually inserted breakpoints in the content should be used to
 > determine page breaks. It really isn’t optimal when auto-generated,
 > since authors tend to group content into pages/spreads/sections
 > anyways. Auto-breaking only works for single flows of text, like a
 > book. In a magazine layout, some pages might overflow vertically
 > before going over the the next page, which is fine.

There are many kinds of web devices and if you leave it to authors to
manually set page break, small screens will still see a lot of
scrolling. Which may be ok; "scroll within section -- page to next
section" certainly has a use. In the past, I have created these by
giving each section its own (scrolled) HTML file, and using @layout [1] to
page between sections. However, this is not a DOM-friendly solution
and forcing a multitude of files seems unnecessary. 

[1] http://books.spec.whatwg.org/#spatial-layout-of-pages;-@layout

In order to address the use case, we would need a flag to signal that
only manual page breaks should be honored, much like 'hyphens' has
'manual' and 'auto' values.

[2] http://www.w3.org/TR/2011/WD-css3-text-20110901/#hyphenation

It makes sense to express this at the same time as declaring a
preference for paged layouts. However, there is a combinatorial
explosion in the waiting; we would double the number of "paged-*"
keywords from 4 to 8. Alternatively, we can express the parameters
(x/y, controls/not, manual/auto) in a functional notation. E.g.:

  overflow: paged(x auto);

Which probably should be the default parameters, so we could just say:

  overflow: paged;

To achieve your manual-only page breaks, you would say:

  overflow: paged(manual);

Or something.

(The presence of the 'overflow-x' and 'overflow-y' properties
complicates the picture somewhat; my preference would be to only allow
the paged* values on 'overflow'.)

 > Also the pages need their own templates. It’s not enough to just
 > flow content over to the next page. Each page likely would have
 > it’s own margins/headers/footers/column layouts/logos/page
 > #/section#, etc. Magazine layouts don’t like having their page
 > layouts repeated, it becomes boring and tedious.
 > 
 > For example, the initial page might need a unique template with
 > lots of white space around lead paragraph and a cover photo before
 > breaking to the next page.

We should be able to address these use cases, while also making sure
the design remains responsive.

Let's see. White space can easily be added around the lead paragraph with
something like:

  p.lead { margin: 2em 4em }

The cover photo can be put in the background of the first page with:

  @page :first { background: url(cover.jpg) } 

Or, if you want it to push aside other content, you can float it:

  img.cover { float: top; column-span: all }

 > The 2nd/3rd/etc.. pages might have be just a full width multicolumn
 > text, with smaller top margin and footer logos.

You can change the page box of the (say) second page with:

  @page :nth(2) { margin-top: 4em }

Footer logos can be floated to (say) the third column on the second page with:

  footer { float: bottom; float-defer-column: 2; float-defer-page: 1 }

  http://books.spec.whatwg.org/#page-selectors

 > The final page might need it’s own template as well, with a big
 > lower margin and separate appendix.

Being able to address the last page is not in the spec, but it should be easy to add:

  @page :last { margin-bottom: 4em }

It may be best to have the appendix appear at the end by simply putting it there?

 > There might be intermediate photo spreads, some full bleed, some with margins.

You can say:

  figure { float: top; float-reference: page }              /* page box is the container */
  figure.bleed { float: top; float-reference: bleed-box }    /* bleed box is the container */

  http://figures.spec.whatwg.org/#setting-the-page-float-reference:-float-reference

 > I do fully support paged layouts, with swipe-left/right. While
 > scrolling is great for short text, paged media works better for
 > long-form articles. It also works great for photo galleries, which
 > is why you see a lot of photographer portfolio websites use
 > horizontal scrolling, as there’s a natural tendency to scan
 > horizontally.

Yes. Is this the case even for scripts that are written vertically? I
have a theory that horizontal gestures on tablets is more natural than
vertical gestures due to how human arms are contructed; the elbow/wrist
are the axis of rotation when making swiping gestures and it seems
easier to make horizotal movements on tablets. On phones, I think it
easier to make vertical gestures with my thumb, especially when only
using one hand.

 > But it won’t work without more layout control. I really think
 > something like the new <TEMPLATE> tag should be used to define page
 > templates for overflow:paged. This would be similar to inDesign’s
 > page templates, and having the browser add these pages as needed
 > when content overflows.

I wouldn't want to use a tag, if we want templates they should be
expressed in CSS. I'm not convinced we need a new templating
mechanism, though. First, I'm worried that template-writing authors would
only cover a limited range of screens -- smaller and biggers screens
than normal would typcally be left without templates. I'd much rather
have a responsive mechanism which naturally scales to any device --
this is my main motivation for working on CSS Figures.

  http://figures.spec.whatwg.org/#goals

Second, I think it will be hard for a new templating mechanism to
enter into browsers. By building on multicol (which all browsers
support), we can achive the same kinds of layouts with relatively
simple modifications to implementations.

 > Meanwhile, I have an example design based on inline-blocks, instead of overflow: paged-x.  

Where do I find it?

 > There are also lots of real-world example magazine layouts to
 > peruse on issuu.com, as well as creative page layouts on
 > polyvore.com.

Indeed.

 > Thanks for your time!

Likewise -- we're on the same page :-)

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

Received on Monday, 28 July 2014 08:51:41 UTC