Footnotes

[darobin]

Should we just use rel=footnote? And the link back?

[frivoal]

What kind of layout mechanism do you have in mind for footnotes? This https://drafts.csswg.org/css-gcpm-3/#footnotes or something else?

The expected layout mechanism (and in particular, whether or not it relies on generated content) influences what the markup should be.

[darobin]

@frivoal At this point we're doing it in the dumbest way possible (which may be considered a feature). We have the notes all grouped in their own section, we generate the cross-linking for them (and in the tools we have just started decorating with the rel). In effect they are treated as endnotes (which is clearly a bug) but no specific option is currently enforced by the spec.

This doesn't mean that we're not interested in alternatives — but for the time being it has been an expedient option. My first instinct is that using something like DPUB-ARIA may be "forward-looking" whereas relying on GCPM might be construed as, uhmm, "optimistic"? But I could well be wrong, it's been a while since I've looked at this discussion :)

[frivoal]

GCPM footnotes have not been implemented in browsers, but they (or minor variants of them, it's hard to tell since the spec if vague) have been implemented in print formatters. Depending on the GCPM footnotes staying exactly as they are currently specified is probably "optimistic" indeed, but I would expect them to mature into something with inter-operable support eventually.

We (vivliostyle) do have basic support for a simple subset of them both in print an in-browser, and we intend keep working on it and to push the whole thing through standardization.

[darobin]

Right, I know about support in print but we need something that works in browsers, ideally without a shim. I'd love your advice on something that is as future-compatible as possible.

[frivoal]

Well, "works in browsers without a shim" is tricky, to the extend that browsers without a shim typically do not have a paged view, and footnotes are much less interesting on scrolling media.

Generally speaking, it makes sense for the notes to be inflow, and then moved somewhere else at the presentation level, but that requires something like either gcpm footnotes, page floats, or regions, none of which are interoperably (or at all) available in browsers.

If you're going to treat them as end notes...

[darobin]

I know it's hard, it's been a hard problem for years. My preference is also to keep them in the flow, but it isn't clear to me that we even have the right markup available to us in order to do that. To me that's the heart of the matter.

To reformulate and be more specific, the "no shims" thing concerns me more at that level than in eventual rendering. For instance, in our product we encode them as endnotes because I don't believe we have a good way of placing them in the flow such that the content will be interpreted correctly by implementations (e.g. such that they won't get indexed in the flow, and that the degraded no-JS experience doesn't ). However in terms of interactions they are more like footnotes: clicking on the ref causes them to appear in an overlay at the bottom of the screen, without scrolling.

If footnotes get inlined the wrong way, you can get really bad experiences (e.g. a sentence just starting mid-sentence for no obvious reason) when downgrading to some devices. I want to avoid that.

After that, for pure styling and interaction purposes, then sure: shim away!