- From: Sanders Kleinfeld <sanders@oreilly.com>
- Date: Fri, 7 Aug 2015 09:28:19 -0400
- 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: <section> <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"/> </figure> <p>In <a href="#a_section"/>, we have some cross references.</p> <p>In <a href="#a_figure"/>, we have an icon image</p> </section> 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. Thanks, Sanders 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