fontType property on TextBlock

[tongyliu]

Release	Renderer status	Tasks status
1.2	✔️ .NET (#1967) ✔️ Android (#1964) ✔️ iOS (#1965) ✔️ TS (#2430) ✔️ UWP (#1963)	✔️ Shared (#1962)

Solves requests

• Monospace blocks of text (Request: Monospace blocks of text #1982)
  • OPEN ISSUE: Would we need author ability to disable markdown so that spaces are preserved? Replacing them with   would be a huge amount of bloat

Solution

Add an additional fontType property to TextBlocks, with configurable fonts for each possible fontType value in host config. Monospace blocks of text can be achieved by using a container with emphasis style.

Schema

New property on TextBlock

Property	Type	Required	Description
fontType	FontType	false	Changes the font style

FontType

Value	Description
default	The default font type
monospace	The monospace font type

Markup:

{
    "type": "TextBlock",
    "size": "large",
    "weight": "bolder",
    "text": "14,411 ft",
    "fontType": "monospace"
}

Why "fontType"?

• Didn't choose just style since we might want to use style for something else
• Didn't choose textStyle since can imagine this font style being useful in other places, like Actions, where the text property is called title rather than text, so font is applicable to both.
• Didn't choose fontStyle since in HTML/UWP/Android, fontStyle (or textStyle) is used for italic/bold, not font families
• Didn't choose fontFamily for reasons specified in a comment below
• Didn't choose font since font is supposed to be a collection of fontFamily + size + weights

Host Config

Add new fontTypes property, which allows defining the font type for each type. Inside each, can set the fontFamily, and also the font sizes, since different fonts may appear larger or smaller. Can set font weights for same reason.

If some properties on a style aren't specified, inherits the properties from the default style.

Deprecate existing fontFamily, fontSizes, and fontWeights properties in exchange for the new fontTypes.

If a host didn't provide the default style but provided the old deprecated properties, those old deprecated properties should be utilized as the default style (and those should be inherited to other styles that also aren't specified).

{
    "fontTypes": {
        "default": {
            "fontFamily": "Arial, sans-serif",
            "fontSizes": {
                "small": 12,
                "default": 14,
                "medium": 17,
                "large": 21,
                "extraLarge": 26
            },
            "fontWeights": {
                "lighter": 200,
                "default": 400,
                "bolder": 600
            }
        },
        "monospace": {
            "fontFamily": "Consolas, serif",
            "fontSizes": {
                "small": 12,
                "default": 14,
                "medium": 17,
                "large": 21,
                "extraLarge": 26
            },
            "fontWeights": {
                "lighter": 200,
                "default": 400,
                "bolder": 600
            }
        }
    }
}

Down-level impact

Low. Text appears and displays pretty well. It simply doesn't have the correct font family.

Host burden

Medium. Changes in structure of host config.

Renderer Requirements

1. A renderer must use correct inheritance of host config unspecified values
2. For a given fontType, if the fontTypes.[specifiedStyle].[property] value exists, use its value
3. Otherwise, if wasn't default, see if the default has a value for that
4. Otherwise, see if the deprecated property has a value for that
5. Otherwise, use initial default value
6. A renderer should support displaying the correct fontTypes

Auto-generated task status

• Shared
• .NET
• Android
• iOS
• TS
• UWP

[andrewleader]

Final spec needed. Also, hosts should be able to define different font sizes for each font in host config, since Consolas 11pt looks bigger than Segoe UI 11pt font.

[dclaux]

Looks good for me overall. Only thing is I'm no fan of the term "display" - whether you use the default, display or monospace font styles, they are all for "display". I suggest we go for something like "alternate" or similar.

[andrewleader]

Agreed - maybe "statistic"? Since that's what it's typically used for?

[mdtauk]

Display is an existing term in type design, alongside "text" fonts. The opposite to Monospaced is Proportional fonts

[carlos-zamora]

Do we want a warning(s) in some cases where inheritance goes into action. So far I've thought about the following cases and results:

1. If hostConfig defines any of the deprecated properties
   --> Warning: [property] has been deprecated. Use AdaptiveHostConfig.FontStyles.Default.[property] instead.
2. If fontStyle.default wasn't defined
   --> Warning: FontStyle.Default wasn't defined. Inheriting font style from deprecated properties.
   or
   --> Warning: FontStyle.Default wasn't defined. Using system default instead.
3. If fontStyle.[specifiedStyle] wasn't defined
   --> Warning: FontStyle.[specifiedStyle] wasn't defined. Using FontStyle.Default instead.
4. If the desired fontStyles.[specifiedStyle].[property] wasn't defined
   --> Warning: FontStyle.[specifiedStyle].[property] wasn't defined. Using system default instead.
   or
   --> Warning: FontStyle.[specifiedStyle].[property] wasn't defined. Using FontStyle.Default instead.

Also, do we want multiple warnings to occur from the same issue?

[andrewleader]

Good point! I suppose avoiding multiple warnings would be nice, but not too critical. We definitely should have those warnings!

[dclaux]

Are we still going with "display"? I would really prefer "monospace" to make it super clear that's what it is. Authors that will use that style need to know that the host will use a monospace font, given that type of scenarios (e.g. simple tables) this is for.

[andrewleader]

@dclaux the font Bing wants is NOT monospace (I measured it)

[mdtauk]

That Bing example uses a Serif font while the normal text is Sans Serif As most platforms do not offer both a Sans and Serif version of their UI fonts, if you wanted to include a Monospace, Proportional Sans and a Proportional Sans Serif as font styles, then that is extra work for the Host Config in the chosen platform renderer. Georgia is available on most platforms, that is a Serif type family. Microsoft uses Consolas for its go to Monospace font.

[dclaux]

Sorry, there was some confusion on my side here. I thought we were doing this solely for monospace font support, I didn’t realize for some reason that we also were talking about allowing an alternate font. I am not a huge fan of allowing that alternate font style (I know my designer won’t like it at all). I suppose I could live with it, but honestly the sole example provided hardly justifies it imo. I would suggest not doing it until we can gather more evidence that it is actually needed. If we are going to do it, I would use the term “alternate” rather than “display” or whatnot to emphasize that card authors shouldn’t expect this font to be anything in particular. I would also say that we should probably never offer serif vs sans serif font styles as that would have the potential of letting authors create very ugly cards. Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Martin Anderson <[email protected]> Sent: Wednesday, October 3, 2018 3:34:49 PM To: Microsoft/AdaptiveCards Cc: David Claux; Mention Subject: Re: [Microsoft/AdaptiveCards] Spec: fontStyle property on TextBlock (#1078) That Bing example uses a Serif font while the normal text is Sans Serif As most platforms do not offer both a Sans and Serif version of their UI fonts, if you wanted to include a Monospace, Proportional Sans and a Proportional Sans Serif as font styles, then that is extra work for the Host Config in the chosen platform renderer. Georgia is available on most platforms, that is a Serif type family. Microsoft uses Consolas for its go to Monospace font. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2FAdaptiveCards%2Fissues%2F1078%23issuecomment-426826142&data=02%7C01%7Cdclaux%40microsoft.com%7C4a700c582aef4f55768d08d629806e01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636742028911673085&sdata=%2B%2FaJ4QuexOhD3xJwrhuqVvsbD9cgDEVMy44WaZC9SVQ%3D&reserved=0>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABRdoTc9dH-wZynxaRw0yQGwrO4zPYnFks5uhTuJgaJpZM4Rgm4s&data=02%7C01%7Cdclaux%40microsoft.com%7C4a700c582aef4f55768d08d629806e01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636742028911683094&sdata=s24FHFt3y8GDQTeUwOptTGFduB5NFibBSwR%2Flvn3gJk%3D&reserved=0>.

[andrewleader]

@matthidinger to speak to the priority of the Bing "display" font feature request.

I like the term alternative, although it's not very semantic, alternative could actually be less prominent. What they're trying to achieve is a more prominent font. Maybe featured or something. I also suggested statistic, since this is typically used when displaying statistics.

Outlook (and other hosts) don't have to provide an alternative font. They could always have it use the normal font, just like they don't have to provide a monospace font either.

[dclaux]

While it is true that host don’t necessarily have to provide an alternate font, if they don’t they run the risk of developers complaining for a bug that isn’t one, eventually forcing the host to support the alternate style. Let’s hear from Matt and Bing, but I do believe we need much stronger evidence than the one screenshot provided. It seems to me that using the default font in that card would be a more than acceptable compromise. Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Andrew Leader <[email protected]> Sent: Wednesday, October 3, 2018 4:11:34 PM To: Microsoft/AdaptiveCards Cc: David Claux; Mention Subject: Re: [Microsoft/AdaptiveCards] Spec: fontStyle property on TextBlock (#1078) @matthidinger<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmatthidinger&data=02%7C01%7Cdclaux%40microsoft.com%7C27dd520227f64e3d4a0508d629859028%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636742050958951032&sdata=%2FESrNZULsg4vzeg%2BfN48h4KEGGA3v0l6SVStK9hwdak%3D&reserved=0> to speak to the priority of the Bing "display" font feature request. I like the term alternative, although it's not very semantic, alternative could actually be less prominent. What they're trying to achieve is a more prominent font. Maybe featured or something. I also suggested statistic, since this is typically used when displaying statistics. Outlook (and other hosts) don't have to provide an alternative font. They could always have it use the normal font, just like they don't have to provide a monospace font either. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2FAdaptiveCards%2Fissues%2F1078%23issuecomment-426833425&data=02%7C01%7Cdclaux%40microsoft.com%7C27dd520227f64e3d4a0508d629859028%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636742050958951032&sdata=N2a3Ov0QJtP6rg2tWLvTMZ6Er6WSKzrwNNcqhCECs0I%3D&reserved=0>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABRdoQnTsxM65u22Zvbd45ORi7nzq8vuks5uhUQmgaJpZM4Rgm4s&data=02%7C01%7Cdclaux%40microsoft.com%7C27dd520227f64e3d4a0508d629859028%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636742050958961046&sdata=ewNXu6c7iNRf2UjiO0bObFBiYP8x370Rj6nqm%2Fmkwm8%3D&reserved=0>.

[dclaux]

Can we close on this? I still have the same concerns about the "display" font:

• I don't think we should have it:
  • The only one example provided doesn't justify adding it
  • While if we do have it hosts can basically make "default" and "display" the same, partners/developers will think there's a bug when their card doesn't actually use two distinct fonts in some hosts (like Outlook)
• If we do have it
  • The term "display" is meaningless to the people who author cards (developers in general). We'd need a term that clearly identifies the font style as an alternative to "default": all font styles are for display purposes after all.

About the monospace font style - it is supposed to help create simple tables or code blocks. But Markdown collapses consecutive spaces. So we have two choices:

• No Markdown for TextBlocks that use the monospace style
• We don't introduce the monospace font style, and instead provide another way to do a code block/simple table by, for instance, introducing a CodeBlock element

If we were to do the latter, then there would be no remaining reason to support fontStyle on TextBlock.

[andrewleader]

@matthidinger to speak towards whether Bing needs a "display" (or whatever we choose to call it) font for 1.2. An alternative could be that Bing uses extensibility, but we did already approve the proposal to add two font styles (monospace and display). I'm happy to find a better name for it! Or if Bing doesn't need it (or can use extensibility), I'm happy to cut it!

For the monospace concern, we could add the isMarkdown property. That's how I'd personally solve it. Thoughts @matthidinger?

[dclaux]

I am fine with the isMarkdown property as a solution. I would however call it useMarkdown, and I would also consider adding it to all containers (including the card itself) to make it easy to disable markdown for all or part of the card in one shot.

@matthidinger looking to hearing from you about the need for a "display" font. Adding this just for Bing and for that particular scenario doesn't feel right to me.

[andrewleader]

Consensus was to remove the display value (so we're only adding monospace). Updated the spec to reflect that.

[andrewleader]

Spec changes from meeting today with Andrew, Becky, David, and Mike

DECISION: Rename to fontType, since it refers to picking a collection of a set of values.

Card authors send...

{
    "type": "TextBlock",
    "text": "Text to display",
    "weight": "bold",
    "size": "large",
    "fontType": "default | monospace", // New property
}

Hosts in HostConfig specify

{
    "fontTypes": {
        "default": {
            "fontFamily": "Segoe UI, Tahoma, Geneva, Verdana, sans-serif",
            "fontSizes": {
                "small": 12,
                "default": 14,
                "medium": 17,
                "large": 21,
                "extraLarge": 26
            },
            "fontWeights": {
                "lighter": 200,
                "default": 400,
                "bolder": 600
            }
        },
        "monospace": {
            "fontFamily": "Consolas",
            "fontSizes": {
                "small": 11,
                "default": 13,
                "medium": 16,
                "large": 19,
                "extraLarge": 24
            },
            "fontWeights": {
                "lighter": 200,
                "default": 400,
                "bolder": 600
            }
        }
    }
}

For record purposes, other options we considered...

Call it fontFamily

Card authors send...

{
    "type": "TextBlock",
    "text": "Text to display",
    "weight": "bold",
    "size": "large",
    "fontFamily": "default | monospace", // New property
}

Hosts in HostConfig specify

{
    "fontFamilies": {
        "default": {
            "fontFamily": "Segoe UI, Tahoma, Geneva, Verdana, sans-serif",
            "fontSizes": {
                "small": 12,
                ...
            },
            "fontWeights": {
                ...
            }
        },
        "monospace": {
            ...
        }
    }
}

Concerns:

• David and Becky feel that the fact that fontFamilies has a property in it called fontFamily plus the other properties is odd

Call it fontFamily for authors, and fonts for hosts

Card authors send...

{
    "type": "TextBlock",
    "text": "Text to display",
    "weight": "bold",
    "size": "large",
    "fontFamily": "default | monospace", // New property
}

Hosts in HostConfig specify

{
    "fonts": {
        "default": {
            "fontFamily": "Segoe UI, Tahoma, Geneva, Verdana, sans-serif",
            "fontSizes": {
                "small": 12,
                ...
            },
            "fontWeights": {
                ...
            }
        },
        "monospace": {
            ...
        }
    }
}

Concerns:

• David and Becky feel that what the property is called in the card must correlate to what the property is called in the host config

Call it fontStyle

Card authors send...

{
    "type": "TextBlock",
    "text": "Text to display",
    "weight": "bold",
    "size": "large",
    "fontStyle": "default | monospace", // New property
}

Hosts in HostConfig specify

{
    "fontStyles": {
        "default": {
            "fontFamily": "Segoe UI, Tahoma, Geneva, Verdana, sans-serif",
            "fontSizes": {
                "small": 12,
                ...
            },
            "fontWeights": {
                ...
            }
        },
        "monospace": {
            ...
        }
    }
}

Concerns:

• Andrew and Mike feel concerned with overloading terminology of HTML/XAML/Android. In HTML and XAML, fontStyle is used solely for "italic | oblique". Android calls textStyle="normal|bold|italic", so similarly the style is referring to modifications to the font family.

[dclaux]

Implemented here: #2905