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

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

From: Håkon Wium Lie <howcome@opera.com>
Date: Tue, 5 Nov 2013 00:54:16 +0100
Message-ID: <21112.13224.504815.571201@gargle.gargle.HOWL>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "Cramer\, Dave" <Dave.Cramer@hbgusa.com>, "liam\@w3.org" <liam@w3.org>, James Clark <jjc@jclark.com>, "www-style\@w3.org" <www-style@w3.org>, Bert Bos <bert@w3.org>
Tab Atkins Jr. wrote:

 > > 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); }

Perhaps. If we can align two models, good. However, Using float has
some benefits:

  - it's implemented/used for footnotes

  - it prevents the element from being floated further (this is a
    restriction in "real" flows, but typically not for elements you
    just want to push aside a little)

  - 'float-offset' works with floats:

       http://figures.spec.whatwg.org/#the-float-offset-property

Also, if we switch to 'flow-into' there may be an expectation that
implementations are based on regions and that, e.g., 'flow-from' and
other regions-related functionality would work. This may not be the
case.

One important use case for sidenotes is having them appear on the
outside of columns:

            ........ .........
            ........ .........
            ........ ...[2]... second
            ........ ......... sidnote
            ........ .........
      first .[1].... .........
   sidenote ........ .........
            ........ ....[3].. third
            ........ ......... sidenote
            ........ .........

Being able to align the sidenotes with its reference point is
important. This is supported through the "align" keyword:

  .note { float: to(sidnote align) }

How would this be solved using regions?

Anyway, I've marked the syntax as an issue.

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

There's no magic involved; the areas are explicitly named and the
content is floated/flowed into them by their names.

But, yes, there should be constraints on where the floats should
appear and it makes sense to say that floats should not move to a
previous page.

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

Think of lines as in TEI [2][3] where the <l> element marks lines in
verses. Thus, the line numbers are based on lines as defined by the
author, not as they happen to be shown on any given screen.

   http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-l.html
   http://www.ibsen.uio.no/DIGTE_Di%7CDi71.xml

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

One use case is lines of poetry where short lines (as defined by the
author) are shown on the same line (on the reader's device). E.g.:

  All the world’s a stage / And all the people in it merely players.

The added '/' makes this non-trivial, it's similar to wanting to set
different margin/padding based on whether an element end up being
block or inline.

Cheers,

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Monday, 4 November 2013 23:54:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:36 UTC