Re: footnote element in HTML

Thanks for the feedback Liam!

On Mon, Feb 9, 2015 at 4:14 PM, Liam R E Quin <liam@w3.org> wrote:

> On Mon, 9 Feb 2015 14:15:24 -0800
> Robert Sanderson <azaroth42@gmail.com> wrote:
> > I'm sorry that you find the annotation spec FPWD very complex.  Any
> > feedback as to the nature of that complexity would be greatly appreciated
> > so we can assess how to address it in future versions.
>
> On my first reading I actually got lost at "All Annotations MUST be
> instances of the class oa:Annotation" :D (where "oa:annotation" was not a
> link to anything and the term "class" was not defined)
>

I added the comment as an annotation on the FPWD. Dogfood and all that :)

And I think it's a very good point. There should be at least discussion as
to how to read the spec, and what we mean by class and so forth. Also on
the roadmap is a primer document focused on the learning and implementing
aspect, rather than a formal specification.  But it's hard to write a
primer before having a spec :)


> > While we're addressing requirements, how about:
> > * Ability to mark a section of text as the anchor, rather than just a
> > marker at a single point.
>
> I don't understand this in relation to footnotes.
> I do understand it for e.g. the target of an index entry, or for more
> general (or more complex) annotations.
>

Footnotes are (in my experience) always about a region of text, rather than
a single point in the document.  That we put a marker at a point is to
avoid having to highlight content in a print environment which would be all
sorts of terrible.  So instead of simply putting in the print-convenient
marker, it seems like it would be useful to associate the footnote text
with the actual span of main content that it refers to, regardless of how
it is rendered by the user-agent.

Thus, here we know the scope of the footnote.
<noteref noteid="1">This is the content text</noteref>
<note noteref="1" typeof="dpub:footnote">This is the footnote text</note>

Rather than here, where we only know the end point of the scope:
<span>This is the content text<noteref id="1"/><note
href="#1">...</note></span>



> > * Ability to have a footnote refer to multiple sections of the text,
> rather
> > than only one.
> The text refers to footnotes; I did mention a single footnote being
> referred to from multiple places, though, as something I'm aware of being
> needed in publishing. You see this a lot in things like table footnotes in
> aircraft repair manuals.
>

I think we're in agreement.

I mean:

<noteref noteid="1">This is some content text</noteref> ...<noteref
noteid="1">This is some later content</noteref>
<note noteref="#1">This is the footnote text</note>



> > * The ability to refer to the footnote itself, for example to (you know)
> > comment on it.
> We have CSS selectors that can match footnote elements, and we have
> XPath...
>

And XPointer and Fragment IDs. All good ... I just wanted to call out the
requirement :)



> > * The ability to create footnotes with reference to non text, including
> > bounding boxes in image based media.
>
> I'm not sure I understand this either -- I think that would be a callout,
> and I agree we should be able to do them (good old SoftQuad Panorama
> supported annotations on user-defined regions of images back in the early
> 1990s, for SGML documents)
>

I think you understand it perfectly :) The text of the footnote refers to
some region within an image, and thus there needs to be something like:

<noteref noteid="1" fragment="xywh=100,100,640,480"><img
src="aircraft-diagram.png"/></noteref>


> * Ability to provide style information regarding the anchor rendering, for
> > example to ensure that a highlight color does not collide with the color
> of
> > the background, or the bounding box color does not collide with the color
> > of the image.
>
> I think you're asking for two separate things here.
>
> A document designer has the responsibility to make sure that text is
> readable on a given background in general, and that would apply to footnote
> markers such as dagger/obelisk/star, numbers, etc.
>

Yes, +1.


> Callouts from graphics or video are different since the content and hence
> background colour might not be known in advance; I seem to remember for
> Panorama we used a double line, one black and one white, to draw the shape,
> but it's been 20 years...
>

Heh, that's a pretty good solution. And yes, that's also what I mean,
though I think about them both the same way -- it's the rendering of the
target region/selection/segment of the content that the footnote content
refers to.


>
> > * Machine readable provenance information regarding the creator of the
> > footnote, separate from the document.
>
> Why do you want to require that it be separate from the document? I would
> hope an author can include footnotes in a document.
>

Sorry, I meant separate from the provenance of the document.  Eg a
reference to the author of the footnote (or other such note) should be able
to be included within the footnote somehow, in a machine processable way.


I agree about tracking provenance of annotations, and in a social world one
> obviously needs privacy/sharing and security potentially on every fact,
> inseparably. But it'd be awfully onerous to have to mark each footnote
> individually with who wrote it when it's usually the same author for all of
> them... (or an editor for 2nd level footnotes, usually indicated by a
> different numbering scheme in print today).
>

Agreed, it should be both optional, and inheritable to avoid needless
repetition.


> * Ability to control the presentation of the footnote with javascript
> > and/or user-agent preferences.
>
> I think you get the first part of that for free with a footnote element in
> the document;


Agreed. Just noting it as a requirement to be discussed.


> researching and writing up good ideas for presentation and user agent
> preferences sounds like it would be very productive.
> Click-to-go-to-separate-footnote-document is about the worst interface that
> I've seen in widespread use.
>

+infinity


> I don't think footnotes are a bad thing, nor that they should be subsumed
> into annotations, just because they're not well-supported in today's Web
> browsers. We should rather work towards improving the support, of course.
>

No disagreement, of course :)


Rob

-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305