Open siefkenj opened 9 months ago
Thanks @siefkenj. Good catch. It'll be a few days before I can merge.
@davidfarmer: do you expect CSS ramifications? Would a beta be useful or necessary?
OK, put this through testing on the sample article.
li
content is a cd
. Which may illustrate a shortage of examples.ol
,ul
, dl
cannot appear as a child if anli
without an intervening p
. Or said differently, the list structure must be a child of a p
. So could be removed from the @test
?Shouldn't these "unstructured" li
be exploded into several HTML p
? I wonder if the pre-processor should just wrap the content of an "unstrcuctured" li
into a p
and then it will be handled appropriately in all conversions (especially HTML)?
I am not sure what @test
refers to. And since we do not use any <p>
tags anywhere in HTML, I don't think exploding is necessary.
Yes, moving this step to the preprocessor would be an option (that's what I do in the JS version. I first add a <p>
around anything that is not allowed as a direct child via the schema; of course you'll want to take special care for the <md>/<m>
tags, as you pointed out to me)
I am not sure what @test refers to
<xsl:if test="ol|ul|dl|me|men|md|mdn|cd">
I don't think ol|ul|dl
are necessary as it never happens this way.
Are you saying that the case
<ul>
<li>
<ul><li>foo</li></ul>
</li>
</ul>
is handled elsewhere in the code?
Your interior ul
has to live in a p
, according to the schema. Who knows how permissive the conversions are.
Some exceptions, such as GOAL-LIKE
, presumes an interior list not in a p
.
The ul
is current auto-wrapped in a p
as per line 5919.
Currently when
is processed, the resulting
p
turns into adiv.para.logical
. However,gets an auto-inserted
p
which turns to adiv.para
even though it contains a block element. This PR makes the behavior of the auto-insertedp
consistent.