Version: 4.3.2 Reporter: Paul Bailey —
mod note- originally reported in v3
Two separate issues here, but both relate to XHTML parsing of list tags. Tested with EE3.5.10, but I believe the issues have been around for a while.
Firstly, when lists are nested, main list items after the first seem to have
tags applied spuriously. For example, the below is already valid XHTML, so nothing should be added:
<ul>
<li>Item 1
<ul>
<li>Sub-item 1.1</li>
<li>Sub-item 1.2</li>
<li>Sub-item 1.3</li>
</ul>
</li>
<li>Item 2
<ul>
<li>Sub-item 2.1</li>
<li>Sub-item 2.2</li>
<li>Sub-item 2.3</li>
</ul>
</li>
<li>Item 3
<ul>
<li>Sub-item 3.1</li>
<li>Sub-item 3.2</li>
<li>Sub-item 3.3</li>
</ul>
</li>
</ul>This is rendered as:
<ul>
<li>Item 1
<ul>
<li>Sub-item 1.1</li>
<li>Sub-item 1.2</li>
<li>Sub-item 1.3</li>
</ul>
</li>
<li>Item 2<ul>
<li>Sub-item 2.1</li>
<li>Sub-item 2.2</li>
<li>Sub-item 2.3</li>
</ul>
</li>
<li>Item 3<ul>
<li>Sub-item 3.1</li>
<li>Sub-item 3.2</li>
<li>Sub-item 3.3</li>
</ul>
</li>
</ul>Note the
tags added to Items 2 and 3 (and the removal of the line-breaks after each of those items). I’ve tested this with a longer list, and it seems to persist. Only the first main list item doesn’t have the spurious
tag applied. This behaviour is easily squished visually in CSS, but what the parser is doing isn’t necessary or consistent.
Secondly, list tags which are indented with spaces seem to produce spurious non-breaking spaces in the XTML parse. For example, using three spaces to indent list items as follows:
<ul>
<li>Item 1
<ul>
<li>Sub-item 1.1</li>
<li>Sub-item 1.2</li>
<li>Sub-item 1.3</li>
</ul>
</li>
<li>Item 2
<ul>
<li>Sub-item 2.1</li>
<li>Sub-item 2.2</li>
<li>Sub-item 2.3</li>
</ul>
</li>
<li>Item 3
<ul>
<li>Sub-item 3.1</li>
<li>Sub-item 3.2</li>
<li>Sub-item 3.3</li>
</ul>
</li>
</ul>
the code is rendered as:
[code]
<ul>
<li>Item 1
<ul>
<li>Sub-item 1.1</li>
<li>Sub-item 1.2</li>
<li>Sub-item 1.3</li>
</ul>
</li>
<li>Item 2<ul>
<li>Sub-item 2.1</li>
<li>Sub-item 2.2</li>
<li>Sub-item 2.3</li>
</ul>
</li>
<li>Item 3<ul>
<li>Sub-item 3.1</li>
<li>Sub-item 3.2</li>
<li>Sub-item 3.3</li>
</ul>
</li>
</ul>With additional indenting to show the tag structure more clearly:
<ul>
<li>Item 1
<ul>
<li>Sub-item 1.1</li>
<li>Sub-item 1.2</li>
<li>Sub-item 1.3</li>
</ul>
</li>
<li>Item 2
<ul>
<li>Sub-item 2.1</li>
<li>Sub-item 2.2</li>
<li>Sub-item 2.3</li>
</ul>
</li>
<li>Item 3
<ul>
<li>Sub-item 3.1</li>
<li>Sub-item 3.2</li>
<li>Sub-item 3.3</li>
</ul>
</li>
</ul>more spurious non-breaking spaces are added:
<ul>
<li>Item 1
<ul>
<li>Sub-item 1.1</li>
<li>Sub-item 1.2</li>
<li>Sub-item 1.3</li>
</ul>
</li>
<li>Item 2
<ul>
<li>Sub-item 2.1</li>
<li>Sub-item 2.2</li>
<li>Sub-item 2.3</li>
</ul>
</li>
<li>Item 3
<ul>
<li>Sub-item 3.1</li>
<li>Sub-item 3.2</li>
<li>Sub-item 3.3</li>
</ul>
</li>
</ul>In all of the above cases, the original code passed to EE is already standard XHTML, so nothing needs to be added or modified. It’s very useful when laying out code for clarity to be able to indent, without this causing the addition of spurious code in the parse.
I see a discussion of the issue where non-breaking spaces are added in the bug tracker from about three years ago, but it doesn’t look like it was formally accepted as a bug. My reading of the XHTML spec is that the only valid content inside
<ul>and
<ol>tags are
<li>list items, which would mean that the addition of non-breaking spaces actually breaks XHTML that’s already valid.
ExpressionEngine implements Markdown Extra and BBCode. Please see the Markdown Extra docs and the BBCode Wikipedia article for a full reference.
**bold**, __bold__, *italics*, _italics_, ~strike/del~, `code()`
bold, italics, strike/del, code()
Link: [link title](https://example.com)
Image: 
[blockquote]...[/blockquote], [quote]...[/quote], and Markdown style:
> Some quoted text. > > This is all one quote.
[code]...[/code], and you can also specify the language for syntax highlighting, [code=php]...[/code]
GitHub flavored Markdown code fences are also supported:
```
public function decoderRing($str)
{
return str_rot13($str);
}
```