The string-set property does not set the string if the element is set to display:none, except (apparently) for the first time. For example, I have the following in the stylesheet:
@page {
@top {
content: string(heading);
}
}
h1 {
display:none;
string-set: heading contents();
}
What is produced from this is that the content of the first h1 is copied to the string and is displayed in the @top page margin area. So far so good. But, it then does not change for the rest of the document, even though there are several more h1 elements in the document. If I remove the display:none property on the h1, it works as expected.
Why is there an interaction between display:none and string-set ?
By the way, speaking of string-set, this property is documented completely differently in the latest (4 May 2007) Working draft on "CSS3 Generated Content for Paged Media"
I admire Prince and wish you folks good luck with it. However, I must say that the situation vis-a-vis CSS 3 is really confusing. You have Prince extensions but some of them seem to mirror things that are in the latest working drafts -- so why are they classified as extensions? You have things that are in the working drafts, but they don't work exactly the same way as spec-ed in the working drafts and/or are missing features. You have very sketchy documentation on everything, seemingly relying on the CSS3 specs for people who are trying to figure out details -- but things often don't seem to work like in the CSS3 drafts, especially when the CSS3 drafts are detailed.
It seems to me that it would be really helpful if you either
(a) tracked the CSS3 drafts, providing detailed documentation on what is different, or filling in details where CSS3 drafts are still sketchy; For example, you could say "we conform to CSS 3 Paged Media as of such-and-such date except blah and blah".
or (b) had complete documentation on the current Prince state independent of the CSS3 drafts, coupled by some kind of statement that Prince plans to converge with CSS3 at some point in the future when the relevant CSS3 modules are closer to finalized.
I admit that either of these would be a lot of work. But the current state -- where both the Prince documentation *and* the CSS3 documentation are sketchy, and anyway in cases where the CSS3 drafts are somewhat detailed Prince does not agree with CSS3 in many cases, but it is not documented how it does not agree -- is exasperating, to say the least.
@page {
@top {
content: string(heading);
}
}
h1 {
display:none;
string-set: heading contents();
}
What is produced from this is that the content of the first h1 is copied to the string and is displayed in the @top page margin area. So far so good. But, it then does not change for the rest of the document, even though there are several more h1 elements in the document. If I remove the display:none property on the h1, it works as expected.
Why is there an interaction between display:none and string-set ?
By the way, speaking of string-set, this property is documented completely differently in the latest (4 May 2007) Working draft on "CSS3 Generated Content for Paged Media"
I admire Prince and wish you folks good luck with it. However, I must say that the situation vis-a-vis CSS 3 is really confusing. You have Prince extensions but some of them seem to mirror things that are in the latest working drafts -- so why are they classified as extensions? You have things that are in the working drafts, but they don't work exactly the same way as spec-ed in the working drafts and/or are missing features. You have very sketchy documentation on everything, seemingly relying on the CSS3 specs for people who are trying to figure out details -- but things often don't seem to work like in the CSS3 drafts, especially when the CSS3 drafts are detailed.
It seems to me that it would be really helpful if you either
(a) tracked the CSS3 drafts, providing detailed documentation on what is different, or filling in details where CSS3 drafts are still sketchy; For example, you could say "we conform to CSS 3 Paged Media as of such-and-such date except blah and blah".
or (b) had complete documentation on the current Prince state independent of the CSS3 drafts, coupled by some kind of statement that Prince plans to converge with CSS3 at some point in the future when the relevant CSS3 modules are closer to finalized.
I admit that either of these would be a lot of work. But the current state -- where both the Prince documentation *and* the CSS3 documentation are sketchy, and anyway in cases where the CSS3 drafts are somewhat detailed Prince does not agree with CSS3 in many cases, but it is not documented how it does not agree -- is exasperating, to say the least.