FITB: Elements not being retained within fillin exercises

[dbrianwalton]

Reports from Chrissy and Andrew state that some elements do not appear inside exercises that are created with the fillin structure.

Chrissy's report thread: https://groups.google.com/g/pretext-dev/c/-AfefZJx-I8/m/c-VNNATVAAAJ
Andrew's report thread: https://groups.google.com/g/pretext-dev/c/wmvrpWwOABM/m/DpvBbkrjCAAJ

Chrissy reported issues with images sometimes not appearing:

I went ahead and converted my fill-in exercise to use the new markup, but something kind of weird happened. I have an image in the statement of the problem, and I had been under the impression that image could be a child of figure or statement, but not

. So it was a child of the statement in the old markup.

When I switched to the new markup, the image did not show - only the short description text did. I put a paragraph around it, and it did show, and build with no errors or warnings. It also works inside a figure, but I didn't really want the numbering.

and issues with links inside the fillin exercises:

Here's the live version with the old markup: Exercise 1.: How a matrix is indexed
When you enter any number other than 6 or -2, the feedback prompts you with an xref to where this notation was defined, in the Definition of a Matrix. In the old markup, the link that goes to that definition.

When I switch to the new markup, the link is just to the section, not the definition specifically. The live version with the new markup is Exercise 2.: How a matrix is indexed

Andrew reported additional issues:

According to the schema, exercise statement should allow for elements like , etc... And those elements work fine in other exercises.

But in fillins, most of those are getting dropped in the JSONification of the statement element.

Is this a known issue?

I didn't do an exhaustive test, but program, pre, and image all are dropped. Tables do make it through.

I do plan to dig into this, and am not yet sure if this is an issue on the PreTeXt side — it could be due to working on XML stubs in the XSL processing — or on the Runestone side — the RS javascript HTML insertion process may have side effects.

Submitting this issue so that it is formally tracked.

[ascholerChemeketa]

I am pretty sure they are being dropped in the PTX processing. If you check the HTML file that is produced and examine the JSON blob that has the markup for the statement that RS is supposed to display, there is no sign of the elements.

[ascholerChemeketa]

@dbrianwalton An unrelated issue you might want to fix when you check on this:

When a fillin is in an exercise-like with a label, it appears the same html id is getting applied to the exercise and the <div data-component="fillintheblank"

This

  <exercise label="programming_11">
    <statement>
      <p>Fill in the missing pieces:</p>
      <p>
        <c>#include &lt;</c>
        <fillin mode="string" case="insensitive" answer="iostream"/>
        <c>&gt;</c>
        ...

Produces:

<article class="exercise exercise-like" id="programming_11"><h3 class="heading"><span class="codenumber">11<span class="period">.</span></span></h3>
<div class="ptx-runestone-container"><div class="runestone">
<div data-component="fillintheblank" class="fillintheblank" style="visibility: hidden;" id="programming_11">
...

I'm not sure if you want to use the runestone-id template instead of the html-id or not on line 50 of pretext-runestone-fitb.xsl, but with either one, you probably need to decorate the retried id to make it unique when it is applied to the div.

[ascholerChemeketa]

@dbrianwalton - A possibly related issue with processing the elements inside fillins.

entity codes in <feedback> fail to make it through to the final output when inside <c>.

This:

          <feedback>Incorrect, Try again! Hint: what word do we put before<c>vector &lt;TYPE &gt;</c></feedback>

Turns into:

"feedback": "Incorrect, Try again! Hint: what word do we put before vector <code xmlns:pf=\"https:\/\/prefigure.org\" class=\"code-inline tex2jax_ignore\">vector <TYPE ><\/code>"}

Which when rendered, <TYPE> is treated as an HTML tag and not rendered.

If I remove the <c>, the escaped < and > work fine.

Inside the <c> I can make the < appear on the HTML page with this: < and relying on it being transformed to <, but it would be great to not have to anticipate that transformation.

[dbrianwalton]

Thank you for your testing these ideas. I'll add this to my test to verify that the edit will address this.