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 23:49:07 +0100
Message-ID: <21113.30179.947525.824018@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:

 > >  > > 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
 > 
 > I don't understand what this means.

The 'float' property is used for creating footnotes:

  .footnote { float: footnote }

  http://books.spec.whatwg.org/#footnotes

Both Prince and Antennahouse supports this:

  http://people.opera.com/howcome/2013/tests/books/coverage.html

 > >   - 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)
 > 
 > Nor this.
 > 
 > >   - 'float-offset' works with floats:
 > >
 > >        http://figures.spec.whatwg.org/#the-float-offset-property
 > 
 > Just use margins.

No, float-offset is different.

  http://figures.spec.whatwg.org/#the-float-offset-property
  http://lists.w3.org/Archives/Public/www-style/2007Aug/0159.html

 > > 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.
 > 
 > Yes, that's my assumption. Let's not build little fiefdoms of
 > almost-identical-but-not-quite functionality.  If this is basically
 > Regions, make it fully Regions.

I think this point is answered by your next bit:

 > > 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(sidenote align) }
 > >
 > > How would this be solved using regions?
 > 
 > It wouldn't be, because you're not flowing them together in an
 > independent portion of the page - it would be done with Positioning,
 > in some fancy new way.  I can sketch ideas for it, if you'd like.

Sure.

 > > 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.
 > 
 > Using brand new functionality, thus magic. ^_^  But anyway, I was
 > saying this in reference to explaining all this functionality with
 > Regions, which would need to gain the ability to be page-aware.

Indeed.

 > >  > 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
 > 
 > Yeah, that's valid for those kinds of cases, but I don't see how it'll
 > help in general.

There are two kinds of use cases for line numbers. One is
pre-formatted by authors (as in TEI), the other is dynamically
formatted on the readers' device. These two use cases will require two
different soltutions; there is no one "general" solution.

 > Most books aren't and shouldn't be formatted to
 > line-break in predetermined spots; it's useful for scholarship to have
 > a "standard" line numbering, but not elsewhere.

There are tons of Shakespeare and Ibsen and ... out there that have
preformatted lines. Even writs gets their line numbers frozen after
the first round of formatting. So, I'd guess there are more
pre-formatted line numbers on the web, than dynamically formatted line
numbers. As such, using leaders and line counters solves a real
problem.

 > > 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.
 > 
 > Seems reasonable.
 > 
 > > 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.
 > 
 > Yeah, definitely non-trivial.

One could possibly have a pseudo-class that reflects whether an
element ends up being block or inline:

  l { display: run-in }
  l:display-inline::after { content: " / " }

Hmm.

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Tuesday, 5 November 2013 22:49:49 UTC

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