Several of the requests that have been made in forums which are under investigation for future releases would be implementable if there was a mechanism for injecting actual tags, rather than flat text, through the content: mechanism. Most of these tricks would revolve around @page { @location {} } schemes.
Of recent note, for example, is the user who wanted a mechanism akin to an old version of Prince's watermarking mechanism, in order to apply a logo to each page. I provided him with a relatively ugly hack revolving around the misappropriation of the page background image, which is servicable in his limited context; however, were it the case that a person wanted two such images per page - say, a logo for the company in one corner and for the department in another - the hack would cease to be applicable. (It is worth noting that CSS3 stacked properties would allow the arbitrary extension of this hack, but that is not a particularly desirable answer - though that on its own is a desirable mechanism for other reasons, such as single-tag implementation of the sliding doors pattern.)
Now, here semantic people get into a remarkably bitter debate about whether the ability to inject tags through :content, :before and :after is a legitimate ability for a stylesheet system. I note that you use vendor prefix codes and support xpath, so it seems likely that you are intensely standards focussed. This presents a difficulty in finding an appropriate resolution system. This is exacerbated by all relevant standards' complete commentary abstinance on the issue (no part of the CSS3 specification currently makes any attempt to resolve the issue.)
I have seen people using foreign references and XPath references to pull in DOM structured content as formatting cue. Whereas this provides an appropriate mechanism for the stylesheet to simply denote the mechanism for injecting new content, I believe this is overengineered, and necessitates an unnessecary subdivision of a document, one which for complex documents could easily become inordinately difficult to contain without software support.
I have a compromise which has mollified essentially everyone I've thrown it at, which I would like for you to consider. Whereas it has no support from standards, it also has no condemnation from standards; it relies entirely on the particular interpretation of mechanisms which are well defined and well accepted. It is extremely unlikely that any future codification of CSS would break this mechanism, though it is quite likely that a future revision will either make this mechanism seem archaic and silly, or make it absolutely vital.
The XML standard allows for entities to contain DOM structured elements, and the CSS standard makes zero mention of the interpretation of strings, particularly with respect to entities, within its content fields. Furthermore, I have a hard time imagining a developer objecting to the interpretation of entities within a content field, and browsers are divided on the issue, which gives you good company to argue with (KHTML / Konqueror / Khameleon / Safari, Omniweb and Opera all believe that entities within generated content should be honored; only KHTML/etc's implementation seems to be strong enough to allow XML's entity rules to prevail.)
If you are willing to honor XML's entity rules from within CSS, then the problem becomes a trivial non-issue, wherein the question of generated repeating content becomes one of the stylesheet referring to a prefabricated entity (or two or six - entities may also legally be fractions of tags - you may define one entity as "<tab", the other as "le>", stick them together and expect them to work) which is defined in the DTD, the whole semantic part of this is kept out of the CSS and in the DTD where it belongs, and everybody's happy.
Furthermore, though I'm guessing at the nature of your software backend, it seems highly likely that this would not be particularly difficult to implement. This would require a (very short) pass through the source document(s) to get the DTDs involved, then an early parse of the DTDs, then the expansion application of entities to the content rules in the CSS, before the CSS was applied to the document. Most likely the only difficult part involved will be the reinterpretation of the document required after the injection of a DOM structure.
I remain unaware of a significant downside to this approach, other than the common "only some browsers do it that way" bit with which pretty much anything needs to wrestle. Quite a few header and footer issues, several border placement issues and so on could be reduced to what another language might call macros (yes, I know macro has a different meaning in CSS, I mean what a C programmer would call a macro.)
Indeed, were such a mechanism supported, advanced PrinceXML users would have a reasonable way to provide pre-fabricated layout toolkits for the benefit of newer users.
I look forward to your perspective on the matter.
Of recent note, for example, is the user who wanted a mechanism akin to an old version of Prince's watermarking mechanism, in order to apply a logo to each page. I provided him with a relatively ugly hack revolving around the misappropriation of the page background image, which is servicable in his limited context; however, were it the case that a person wanted two such images per page - say, a logo for the company in one corner and for the department in another - the hack would cease to be applicable. (It is worth noting that CSS3 stacked properties would allow the arbitrary extension of this hack, but that is not a particularly desirable answer - though that on its own is a desirable mechanism for other reasons, such as single-tag implementation of the sliding doors pattern.)
Now, here semantic people get into a remarkably bitter debate about whether the ability to inject tags through :content, :before and :after is a legitimate ability for a stylesheet system. I note that you use vendor prefix codes and support xpath, so it seems likely that you are intensely standards focussed. This presents a difficulty in finding an appropriate resolution system. This is exacerbated by all relevant standards' complete commentary abstinance on the issue (no part of the CSS3 specification currently makes any attempt to resolve the issue.)
I have seen people using foreign references and XPath references to pull in DOM structured content as formatting cue. Whereas this provides an appropriate mechanism for the stylesheet to simply denote the mechanism for injecting new content, I believe this is overengineered, and necessitates an unnessecary subdivision of a document, one which for complex documents could easily become inordinately difficult to contain without software support.
I have a compromise which has mollified essentially everyone I've thrown it at, which I would like for you to consider. Whereas it has no support from standards, it also has no condemnation from standards; it relies entirely on the particular interpretation of mechanisms which are well defined and well accepted. It is extremely unlikely that any future codification of CSS would break this mechanism, though it is quite likely that a future revision will either make this mechanism seem archaic and silly, or make it absolutely vital.
The XML standard allows for entities to contain DOM structured elements, and the CSS standard makes zero mention of the interpretation of strings, particularly with respect to entities, within its content fields. Furthermore, I have a hard time imagining a developer objecting to the interpretation of entities within a content field, and browsers are divided on the issue, which gives you good company to argue with (KHTML / Konqueror / Khameleon / Safari, Omniweb and Opera all believe that entities within generated content should be honored; only KHTML/etc's implementation seems to be strong enough to allow XML's entity rules to prevail.)
If you are willing to honor XML's entity rules from within CSS, then the problem becomes a trivial non-issue, wherein the question of generated repeating content becomes one of the stylesheet referring to a prefabricated entity (or two or six - entities may also legally be fractions of tags - you may define one entity as "<tab", the other as "le>", stick them together and expect them to work) which is defined in the DTD, the whole semantic part of this is kept out of the CSS and in the DTD where it belongs, and everybody's happy.
Furthermore, though I'm guessing at the nature of your software backend, it seems highly likely that this would not be particularly difficult to implement. This would require a (very short) pass through the source document(s) to get the DTDs involved, then an early parse of the DTDs, then the expansion application of entities to the content rules in the CSS, before the CSS was applied to the document. Most likely the only difficult part involved will be the reinterpretation of the document required after the injection of a DOM structure.
I remain unaware of a significant downside to this approach, other than the common "only some browsers do it that way" bit with which pretty much anything needs to wrestle. Quite a few header and footer issues, several border placement issues and so on could be reduced to what another language might call macros (yes, I know macro has a different meaning in CSS, I mean what a C programmer would call a macro.)
Indeed, were such a mechanism supported, advanced PrinceXML users would have a reasonable way to provide pre-fabricated layout toolkits for the benefit of newer users.
I look forward to your perspective on the matter.
John Haugeland is http://fullof.bs/