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

On Fri, Aug 8, 2008 at 2:14 AM, marbux <marbux@gmail.com> wrote:

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


You'll want to check the Generated and Replace Content Module [1], which
gives a much broader and more extensive treatment of the subject than GCPM
(which is more of a grabbag of print-related issues that aren't addressed in
other specs) does.  It introduces mechanisms to produce arbitrary 'magic
areas', with several default magic areas built in (footnote, section-note,
endnote) that are extremely easy to use.  It took me a few reads to wrap my
head around how it worked, but it's really rather clever.

Generating a 'magic area' outside the document is outside of the current
html and css specs, and is probably outside of their jurisdiction entirely,
but it's easy to do with javascript (scripting to code the content into a
special url that the receiving document can decode).  Ordinary CSS can
provide good fallback styling for when viewing the document standalone.

Associating things with arbitrary spans of text (possibly/likely crossing
element boundaries) is still a difficult issue.  The existing <ins>/<del>
elements run into the same problems.

[1]: http://www.w3.org/TR/css3-content/#moving

~TJ