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

Thanks for this Håkon.  Your new @page selectors looks like they could help for magazine layouts  especially combined with your @area definitions.  Implementations of that in Chrome/Webkit/Mozilla/IE would be useful.  CSS3 Regions would have been ideal, but none of the implementations had region-break support, which was critical for magazine layouts.

I still think we do need some kind of templating capabilities, either in CSS or HTML.  You come close with the “running headers” in CSS Paged Media module and “running elements” in CSS Books, but it looks like they require page decorator elements to be defined by the article content.  That’s fine for simpler content presentation… but let’s say you’re building an app, like you would for a CMS that edits the presented content.  

In an app where you can edit side-swiping pages from a top menu bar, certain pages might need a different menu set - the lead page might have “Edit Title”, body text only pages might have an “Edit Text”, photo pages might have “Edit Photo”, advertising pages might have “Change Ad”, comment pages might have “Add Comment”, etc.  

Let’s say we define these menus as CSS Book/Paged Media Headers, not even sure if that’s appropriate, but I need to edit content on a page-by-page basis, just like you would edit content on an DIV-by-DIV basis on modern website CMSs.  (Click here to Edit Title, Click here to Edit Article Text, Click here to add Related Links, Add Comments, etc.. the paged media metaphor for websites basically transforms Section DIVs into individual pages)

For this top menu, let’s say you have a Running Element type, with <UL><LI> for page menus.  In your case we would have to define these <UL> menus when the menu type changes. That’s fine when I know the page structure, but when I don’t know the structure because the user defines it in the CMS, then I’d have to write in some script to add them in at every IMG, P, or whatever.

This might be easy to do, don’t know.. but the spec needs to be able to account for the fact that paged media for the web is going to involve more advanced apps that base their functionality on the page itself, which includes top-level menus that might change as you change pages, and that content might be unknown.  This functionality would typically duplicate iOS’s View Controllers, so if Chrome wants to compete against that, they need to be able to do this.

Meanwhile the display:inline-block paged example i have is at:  http://engine.futureclaw.com/page_test.html

Right now there’s a few inline-block pages, with a cover page, a category description page, a category list page, and an article page.  Each page is accessible by swiping right.  Eventually there will be all sorts of page types, like ad pages, comment pages, etc.. all from the same URL, sorta like all the section DIVs on content pages.

The article page is really long, and somehow needs to be split into several subpages.  Ideally I would like to figure out some kind of paging system that does that.  I could split the article content manually to divide up the pages, but that doesn’t seem DOM/SEO/newsreader/semantic friendly?  But since magazines tend to have unique page layouts, that might be the ultimate choice.

Another issue is floating page insertions.  We might need to make a DIV it’s own page, and something like a “.ad_page {display:page; float-page: 3}” for me to insert an ad page somewhere after the 3rd page (or near the beginning/near the end/after table-of-contents/put makeup ad right before beauty section/back cover/etc..)  These are the kind of issues real magazines face when they insert ad pages according to their advertiser wishes.

Also in the test page there aren’t images in it yet, but when it comes the article will have a whole gallery of photos, in the middle of it, covering 10 or so pages on its own, some full bleed, some 2-page spreads (if that’s possible on a double-width display), and so on.  The obvious solution would be to place the gallery images inline with the article text, but that also doesn’t seem very semantically correct? Semantically I would like article text within a <MAIN> and the photo spread in an <ASIDE> and floated to their own pages.  So you might need to add some type of “float-pages: center” support as well..  (A lot of books have center photo plates.)

Anyways hope to get these paged-media CSS implemented sooner rather than later across browsers.  Our current site is 4 years old and we tried to get it to do something similar back then in HTML/CSS, as the iPad made it obvious paged media is the way to go for usability.  Recently a lot of sites implemented full page-width content articles, instead of the typical 3 columns, but they still scroll vertically.  Eventually they’re going to want to go horizontally paged.

-bobby
---
Bobby Mozumder
Editor-in-Chief
FutureClaw Magazine
mozumder@futureclaw.com
1-240-745-5287
www.futureclaw.com
www.twitter.com/futureclaw

On Jul 28, 2014, at 4:51 AM, Håkon Wium Lie <howcome@opera.com> wrote:

> 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 Wednesday, 30 July 2014 07:50:43 UTC