W3C home > Mailing lists > Public > public-digipub@w3.org > August 2015

Re: Cross-References in GCPM (was: CSS Pages and Pagination)

From: Sanders Kleinfeld <sanders@oreilly.com>
Date: Fri, 7 Aug 2015 09:28:19 -0400
Message-ID: <CAD1Cp0sR_xVdvqBiFX7RR3pm2orx-Zb7sxnYfJu3VLkQA3=VMw@mail.gmail.com>
To: Håkon Wium Lie <howcome@opera.com>
Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, public-digipub <public-digipub@w3.org>
the ability to automatically customize the text content based on the
type of element that is being linked to. So for example, if we had
markup like the following:

  <h1 id="a_section">The First section title</h1>
  <p>Some text here</p>
   <figure id="a_figure">
      <figcaption>An interesting icon</figcaption>
      <img src="icon.gif"/>

   <p>In <a href="#a_section"/>, we have some cross references.</p>
   <p>In <a href="#a_figure"/>, we have an icon image</p>

We might want the cross-reference to the section heading (#a_section)
to contain the text "Section 1.1", and the cross-reference to the
figure caption to contain the text "Figure 1.1". The numbers in the
cross-reference text can be generated with target-counter(), but I'm
not aware of a way to tailor the text content based on the element
that the <a> href refers to.

You can use the target-text() function to pull in an element's text,
but that's not what we want here.

One workaround I can think of would be to use a pseudoelement to do
the label, e.g.:

figcaption::before {
  content: "Figure " counter(fignumber);

And then use target-text() to pull that in:

a { target-text(attr(href url), before)

But that presumes that we actually want that ::before content on the
figcaptions themselves, which oftentimes we do not.

Another hack I've seen done is to craft the ids such that the href
value will contain the element type, so that you can then customize
the generated content accodingly, i.e.:

a[href*="figure"] {
  content: "Figure " counter(fignumber);

a[href*="section"] {
  content: "Section " counter(sectnumber);

But that introduces additional requirements in how ids are named,
which goes against the spirit of what I'm trying to accomplish and can
be hard to enforce with content creators.

So right now, we postprocess the XHTML with XSLT to generate the text
nodes of the XREF <a>s before applying the CSS. I don't know whether
it would be in scope to add more advanced functionality to target-text
to accommodate this use case (assuming there's not a way to accomplish
this already that I've missed), or how widely it's needed. Would love
to hear others' thoughts.


On Thu, Aug 6, 2015 at 1:47 PM, Håkon Wium Lie <howcome@opera.com> wrote:
> Sanders Kleinfeld wrote:
>  > Paged Media does not yet meet every single one of our needs (e.g., we
>  > fall back on XSLT postprocessing of XHTML to generate text nodes for
>  > cross-reference in a more sophisticated fashion than currently
>  > supported by CSS Generated Content for Paged Media)
>  > but it meets most of them,
> It warms my heart to hear this.
>  > and the fact that there are professional-grade tools available that
>  > implement it (we use AntennaHouse) makes it viable to center a
>  > print publishing program around the specification. I can't yet say
>  > the same for any other spec.
> Exactly. Gradual improvements Paged Media seems like a viable way
> forward, rather than a "let's kill all the sheep and start with goats"
> approarch. I've been adding some features here:
>   https://figures.spec.whatwg.org
>   https://books.spec.whatwg.org
> As always, specifications are quite useless without implementations,
> so I'm reluctant to add more until implementations catch up. But I'd
> be interested in hearing your list of requirements for
> cross-references.
>  > And I'll echo Daniel and Tzviya with a big thumbs up for the excellent
>  > work Dave Cramer and others are doing to evolve and enhance GCPM.
> We have consensus: Dave is great!
> -h&kon
>               Håkon Wium Lie                          CTO °þe®ª
> howcome@opera.com                  http://people.opera.com/howcome
Received on Monday, 10 August 2015 06:50:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:34:52 UTC