Re: [css-books] Re: [css3-gcpm] Complex Footnotes

On Sat, Oct 26, 2013 at 10:57 AM, Håkon Wium Lie <howcome@opera.com> wrote:
> Dave Cramer wrote:
>
>  > >The digital publishing interest group (Member-only) is producing a very
>  > >helpful document describing requirements for page layout from the
>  > >publishing industry, although I fear it could become rather large.
>  >
>  > Indeed! I was drafted to lead this effort by Markus and Ivan. We're hoping
>  > to have something online soon
>
> An early draft is now available, as announced by Dave:
>
>   http://w3c.github.io/dpub-pagination/index.html
>   http://lists.w3.org/Archives/Public/www-style/2013Oct/0614.html
>
> There are many interesteing cases in there. I've spent some time
> trying to style Fig 12 and Fig 13, available from here:
>
>   http://w3c.github.io/dpub-pagination/images/hamlet.png
>   http://w3c.github.io/dpub-pagination/images/PepysFootnotes.jpg
>
> The challenges, compared to simple footnotes, are:
>
>  a) two streams of footnotes, with separate formatting
>  b) footnote numbering based on line numbers
>  c) inline vs block-level footnotes
>
> ---
>
> To address a), "named areas" have been added
>
>   http://books.spec.whatwg.org/#named-areas
>
> Using this, one can define two named areas, each representing a stream of footnotes:
>
>   @page {
>     @area fn1, fn2 {
>       float: bottom; column-span: all;
>     }
>   }
>
> The areas will be generated in the order specified, so that fn1 will
> be below fn2 (as it goes to the bottom first). The areas would only
> appear on pages where they have content and, as floats, their size
> would depend on their content and 'max-height' would apply.
>
> One can then float footnote elements into the two named areas:
>
>   .fn1 { float: to(fn1) }
>   .fn2 { float: to(fn2) }

I don't understand the use of 'float' here.  This seems to just be
using Regions, and so should extend that syntax:

.fn1 { flow-into: page-area(fn1); }
.fn2 { flow-into: page-area(fn2); }

The @area blocks are automagically set up to receive their
corresponding flow.  We should probably de-magic this into some
functionality on flow-from, to, so that it'll only recieve flows from
the same page or earlier.

> In Fig 12, there are no footnote calls. This can be specified with:
>
>   .fn1::call, .fn2::call { content: "" }
>
> (But it's not necessary, as calls for elements floated into named
> areas will only be generated when specified.)
>
> To differentiate the two footnote areas, one could e.g. do:
>
>   @page {
>     @area fn1 {
>       float: bottom; column-span: all;
>     }
>     @area fn2 {
>       float: bottom; column-span: all;
>       columns: 2;
>     }
>   }
>
> Named areas are a generalization of the "footnote" area, which would
> still be easier to use for simple footnotes.

Overall, something like this seems good.

> To address b), we first need a line counter:
>
>  .line { counter-increment: 1 }
>
> (which would count elements marked up as lines, and not lines themsleves)
>
> Then number every 5th line:
>
>   .line:nth-of-type(5n)::after { content: leader(space) counter(line) }

I think line counters have been proposed before.  Your solution
doesn't scale, as it requires the author to predict ahead of time
precisely where lines will break. This should be done with a proper
specialized line counter.  Making this work correctly in a reasonable
number of cases is non-trivial, of course.

> And use the line counter to number footnotes:
>
>  .fn1::marker { content: counter(line) }
>
> Here's a sample document which uses this technique:
>
>   http://people.opera.com/howcome/2013/tests/books/e-footnotes-leaders-line-numbers.html
>   http://people.opera.com/howcome/2013/tests/books/e-footnotes-leaders-line-numbers-ah.pdf
>   http://people.opera.com/howcome/2013/tests/books/e-footnotes-leaders-line-numbers-pr.pdf
>
> This is not a complete solution. In Fig 13, some of the footnote markers have two numbers. e.g.:
>
>   40, 41 O my ... uncle
>
> This is similar to having numbered list items like:
>
>   1
>   2
>   3, 4
>   5
>
> It may be that these cases must be hand-coded.

Yes, a complete solution to this would involve non-nesting start/end
markers denoting the area being foot-noted, and then something
intelligent for printing out the lines that the area covers.  That
seems like a lot of work for something extremely niche.

> To address c), I think we need a new value on 'display'. CSS 2.0 had
> two display values either became block or inline, depending on
> context:
>
>   run-in and compact
>     These values create either block or inline boxes, depending on context.
>
>   http://www.w3.org/TR/1998/REC-CSS2-19980512/visuren.html#display-prop
>
> It seems that neigher 'compact' or 'run-in', as defined in 1998, give
> us what we need to do inline footnotes. Perhaps we need something like:
>
>   make the element inline if it takes up less than a line, otherwise
>   make it a a block
>
> Or something.
>
> I believe this display value would be useful outside of footnotes,
> too. As such, this is not a footnote-specific issue.

What are some examples that would illustrate the use of this?

~TJ

Received on Monday, 28 October 2013 17:11:48 UTC