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

Bobby Mozumder wrote:

 > 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.

Right. I think I understand your use case. It should be possible to do
with named areas & named pages. First you would define a set of named
page with a position for the menus:

  @page photo {
    @area photo-menu { position: absolute; ... }
  }

  @page ad {
    @area ad-menu { position: absolute; ... }
  }

Then you would have some makrup to define the menus themselves:

  <ul id=photo>....</ul>
  <ul id=ad>....</ul>

Then you would flow the elements to the names areas and make them
"stick", so that they remain visible on all pages that have the
"photo-menu" named area:

  #photo { flow: area(photo-menu, fill stick) }
  #ad    { flow: area(ad-menu, fill stick) }

The "fill" keyword signals that the element should be filled into the
first available space in the named area, regardless of page (as
opposed to, say, the "baseline" keyword which places the element
somewhere else).

  http://books.spec.whatwg.org/#placement-in-named-areas
  http://books.spec.whatwg.org/#fixing-and-clearing-elements-in-named-areas

This is in a not-so-developed part of the specification. Comments
welcome. Perhaps it would be better to turn the placement keyword into
a function name:

  #photo { flow: fill(photo-menu, stick) }
  #ad    { flow: fill(ad-menu, stick) }

 > 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.

Yes.

 > 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.

In which browser, on what device? 

I need to test before commenting.

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

Received on Thursday, 31 July 2014 22:08:51 UTC