[Spec] Split ILabel interfaces

TextType-specific Labels in Core

The Forms implementation of the various text types and formatting options for Label is ... awkward. There's the default Label stuff, there's FormattedText, and there's TextType.HTML. It makes the renderers difficult because they must handle transitions and conflict between different text types and incompatible properties (e.g., what does CharacterSpacing do in an HTML Label? How does TextColor affect FormattedText (where Spans have their own color information)?, and many others). And the behavior isn't consistent across platforms.

We can't avoid pulling the current Controls.Label behavior forward into Maui.Controls (because migration), but we can avoid pushing all these problems onto everyone else. And we can set ourselves up for better things in the future.

I'm proposing that for Maui.Core, we effectively split this into three separate types: Label, FormattedLabel, and HtmlLabel.

API

Interfaces

ILabel is the only one of these we absolutely need for Stable. The rest could possibly be in a future release. (A '*' next to a property means that I'm not sure yet if the property is appropriate for the label type.)

ILabel {
	Font {get;}
	Alignment {get;}
	LineBreakMode {get;}
	LineHeight {get;}
	MaxLines {get;}
	Padding {get;}
	Text {get;}
	TextBrush {get;}
	TextDecorations {get;}
	CharacterSpacing {get;}
}	

IFormattedLabel {
	Text {get;} (-> FormattedText)
	Font* {get;}
	LineBreakMode* {get;}
	MaxLines* {get;}
	Padding {get;}
	TextColor* {get;}
	TextDecorations* {get;}
	CharacterSpacing* {get;}
}

IHtmlLabel {
	Text  {get;} (-> HTML)
	LineBreakMode* {get;}
	MaxLines* {get;}
	Padding* {get;}
}

ISpan {
// We'll need this for IFormattedLabel
}

Handlers

In Core

LabelHandler

Handles ILabel; most of the work is done in extension methods which we can also use for the Controls.LabelHandler

FormattedLabelHandler

Handles IFormattedLabel. Most of the work is done in extension methods. Some of this can be reused for the Controls.LabelHandler. This doesn't necessarily have to be implemented for Stable; we could add it later.

HtmlLabelHandler

Handles IHtmlLabel. Most of the work is done in extension methods. Some of this can be reused for the Controls.LabelHandler. This doesn't necessarily have to be implemented for Stable; we could add it later.

In Controls

Controls.LabelHandler

Handles ILabel in Controls. Also handles a bunch of Controls.Label-only properties (like TextType). This is basically the renderer we have now. We implement this for compatibility/migration reasons.

Label

The current Label type. It implements ILabel, but none of the other interfaces. It retains properties like FormattedText, but they don't map to the interfaces. Instead, it uses the Controls.LabelHandler. Once FormattedLabel and HtmlLabel are available, we mark properties like TextType and FormattedText as obsolete.

FormattedLabel

A new type to be introduced when we've got the time. This maps directly to IFormattedLabel, and uses the default IFormattedLabel handler. The handler will map it only to the native formatted text types, and only in formatted text mode.

HtmlLabel

A new type to be introduced when we've got the time. This maps directly to IHtmlLabel, and uses the default IHtmlLabel handler. The handler will map it only to the native HTML-capable text types, and only in HTML mode.

Developer Experience

Forms migration should be mostly seamless - everything just works the same (bugs and all). The only change is that when the new Label types become available (either at Stable or later on), a couple of the properties will be marked Obsolete.

For other SDKs (like Comet), formatted text and HTML text won't be available until we release the interfaces and handlers for those in Core. That could be at Stable, or possibly later. Basic Label stuff will be available at Stable.

If/When Forms users migrate to the new Label types, some of the old behaviors will change to things which make more sense. For instance, they'll have to handle text color in the HTML of an HtmlLabel, rather than using a TextColor property (which doesn't work consistently in Forms anyway).

Backward Compatibility

For Controls, nothing changes from Forms (at least for the first Stable release).

Difficulty : Medium

Start by reviewing the proposed ILabel, IFormattedLabel, IHtmlLabel, and ISpan contracts alongside the existing Controls.Label and LabelHandler behavior described in the issue. Done means the scope and API are resolved, with the stable ILabel and corresponding Core LabelHandler approach agreed and implemented without breaking Controls compatibility.