Forum Feature requests

CSS3 generated list features

mophor
I saw prince has a content function called target-content(url)

maybe change this to target-string(url,pseudo), to also be able to get target generated content (http://www.w3.org/TR/css3-gcpm/#cross-references)

Furthermore, generated lists would be great, however, I see some limitations in the current working draft, since the generated element (where the make-element property refers to) can only be a single element. I would like to be able to repeat an element (and child elements) and specify an optional target element inside, to give an example:

(I extended w3c's example on http://www.w3.org/TR/css3-gcpm/#toc)

...
<style>
  #toc { prototype: container }
  #toc-entry { 
    prototype-insert-position: current toc-par;
    font-size: 14pt }
  #toc-entry::after { content: leader('. ') source-counter(page) }
  h1.chapter { make-element: toc-entry content }
</style>
...
<div>
  <h1>Table of contents</h1>
  <div><p></p></div>
</div>
...
<h1>Introduction</h1>
...


Here, I extended the prototype-insert-position property with an optional target-id. This should point to the id (inside the element) where the actual content is generated. If omitted, it will be the element itself. Another option would be:
<style>
  #toc { prototype: container }
  #toc-entry { 
    font-size: 14pt }
  #toc-entry::after { content: leader('. ') source-counter(page) }
  #toc-entry #toc-par {
    prototype-insert-position: current;
  }
  h1.chapter { make-element: toc-entry content }
</style>

ie to specify the property on the target element

In this light, also atomatic linking would be great, ie linking to the source id. That source id might not be set yet, so we might need a property to set this first:
h1 {
  make-attribute: id generate();
}

which sets the id attribute of the h1 element to a generated (uid) one, maybe we need an extra flag whether or not to overwrite existing id's (default: not). This could be a comma seperated list of multiple attributes to be set I guess. The generate() funtion might be replaced with <content> (see w3c: http://www.w3.org/TR/css3-gcpm/#string-set)

Next, this attribute should be set to the href attribute of the TOC entry:
  #toc-entry #toc-par {
    prototype-insert-position: current;
    make-attribute: href "#" source-attribute(href);
  }

where I introduced the source-attribute() function (similar to source-counter)

I would like to discuss this here a bit, because Prince is an application in which it actually might be used.

After some discussion, I plan to post it on the www-style mailing list
howcome
mophor wrote:
Furthermore, generated lists would be great, however, I see some limitations in the current working draft, since the generated element (where the make-element property refers to) can only be a single element. I would like to be able to repeat an element (and child elements) and specify an optional target element inside, to give an example:


Thanks for posting. This is the first serious response to the generated lists proposal. I don't understand what limitations you are thinking of, though. Perhaps you could post a use case? (Or, given that this is a topic only for the chosen few, perhaps you could email it to me. Or, to www-style, as you also suggested).

howcome@opera.com
hfinger
A TOC entry can contain a (chapter, say) number, the heading text, a spacer or leader, and the folio number.

Any decent implementation of a TOC generator (jumping in with both feet without having studied the history of CSS list generation) should allow these components to be ordered in any way or even omitted, postioned by a mechanism similar to tab stops, and allow hard-coded invariant text and other objects to be embedded, e.g. :

printersFlower pgNumInSmallType Chapter lgChapNum headingTextWithUnderrule

:idea: 27 Chapter 12 Formatting generated lists

FrameMaker provides extremly flexible template expressions which determine how an entry is constructed, formatted, and positioned. By extrapolation, same for LOF and LOT with figure and table numbers, as well as folio numbers. Studying the FM expressions for formatting entries would provide a good model for CSS and Prince.

My apologies if I have ventured onto well-trodden ground to teach grandma to suck eggs.
StoneCypher
You could hack that.
  1. Create a set of classes that express the formatting and styling you want. Remember that CSS classes can inject invariant text.
  2. Create a new attribute on the things you want to manipulate in the TOC. For this example we'll call it tocfmthook, for "table of contents formatting hook". Populate this attribute with the name of the CSS class which represents the desired TOC formatting.
  3. Set the following rule on #toc-entry:
    make-attribute: class source-attribute(tocfmthook);
Remember to wear your ninja mask, or you may be attacked by samurai.

John Haugeland is http://fullof.bs/

StoneCypher
Actually, on second read, you'll need to inject <spans> in the invariant text, and hook the tocfmthook class thing to those. And I'm not sure whether Prince interprets tags from generated text (the standard says it ought to, but that's honestly pretty meta.)

John Haugeland is http://fullof.bs/