Naming of `FormattedText`

[travisleithead]

(This is internal Microsoft feedback from a review of the spec by resident expert @petercon. Re-posting here with permission.)

---

There’s an oddness to the name of this interface in that these objects need to be created before text is formatted, and even after the format() method is called these objects don’t carry any info that reflects that formatting. It seems like StyledText might be more fitting.

DWrite does have the IDWriteTextFormat interface that is somewhat similar in relation to carrying styling info (but not the text itself). It includes several aspects of paragraph styling relevant to layout, as well as the font styling. But it doesn’t include the layout width. In DWrite, the text content and the layout dimensions are input parameters along with IDWriteTextFormat when an IDWriteTextLayout object is created. So, creating an IDWTL is akin to calling FormattedText.format() and getting back

[yjbanov]

It seems the need for the "formatted" qualifier in front of "text" is driven by the fact that Text is already taken. If we picked a different noun, then the qualifier could be used to describe the output of a specific part in the formatting pipeline rather than just for disambiguation. I will shamelessly propose that we use "paragraph" as the main noun that we use over in the Flutter land. Then:

• Paragraph - output of the "build" step, i.e. what's currently referred to as FormattedText. It's not yet shaped.
• ShapedParagraph - output of the "shape" step, it contains all the text metrics. It is currently referred to as FormattedTextParagraph in the proposal.

At this point we have all we need for Flutter use-case, which likely includes games and other WebGL use-cases (more details on why we don't need more than this here). However, for rendering into HTML and/or canvas2d, it may also make sense to have:

• RenderParagraph - this is the combination of ShapedParagraph with HTML/CSS-specific decorations that make sense in the HTML world, but not in WebGL.

[travisleithead]

PR https://github.com/WICG/canvas-formatted-text/pull/39 drops many of the data model interfaces, which helps with reusing the name FormattedText for the output of a format step. I think this is trendering in the right direction, and in accordance with this feedback.

There's a certain consistency for keeping sets of related platform interfaces groups together by functional name for easy discoverability... hence I'm partial to keeping "FormattedText" as a prefix for most of these things.

[travisleithead]

I think this issues is largely resolved now with #39. Of course, names can always be improved. ;)