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

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

From: marbux <marbux@gmail.com>
Date: Fri, 8 Aug 2008 18:33:58 -0700
Message-ID: <2c60d980808081833i442f77caxbfb9de65ba958b57@mail.gmail.com>
To: "www-style list" <www-style@w3.org>

On Fri, Aug 8, 2008 at 7:43 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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.

Thanks for helping a newbie, Tab. I took a quick skim of the
referenced section of GRCM and will definitely spend more time
studying it. Initially, it looks like an informational cross reference
in the GCPM spec to that GRCM section would be helpful to other
newbies.

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

I obviously should have been more clear. I don't propose that such
magic areas be generated. But from an interoperability standpoint, the
more that markup for identifying multi-purpose notes can be explicitly
standardized, the fewer interop headaches there will be. So e.g., if a
reviewer's comment is designated by an author to be added to a To-Do
task list, it would need to be identified as both a comment and a task
for parsing purposes.

I am mindful here of the history of footnotes on the web and of
Google's recent announcement that it now has indexed over a trillion
web pages. I could in a few minutes produce a list of at least a
half-dozen different custom tags used by various web apps to identify
footnotes and I suspect there are many more.

No one knows how many web pages are out there with footnotes, but
consider the problem of programmatically parsing and processing such
content in a business process for say, document assembly from data
extracted from other documents.

Can content X be extracted without linked content Y (a footnote) on
the same page? And how to identify where content Y ends when all there
is to associate the X and Y is a hyperlink? How might things be
different today if HTML 1.0 had specified tags for footnotes and
footnote calls that identified the footnote relationship between
content X and content Y as well as the boundaries of Y? Might that
trillion web pages be easier to programmatically parse if such tags
had been standardized, whether browsers understood such tags or not?
In my mind's eye, the authoring tools would still have been in a
better position to interoperate if footnotes and footnote calls had
been identified as such with a standardized vocabulary.

I suggest that there is interoperability ground to be gained by
standardizing markup for note types whether their corresponding
"magic" areas are also specified in CSS or not. This is not to suggest
that such markup be simply brainstormed; there is research needed to
identify what additional note markup would be useful to authoring tool
developers and how such notes are defined by other specifications
should also be studied.

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

Yes. FWIW, here is the solution that is being adopted for OpenDocument
1.2. <http://lists.oasis-open.org/archives/office/200708/msg00007.html>.
It's been approved but is still being formalized by the editor.

Best regards,

Paul E. Merrell, J.D. (Marbux)

-- 
Universal Interoperability Council
<http:www.universal-interop-council.org>
Received on Saturday, 9 August 2008 01:34:41 GMT

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