The attached example should produce "Page 1 of 2" and "Page 2 of 2" using

content: "Page " counter(page) " of " target-counter(url("#end"), page);


The result is always "Page ... of 0".

The correct result is produced by PDFreactor and Antennahouse.

1. 1.zip‎ 361.0 kB

I don't think that should work as the "#end" URL is resolved relative to the document it appears in, table.css, and thus is the same as writing "table.css#end" which will not find anything useful.

If you replace this with url(000001.html#end) then it works, or if the CSS rule is included in the HTML document so that the URL will be resolved relative to itself.

Perhaps yes, perhaps no. The point is that we have different output and different interpretations among the tools - either through implementation details or due different interpreations of the specs. From the user's perspective, this is more than acceptable. Why would PDFreactor or AH work here as expected?

In general URLs are supposed to resolve relative to the document in which they appear:

However it appears that the specs have recently made an exception for the fragment-only case:

https://drafts.csswg.org/css-values-3/#local-urls

Prince does not implement these eccentricities.

Eccentricities or not. It must be possible to run the same stylesheet against arbitrary HTML files without including the individual names of a HTML file. Something for the roadmap I guess.

Arbitrary HTML files that are known to contain an element with an ID of "end", presumably!

You got my point

Another argument: using target-counter() in this case works only correct with an inline stylesheet inside the HTML. I am not a spec layer but looking at this issue from the user's perspective, both should behave identical.

In general CSS rules are not portable, consider this example:

body { background: url(image/paper.jpg) }

If this rule is located inside "blah/doc.html" then the URL will be "blah/image/paper.jpg", but if the rule is moved to an external style sheet "http://example.com/style.css" then the URL will be "http://example.com/image/paper.jpg".

It is only the fragment case where browsers are behaving strangely, and I'm not sure where that came from as they certainly didn't do it for the benefit of target-counter().

Yes and no.

In our case we have a thousand HTML generated in one folder and they have to be converted using one CSS to PDF. It is just impossible to adjust the process generating the HTML in order to inject a related CSS rule for "content:.." into the HTML. A external stylesheet must to the job - that's the users expectation here. I am not fingerpoint here or blaming anyone here. But these minor differences in the behavior of tools since is a huge problem in reality. So we have specs and different interpretations or implementations of the specs. And the gap between specs and implementations is much larger with all PrintCSS tools than with the browser engines.

In this case applying external JavaScript would be sufficient to update the HTML by inserting any necessary CSS rules without needing to modify the original files.

You are arguing from the PrinceXML point of view which is fine. I am arguing from the #PrintCSS users prospective where is a user is faced with the problem making a technology decision and picking a tool. And not every tools has JS support...I am really talking her about the interpretation of specs across all tools in order to achieve a better interoperability.

Yes, since the #fragment eccentricity has been codified in the CSS specification we will also need to implement it for the sake of interoperability.

Thanks Mike