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

On Mon, Nov 4, 2013 at 3:54 PM, Håkon Wium Lie <howcome@opera.com> wrote:
> 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

I don't understand what this means.

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

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

For example, long footnotes may be continued onto the next page.  Once
you make Regions page-aware (so they won't flow into an area from an
earlier page), then you get this for free - all the areas of the same
name are just a region flow, so if there's a max-height constraint, an
overfull area will spill to the next page's area, *and* work properly
with additional footnotes from the same or following page as well.

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

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

> 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

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

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

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.

~TJ

Received on Tuesday, 5 November 2013 00:40:04 UTC