There are situations where generated content, such as a page header or footer region or a ::before or ::after psuedoelement, may contain an abbreviation or acronym. Currently, when generating tagged PDFs for screen-readers it's necessary to manually edit the resulting PDF to add the appropriate read-aloud text to these elements. It'd be handy if this could be specified at the stylesheet level instead.
Forum › Feature requests
Allow the prince-expansion-text property to apply to generated content
One possibility would be to use prince-flow to move a whole element into generated content. It might be combined with script to create an element not already in the source document.
I did wonder whether this is sufficient grounds to add a generated-content item along the lines
There are other use cases for that sort of idea (with whatever syntax). However, the CSSWG has in the past been somewhat reluctant to adopt proposals that amount to an ugly reimplementation of XML in CSS, e.g. noting also its "slippery slope" aspects:
I did wonder whether this is sufficient grounds to add a generated-content item along the lines
prince-apply((prince-expansion-text "Cascading Style Sheets") (font-variant small-caps) "css")There are other use cases for that sort of idea (with whatever syntax). However, the CSSWG has in the past been somewhat reluctant to adopt proposals that amount to an ugly reimplementation of XML in CSS, e.g. noting also its "slippery slope" aspects:
... and then developers will want pseudos to have read/write OM properties, then attributes to make them drop zones, give them ARIA roles or attach event handlers to them, then there'll be APIs to create, move and delete these pseudos. And then we have recreated the DOM except without a static document language... until someone writes a JS library to generate them from such markup.
Unless I'm misreading the spec, using a script-generated element in conjunction with prince-flow would only address the case where an abbreviation resides in a page region, not the case where an abbreviation resides in pseudoelement.
Headers and footers are currently treated as pagination artifacts that do not appear in the tagged PDF structure tree, but the ::before/after pseudo-elements in main flow content should support prince-expansion-text in latest builds.
Huh. You know, I didn't even think to try the latest build because the roadmap only refers to supporting prince-expansion-text on the list and footnote marker pseudoelements, but it looks like the ::after pseudoelement is supported as well. Never mind about that one, then - thanks for the heads-up!