Consider the attached file lbl-test.html. When running the following command:

prince --pdf-profile="PDF/UA-1" lbl-test.html

... in the resulting document, the <Lbl> tags appear as siblings of the <LI> tags, not as children of them; consequently, the document tree does not validate; see attachment lbl-test-01.pdf.

If I change line 17 of lbl-test.html to "display: block" rather than "display: inline-block", the <Lbl> tags appear as children of the <Lbody> tags, which still isn't quite right, though at least the document validates. However, the resulting reading order is kind of bizarre, with all of the ::before psuedoelements appearing to precede the actual list contents; see attachment lbl-test-02.pdf

I've tried styling the ::marker element rather than the ::before pseudoelement, but there doesn't seem to be any obvious way to achieve the demonstrated drop-cap-like effect by styling the ::marker element; in fact, setting the float property on the ::marker element appears to simply break the document tree in exciting ways without actually floating it.

1. lbl-test-01.pdf‎ 35.7 kB
2. lbl-test-02.pdf‎ 35.8 kB
3. lbl-test.html‎ 3.3 kB

Edited 21 Sep 2020 by David J Prokopetz

Thanks, we will take a look at this.

Actually, check that last one - after some further experimentation I realised that I'd forgotten to set "list-style-position: inside" on the parent list before setting the ::marker elements to "float: left". If you do that, the document tree doesn't break.

The other bug reports stand, though; I'm reasonably sure that when you float a ::before pseudoelement on a list item, the position of the resulting tag in the document tree shouldn't vary depending on whether the pseudoelement's display type is block or inline-block, and having a ::before psuedoelement appear as a *sibling* of its parent is very strange.

(Interestingly, the reported issue regarding a broken reading order is also reproducible with a floated ::marker element with display type block, though inline-block prevents it.)

Hm. After some further testing, I don't think the issue is idiosyncratic to lists. Consider the attached example.

1. pseudoelement-test.html‎ 1.4 kB
2. pseudoelement-test.pdf‎ 33.8 kB

We have fixed this issue in the latest build, thanks again for letting us know!

Thanks. I haven't yet had the opportunity to try it out against the document that was giving us trouble in the first place (that project is currently on hold), but I'll keep you posted.