W3C home > Mailing lists > Public > www-style@w3.org > January 2013

Re: Calling for a massive revamp of Paged Media and GCPM

From: Håkon Wium Lie <howcome@opera.com>
Date: Mon, 14 Jan 2013 15:08:04 +0100
Message-ID: <20724.4420.348613.920173@gargle.gargle.HOWL>
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Cc: "www-style\@w3.org" <www-style@w3.org>
Daniel Glazman wrote (in somewhat different order):

 > In summary, Paged Media and Generated Content for Paged Media paved the
 > way. But they were never really implemented if you except YesLogic's
 > PrinceXML and now show their limits given the new industries using
 > extensively html and CSS. I am calling for a massive revamp of these
 > documents based on Regions, Flows, Slots, Exclusions, Grids and the
 > @page rule. We're just too far behind what live paged media really need
 > from CSS.

1) It's good to see interest in this area on www-style

2) The current proposals for PM/GCPM are implemented and are used for
   creating real books. If it ain't broken, don't fix it.

3) I'd like to see code examples for your proposals

4) My own list of frustrations in this field is different from yours.
   To me, headers/footers/footnotes are solved & implemented. My top-3
   list for things needed to improve CSS-based books are:

   - line alignment between columns
   - conditional anchoring/floating of figures
   - collapsing of page numbers in index entries

Current status of CSS-based book publishing isn't too bad, though --
printed books on the NYT bestseller list are often done with CSS. 
Personally, I've printed two physical, bound, books from HTML/CSS:

  http://www.princexml.com/samples/#book
  http://www.princexml.com/samples/#ibsen

These books use a range of features, and the lessons learnt have
influenced the features described in GCPM. My conclusion is that we
can do most books in CSS now (especially if we add support for the
top-3 list above) and that we can do even more books if we continue in
the track we're in. I hope to devote more time to GCPM in the near
future.

 > In that perspective, CSS and html5 have a few major holes I would like
 > to discuss here:
 > 
 >
 > 1. the Paged Media and Generated Content for Paged Media specs do not
 >     allow content-rich headers and footers at this time.

Not so. You can make element be running headers/footer using, e.g.:

  @page { @bottom-center { content: element(footer) }}
  footer { position: running(footer) }

  http://www.w3.org/TR/css3-gcpm/#running-elements
  http://dev.w3.org/csswg/css3-gcpm/#running-elements

Prince has implemented this using a slightly different syntax; 

  @page { 
    @top { content: flow(header) }
  }
  h1 { flow: static(header) }

  http://www.princexml.com/doc/8.1/page-headers-footers/

 > 2. the Paged Media spec divides the margin of a page into 16 (!) areas
 >     where CSS can generate content from the markup through CSS rules
 >     only. At a time we discuss slot generation through dedicated
 >     at-rules and flows of content, at a time we have flexbox to nicely
 >     and precisely place data wherever we want, at a time we have Grid
 >     Layout to divide finely a layout into slots, this seems to me a
 >     suboptimal and too complex solution. It's unmaintainable from an
 >     author's perspective. It's clearly not enough to import a document
 >     coming from a word processor without dropping a lot of data living
 >     in headers and footers.

To me, the current solution seems simple and it has worked well in my
books. It allows you to say things like:

  @page { @top-center { content: "My Book!" }}
  @page { @top-left { content: "My Book!" }}
  @page :left { @top-left { content: "My Book!" }}
  @page :right { @top-left { content: counter(page) }}

Which I find quite readable.

What would these code snippets look like in your prefered syntax?

The top-* and bottom-* margin boxes are routinely used in western
publishing, and I think it would be a loss to remove them. Authors
would then have to define them themselves.

I've only rarely used the left-* and right-* margin boxes. But they
should remain for completeness.

 > 3. even if we do have header and footer elements in html5, CSS is
 >     currently to weak to allow authors to give them a rich presentation
 >     including in paged or print media, for instance allowing them to
 >     persist across the pages of a given section.

As mentioned above, GCPM supports running elements. 

  @page { @bottom-center { content: element(footer) }}
  footer { position: running(footer) }

 > 4. the GCPM module allows content "creation" into headers and footers
 >     through the 'content' property. But the functional notation content()
 >     defined in same spec only allows to retrieve the textual contents
 >     of a given element without capturing its richness. 

Again, GCPM support running elements.

 > 5. footnotes in the GCPM seem to me a tortured solution. I agree
 >     footnotes are an extremely complex problem. But wait, adding a
 >     footnote counter is easy and we have both ::before and ::after.
 >     If we flow footnotes into a footnote area defined as above in 4,
 >     we could use ::before as the counter reference that will stay with
 >     the footnote's prose and ::after as the footnote's source that
 >     remains in the main prose. All we need for it is a way of specifying
 >     generated content does not flow with its parent element. And if
 >     your footnote is a link AND the target of that link, clicking on the
 >     linkified ::after will even take you to the footnote in the
 >     footnotes' area by pure magic. We don't need all the extra stuff the
 >     GCPM spec specifies.

>From your prose, it seems you'd like to use ::before and ::after
instead of the proposed ::footnote-call and ::footnote-marker. This is
simplification, and one that would be acceptable in most cases.
However, you lose the ability to use ::before and ::after for their
normal purposes, e.g. add brackets around footnotes. Also, you need to
add a mechanism for specifying when before/after work normally
and when they work the footnote way. This adds to the complexity, so
I'm not sure we end up with a simpler solution overall.

Here's GCPM's proposal for foonotes:

  http://www.w3.org/TR/css3-gcpm/#footnotes

Using it, one can style footnote calls and markers with:

  ::footnote-call {
    content: counter(footnote, super-decimal);
  }
  ::footnote-marker {
    content: counter(footnote, super-decimal);
  }

The declarations above can be put in a default style sheet. All that
the author has to do is to say:

  .note { float: footnote }

If you use the before/after pseudo-elements, you cannot rely on the
default style sheet the same way. Perhaps you would need to write:

  .note { float: footnote }

  .note::before {
    content: counter(footnote, super-decimal);
  }
  .note::after {
    float: back-to-prose;
    content: counter(footnote, super-decimal);
  }

Other suggestions?

As for target-pull(), it's there mostly to deal with legacy markup and
not an essential part of a footnote solution. 

I also believe there's a value in telling the formatter that something is a
footnote (as opposed to a generic float). Footnote rendering is
complex and heuristics may be necessary at times. For example,
consider this makrup:

  <p>A sentence consists of words. <span class="footnote">Most often.</span>.</p>

When the .footnote element is whisked away, it leaves a foonnote call
behind. The footnote call should be right after "words.". To achieve
this, the space after "words." must be "eaten" and this is not easily
specified. You can avoid it by chaning the markup. E.g.:

  <p>A sentence consists of words.<span class="footnote"> Most often.</span>.</p>

But that's a bit weird. Allowing implementation to use some heuristics
when positioning footnote calls may be better. But that only works
when implementations know that something is a footnote...

 > 6. similarly, bookmarks are defined by GCPM as being presentational. I
 >     disagree with that approach. A bookmark is clearly for me an
 >     annotation and annotations are content. We could use for bookmarks a
 >     mechanism totally similar to the one I outlined for footnotes above,
 >     with a slot and a flow. Simple, efficient, rich, clean.

GCPM doesn't really say what PDF bookmarks are. The CSS properties are
simply used to indicate which elements that should be bookmarks, and
at what level. It's quite simple:

  h1 { bookmark-level: 1 }
  h2 { bookmark-level: 2 }
  h3 { bookmark-level: 3 }

Which is typically hidden in the default style sheet.

What would your proposal be?

Note that the editor's draft for bookmarks are somewhat simplified compared to the WD:

  http://www.w3.org/TR/css3-gcpm/#bookmarks
  http://dev.w3.org/csswg/css3-gcpm/#bookmarks

 > 7. the main content area of a page can easily be defined as the
 >     substraction of all the flow areas defining headers, footers,
 >     footnotes, etc from the page area (Cf. terminology in section
 >     3.1 of the Paged Media spec). It means that headers, footers,
 >     footnotes and friends can easily be defined as Exclusions to the
 >     page area. Of course, it is still also possible to define a flow
 >     for the main content of a document and send that flow to specified
 >     slots/areas/grid cells/... in pages.

Again, I'd like to see code examples. 

Cheers,

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Monday, 14 January 2013 14:08:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:04 GMT