Proposal: Unify document formatting between RichEditBox and RichTextBlock

[cghersi]

Summary

Currently the way in which you format the text in RichEditBox and RichTextBlock is pretty different. A new (set of) API that enables a common way to set formatting properties for those two (quite connected) elements would ease maintenance of UWP projects as well as speed up development and reduce bugs due to lack of sync in the two scenarios.

Rationale

Often RichEditBox and RichTextBlock are used together to provide a Read-Only / Edit Mode for text-centric control.
Depending on the Modality, the developer has to apply a coherent set of formatting options to those two controls.
The most immediate way a developer could think of, in such a rich and powerful environment, is to set the properties of an ITextDocument.

As part of these unifying effort, a basic type supporting strings with specific format (similar to the iOS version of NSAttributedString) would be quite handy: it should be available in the .NET Standard specification, and few API to set / append such AttributedStrings to an ITextDocument would enormously ease the effort for the UWP App developers.

[verelpode]

I experience much the same problem as @cghersi described. My preferred solution/proposal is to make a Blocks property in RichEditBox and/or RichEditTextDocument the same as RichTextBlock.Blocks. This is the same principle as how it worked in WPF -- see System.Windows.Documents.FlowDocument.Blocks.

This new Blocks property might be easier to implement if it operates on-demand or as a conversion, meaning there is no requirement to radically change the internal representation to use Blocks. The internal representation of the rich text can be anything, but there should exist a way to convert to and from Windows.UI.Xaml.Documents.BlockCollection. Thus I believe it would be acceptable if the WinUI team decides to make the getter of RichEditTextDocument.Blocks return a newly-created BlockCollection each time it is invoked, but if that's how it works (as a conversion), then I suggest making new methods instead of a Blocks property, as follows:

class RichEditTextDocument
{
    ...
    // Already exists:
    public ITextRange GetRange(int startPosition, int endPosition);

    // Proposal:
    public BlockCollection GetRangeAsBlocks(int startPosition, int endPosition);
    // Convert entire document/content to blocks:
    public BlockCollection ToBlocks();
   
    public void ReplaceRange(int startPosition, int endPosition, BlockCollection newContent);

    public void ReplaceAll(BlockCollection newContent);

    // For use with GetRange and GetRangeAsBlocks etc:
    public int Length { get; }
    // Alternatively Length could be named:
    public int EndPosition { get; }
}

Re the proposed "Length" or "EndPosition" property, I was surprised to see that this doesn't already exist, considering that RichEditTextDocument.GetRange(int startPosition, int endPosition) does already exist.