`<simpara>` inside `<varentry><listitem>` is converted to `<span>` tag rather than `<p>` tag.

[Girgias]

This was noticed by @nilgun that the conversion from <para> to <simpara> is affecting the layout of pages.

Indeed, two consecutive <simpara> tags are rendered as one big paragraph, which is not what the XML markup indicates.

I don't understand why the choice was made to deviate from the usual conversion to HTML <p> tag, as flow content is allowed within a <dd> HTML tag.

This is a quite simple fix, and should better represent the behaviour intended by the XML, as if someone wanted to only have one big paragraph they wouldn't use multiple <simpara>/<para> tags.

[alfsb]

I don't understand why the choice was made to deviate from the usual conversion to HTML <p> tag, as flow content is allowed within a <dd> HTML tag.

Possibly, "hard" margins, or no collapsing margins. At least this is a very common problem in automatic transforming systems that do not use the box model of HTML/CSS.

This is a quite simple fix, and should better represent the behaviour intended by the XML, as if someone wanted to only have one big paragraph they wouldn't use multiple <simpara>/<para> tags.

A post processing step that analyses HTML conformance against well known DTDs may be necessary to detect some corner case like <p><p>text</p></p>.

[Girgias]

Aren't <para> tags converted to <div>?

[alfsb]

Aren't <para> tags converted to <div>?

I think so, but <p><p> is just one example. The proposed change takes into account the synthetic HTML model, but only by validating the PhD output files to ensure there are no violations elsewhere.

It may detect other problems, such as one I'm trying to debug today, where half of the doc-pl manual is wrapped in <strong> at all levels.

[Girgias]

Right, but it would indeed be good if we can have a special post-processing pass that flags basic DTD and maybe even accessibility issues with the produced HTML.