[Document lists] Research the approach to the conversion in GHS

[niegowski]

• Try exposing conversion helper from DocListProps
  • Check feasibility
  • PoC of it used in GHS to handle attrs of ul/ol and li

[Reinmar]

🟢 Scenario 1 (that works)

Set data:

<paragraph listIndent=0>x</paragraph>
<paragraph listIndent=1>y</paragraph>

Conversion to view:

• listIndent=0 -> wraps the <p> in <li> and <ul>
• listIndent=1 -> wraps the <p> in <li> and <ul> and <li> and <ul>

At some point we have this in the view:

<ul><li><p>x</p></li></ul>
<ul><li><ul><li><p>y</p></li></ul></li></ul>

Thanks to ul and li being attribute elements, the uls and lis that are "similar" are merged into:

<ul><li><p>x</p>  [</li></ul>
<ul><li>]   <ul><li><p>y</p></li></ul></li></ul>

(everything between [] is deleted on this merge)

Finally, we get this:

<ul><li>
    <p>x</p>
    <ul><li>
        <p>y</p>
    </li></ul>
</li></ul>

🟢 Scenario 2 (that still works)

Set data:

<paragraph listItemId=a listIndent=0>x1</paragraph>
<paragraph listItemId=a listIndent=0>x2</paragraph>
<paragraph listItemId=b listIndent=1>y</paragraph>

... conversion happens

At some point we have this in the view:

<ul><li _id=a><p>x1</p></li></ul>
<ul><li _id=a><p>x2</p></li></ul>
<ul><li _id=a><ul><li _id=b><p>y</p></li></ul></li></ul>

.... merging happens

Finally, we get this:

<ul><li>
    <p>x1</p>
    <p>x2</p>
    <ul><li>
        <p>y</p>
    </li></ul>
</li></ul>

🟢 Scenario 3 (that still works)

Set data:

<paragraph listItemId=a listIndent=0 listStyle=Q>x1</paragraph>
<paragraph listItemId=a listIndent=0 listStyle=Q>x2</paragraph>
<paragraph listItemId=b listIndent=1 listStyle=Q>y</paragraph>

... base conversion of lists happens

At some point we have this in the view:

<ul><li _id=a><p>x1</p></li></ul>
<ul><li _id=a><p>x2</p></li></ul>
<ul><li _id=a><ul><li _id=b><p>y</p></li></ul></li></ul>

Then, listStyle conversion kicks in. It wraps e.g. <p>x1</p> in another <ul style=Q> structure. But since the outermost uls are "similar" (<ul style=Q><ul> -> <ul style=Q>) we get this:

<ul style=Q><li _id=a><p>x1</p></li></ul>
<ul style=Q><li _id=a><p>x2</p></li></ul>
<ul style=Q><li _id=a><ul style=Q><li _id=b><p>y</p></li></ul></li></ul>

.... then merging happens

Finally, we get this:

<ul style=Q><li>
    <p>x1</p>
    <p>x2</p>
    <ul style=Q><li>
        <p>y</p>
    </li></ul>
</li></ul>

🔴  Scenario 4 (that doesn't work)

Set data:

<paragraph listItemId=a listIndent=0 listStyle=Q htmlLiAttributes=W>x1</paragraph>
<paragraph listItemId=a listIndent=0 listStyle=Q htmlLiAttributes=W>x2</paragraph>
<paragraph listItemId=b listIndent=1 listStyle=Q>y</paragraph>

... conversion happens

At some point we have this in the view:

<ul><li _id=a><p>x1</p></li></ul>
<ul><li _id=a><p>x2</p></li></ul>
<ul><li _id=a><ul style=Q><li _id=b><p>y</p></li></ul></li></ul>

Then, listStyle conversion kicks in. It wraps e.g. <p>x1</p> in another <ul style=Q><li> structure. But since outermost lis and uls are "similar" we get this:

<ul style=Q><li _id=a><p>x1</p></li></ul>
<ul style=Q><li _id=a><p>x2</p></li></ul>
<ul style=Q><li _id=a><ul style=Q><li _id=b><p>y</p></li></ul></li></ul>

Then GHS's converter kicks in. It wraps those blocks again in another ul/lis. Situation before GHS's elements get merged with their siblings:

<ul style=Q><li _id=a W><li _id=a><p>x1</p></li></ul>
<ul style=Q><li _id=a W><li _id=a><p>x2</p></li></ul>
<ul style=Q><li _id=a W><li _id=a><ul style=Q><li _id=b><p>y</p></li></ul></li></ul>

We'd like <li _id=a W><li _id=a> to get merged into a single <li W _id=a> but IDs prevent merging.

PROBLEM ☝️

[Reinmar]

Ideas:

• Maybe we could stop using IDs at all and instead override isSimilar() so it uses some custom property.
• We found out that IDs are handled differently in case of nested and sibling elements. In case of siblings, if IDs are equal, elements get merged. This doesn't happen for nested ones.
  • This seems buggy.
  • Let's try to merge in both cases.
  • Identical IDs mean that both attribute elements came from the same "source" (e.g. the same comment). Then, why having it twice in the model?