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

On Fri, Aug 8, 2008 at 8:33 PM, marbux <marbux@gmail.com> wrote:

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


No problem, and I agree that a reference would be helpful. That'd be
something to take up with Håkon.


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


It's possible that this is an issue best served by talking to the
Microformats community.

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

Yup, and that exact solution has been thrown around on the html5 mailing
list before as well (<ins-start>/<ins-end>/etc).  Though it's almost
certainly the best solution overall, it suffers from a lack of support in
CSS, as there's no element to style.  A pseudoelement may be possible here,
but that's a different discussion.

~TJ