- From: Peter Moulder <pjrm@mail.internode.on.net>
- Date: Tue, 13 Nov 2018 18:15:02 +1100
- To: Hans Meiser <brille1@hotmail.com>
- Cc: "www-style@w3.org" <www-style@w3.org>
The approach taken by the PDF user-agent Prince is that construction of
natural language is best left to script: otherwise, the parameter array
will inevitably be found lacking once someone wants text like "at the top
of" or "in the appendix" or whatever.
More specifically, it allows a generated-content function
prince-script(FUNC-IDENT, ARGS) where ARGS are other generated-content
items (such as counter(page) and target-counter(URI, page)).
So for just the page-number description, one might have CSS
a[href ^= "#"]::after {
content: " (on "
prince-script(describeRef,
counter(page),
target-counter(attr(href), page))
")" ;
}
and javascript
Prince.addScriptFunc("describeRef", function(ownPage, targetPage) {
/* To distinguish "above" from "below", one would query the dom
* here, after adding function arguments attr(id), attr(href).
*/
if (ownPage == targetPage) {
return "this page";
} else if (targetPage == ownPage + 1) {
return "next page";
} else if (targetPage == ownPage - 1) {
return "previous page";
} else {
return "page " + targetPage;
}
});
(Prince cautiously requires FUNC-IDENT to be registered explicitly using
Prince.addScriptFunc rather than automatically exposing all global named
javascript functions. The second argument can either be a named javascript
function, or an anonymous function as used above.)
Depending on the desired behaviour of the suggested paragraph() function,
it might be implementable just by querying a particular counter (and/or
the page counter of paragraph elements). For the most general case,
one can query the formatted document and re-start the layout with
revised javascript inputs.
A number of PDF-centric user agents for CSS allow use of javascript;
I haven't looked at how the above would differ between them.
pjrm.
Received on Tuesday, 13 November 2018 07:15:31 UTC