Introduce AdaptiveCard.requiredHostCapabilities property

[dclaux]

Problem

As the Adaptive Card format and capabilities evolve, card authors will need ways to prevent cards that would not be compatible with older clients from rendering. One such example is inline text highlighting - an older client would not understand the tag and therefore would:

• Not highlight the text
• Render the and tags as plain text
  which would result in a bad experience.

Proposed solution

Introduce a requiredHostCapabilities property on AdaptiveCard that makes it possible for the card author to tie the rendering of the card to the host's ability to handle a set of features. Essentially, requiredHostCapabilities is the equivalent of enabling "feature discovery" in Adaptive Cards, which is usually considered a much more efficient versioning mechanism than a simple version number.

Example

Consider this card:

{
	"type": "AdaptiveCard",
	"version": "1.0",
	"body": [
		{
			"type": "TextBlock",
			"text": "This is <mark>highlighted</mark>"
		}
	]
}

This card would render like this in a v1.0 host:

If the card author wants to enforce that their card is only rendered in hosts that support inline text highlighting, they would add the requiredHostCapabilities property:

{
	"type": "AdaptiveCard",
	"version": "1.0",
	"requiredHostCapabilities": [
		"InlineTextHighlighting"
	],
	"body": [
		{
			"type": "TextBlock",
			"text": "This is <mark>highlighted</mark>"
		}
	]
}

Proposed design

requiredHostCapabilities would be an array of strings, and the accepted values would be officially documented. Beyond the documented values, hosts could have their own named features.

Alt proposed solution

Use data binding with a host runtime object that declares supported features.

This way, authors can change anything they want... they could drop an element, swap an element, swap a specific property, etc. And all we have to do is build the transform language - we don't have to build APIs to do all of those infinitely many things!

{
	"type": "AdaptiveCard",
	"version": "1.0",
	"body": [
		{
			"type": "TextBlock",
			"text": "This is {{host.features.inlineTextHighlighting ? '<mark>highlighted</mark>' : 'highlighted'}}"
		}
	]
}

[andrewleader]

Proposal has concerns: Should it be called "Constraints"? Support things like width, rendererVersion, etc. Do we want fallbacks to be able to be provided?

Does the proposed templating constraints also solve these things like width, etc? Do we end up with duplicated concepts if we add both? We need to investigate these.

Or should each element have a requiredHostCapabilities, and that can cause the fallback strategy discussed in #1587 to kick in?

[andrewleader]

Closing in favor of #2019