- From: marbux <marbux@gmail.com>
- Date: Fri, 8 Aug 2008 00:14:45 -0700
- 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 UTC