Background

Originally posted by @michael-hawker in #684 (review)

I love the idea of translating lists into text instead of custom UI, makes a lot of sense and resolves a lot of issues with accessibility and copying.

Seeing how this works, I think the crux of the issue is that a List is contained in a Paragraph and we need to modify the properties of the parent paragraph to make this work/look good.

I'm wondering if we can be better here about using parsing to detect this or having the List Renderer make/be a paragraph vs. having to connect state between the paragraph and lists between the renderer. @nerocui any insights here?

I'd have to look at the parsing tree here (I wrote a tool for that actually a few weekends back, but still need to publish it.) Like I just wonder if in all cases a list is just encapsulated by a paragraph and any text before/after is a separate paragraph. If so, we should just make a dedicated "BulletedParagraph" type which will just output the final result that he Listrenderer does vs. it being a thing which needs to coordinate with the general paragraph.

Problem

The state handling implemented in #684 weaves List-specific state management into the WinUIRenderer, and weaves the WinUIRenderer into the MyParagraph and ListRenderer classes to access and update this state.

If this pattern is consistently followed for the rest of the MarkdownTextBlock implementation, the code will become difficult to maintain and extend.

Solution

A cleaner approach should be found that still achieves the desired selection behavior on rendered objects without storing implementation state on the WinUIRenderer container.