W3C home > Mailing lists > Public > www-style@w3.org > August 2008

[css3-gcpm] More magic areas than footnote and sidenote?

From: marbux <marbux@gmail.com>
Date: Fri, 8 Aug 2008 00:14:45 -0700
Message-ID: <2c60d980808080014q173fa7d6x6f15e2997e098494@mail.gmail.com>
To: www-style@w3c.org

"Should there be a mechanism to create new areas like
footnote/sidenote, or are two "magic" area enough?"
<http://www.w3.org/TR/2007/WD-css3-gcpm-20070504/#sidenotes>

For editing application interoperability purposes, I'm somewhat
inclined against a flexible mechanism. However, I see a strong need
for at least three more note elements to be defined: [i] endnotes,
[ii] comments; and [iii] annotations.

Endnotes are commonly collected at the end of a chapter or near the
end of a book rather than on the same page as the note's call in the
body text. Their use in dead tree books is common and time-honored. A
target reference for their placement seems necessary, given that other
end matter may trail the endnotes, e.g., a subject matter index,
appendices, and the colophon.

Comments are needed for collaborative document development. A lead
author will wish to have others comment on drafts, decide whether to
apply suggested changes, and to retain an audit trail of comments and
related editing decisions. If no common mechanism is adopted for
associating comments with content, authors will become trapped in the
editing application that they receive the first comment in,
notwithstanding that a desired editing feature is only supported in
another application.

An annotation ability is needed for the ultimate reader of a document.
While this is a feature that will be wasted in dead tree documents, it
is a feature expected by eBook readers. See e.g., ePub 2.0 (uses CSS 2
with Daisy DTBook annotation features).
<http://www.openebook.org/2007/ops/OPS_2.0_final_spec.html#Section2.4.1>;
(which are in turn derivative of SMIL).
<http://www.niso.org/workrooms/daisy/Z39-86-2005.html#Notes>.

If a more generic approach to notes is considered, one might imagine a
generic <note> element with an optional <notecall> pseudo-element and
with cascading properties for further definition of the note type and
desired processing. (Note that an emerging trend in both desktop and
web collaborative editors is to attach comments and annotations to
highlighted text spans rather than to a note call. This can present
programming challenges when the span crosses paragraph or page
boundaries, particularly with intervening footnotes)

Example <note> types:

annotation
approve
approve-with-changes
disapprove
*bibliography-entry
*calendar-entry
comment
*contact
** endnote
footnote
*memorable-quote
*research-note
sidenote
*todo-task
=======
* denotes plausible note types where the "magic" area may be located
in another document or application or be co-located in both the local
document and elsewhere.

** denotes note type where the "magic" area is at the end of the
chapter or document rather than on the same page.

The primary concern I address in this post is that the recommendation
go beyond presentation to address foreseeable authoring workflow needs
as well as electronic document reader needs such as annotation and
maintaining a collection of memorable quotes.

Best regards,

Paul E. Merrell, J.D. (Marbux)
---
Universal Interoperability Council
<http:www.universal-interop-council.org>
Received on Friday, 8 August 2008 07:15:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:11 GMT