Forum Bugs

Nested ul / ol

koen
PrinceXML renders the code below incorrectly. This uses an unconventional way of nesting <ul> within <ol>, but it renders correctly on all major browsers.
Note that the <ul> is not nested within the <li> above it, to avoid that the <li> style is applied to it.

<html>
<body>
<ol>
<li style="color:red">Introduction</li>
<ul>
<li>item 1</li>
<li>item 2</li>
</ul>
<li style="color:red">Overview</li>
</ol>
</body>
</html>
mikeday
If you use our new HTML5 parser (with "-i html5" on the command-line, or setInputType("html5")) then it renders better. But it looks like the numbering is still slightly different to the browser.

Is it possible to move the <ul> inside the first <li>? :)
dauwhe
"Unconventional" is one way to describe it, although I'd probably use a more technical term like "invalid" :)

Is there an unambiguously correct rendering of this markup? I see an ordered list that contains three child elements; is <ol> supposed to label all child elements, or only <li> children? I wouldn't want to rely on browser-style error correcting in my PDFs.

Dve
koen
When the <ul> is moved inside the first <li>, it inherits the styling applied to the <li>, what I don't want. Here it's easy enough to reset the style to color:black in de <ul>, but this is a simplified example.

Anyway, seems indeed like this is invalid according to the standard. But all browsers render it correctly - or rather the way I intended :-) Also wkhtmltopdf does it right.
mikeday
Have you tried enabling the Prince HTML5 parser?
koen
Yes, with the HTML5 parser it looks better. But the numbering is still wrong, as you already noticed. Even though it's not standard, I would say that only the <li> items should be counted.

I now realize that, when using the HTML5 parser, I can work around the numbering issue by inserting a value="2" attribute in the last <li>. That's ok for me. Thanks!