Unordered Lists Nested Within Ordered Lists Keep Reverting to Numbers

RyanHayes

One of our faculty is having an issue with lists. The expected behavior has changed within his course and differs from the behavior I see in my dev shell. He creates an Ordered List as shown below. He changes Item 1A to a bullet point and saves the page. The bullet point for Item 1A changes from a bullet point back to 1. I went into his shell tested and had the same issue. I test in one of my dev shells, the bullet point stays. I can get his bullet point to not revert back to the number 1 using the HTML editor. Previously, and in other shells, this could be done within the RCE. I cannot figure out why the nested list (Item 1A keeps reverting back to 1. from •).

1. Item 1
   1. Item 1A
2. Item 2

jeremyfw

What you’re seeing is very consistent with how Canvas’s Rich Content Editor (RCE) normalizes HTML under certain conditions.

Here’s what’s most likely going on.

First, an important grounding fact: Canvas does not actually support mixed list types within the same list structure via the RCE UI. An ordered list (<ol>) that contains a nested unordered list (<ul>) is technically valid HTML, but the RCE aggressively rewrites lists to maintain consistency. When it does that rewrite, it often collapses everything back into a single <ol>.

That explains why:

• The bullet appears to stick initially
• Then reverts back to 1. on save or reload
• But works when manually fixed in the HTML editor

Why does it only happen in this user’s course/account?

The usual causes are one (or more) of these:

1. This is very common and explains why it works in your dev shell but not theirs.
   • One course has a newer RCE build
   • A feature option is enabled/disabled at the account or sub-account level
2. Course copy legacy HTML
   Courses copied forward over multiple terms often contain legacy list markup. The RCE will try to “clean” that markup on save, and in doing so, it flattens mixed lists.
3. Account-level CSS or JS
   Some institutions apply custom CSS/JS that affects list rendering or triggers normalization when content is saved. The instructor won’t see this, but the RCE reacts to it.
4. RCE accessibility normalization
   Canvas has been tightening accessibility rules. Mixed list semantics can get rewritten because screen readers expect consistent list structures.

Why the HTML editor workaround works

When you switch to HTML and explicitly structure it like:

<ol>
  <li>Item 1
    <ul>
      <li>Item 1A</li>
    </ul>
  </li>
  <li>Item 2</li>
</ol>

Canvas will display it correctly, but the moment the RCE touches it again, it may normalize it back unless the structure is very explicit and clean.

Practical recommendations

• Use indentation + numbering styles, not mixed list types, when possible
  This is the only approach that reliably survives RCE edits.
• Edit once in HTML, then avoid reopening in RCE
  If the content must stay mixed, tell the instructor not to toggle back into the visual editor.
• Test in a fresh page
  If it works in a new page but not an old one, legacy HTML is the culprit.
• Check course feature options
  Especially anything related to “New RCE,” “Accessibility,” or beta features.

Bottom line

Nothing is “wrong” with the user. This is a known Canvas RCE limitation combined with rollout differences. Mixed ordered/unordered lists are fragile, and behavior can absolutely vary by course or account even within the same institution.

If you want 100% predictable behavior in Canvas, list purity sadly beats elegance.