| Release | Renderer status | Tasks status |
|---|---|---|
| 1.2 | 鉁旓笍 .NET (#1359) 鉁旓笍 Android (#1285) 鉁旓笍 iOS (#1284) 鉁旓笍 TS (#1360) 鉁旓笍 UWP (#1283) |
鉁旓笍 Shared (#1282) 鉁旓笍 Designer (#2674) |

Notice how Android notifications choose to display the button as part of the text input. The payload should allow this flexibility for the host to display the button however makes sense.

On only Input.Text (since that seems to be the only place a quick action would be desired on an input), the following property would be added...
| Property | Type | Required | Description |
|---|---|---|---|
| type| Input.Text | true | |
| inlineAction | Action | false | The inline action for the input. Typically displayed to the right of the input. Strongly recommended you provide an icon on the action (which will be displayed instead of the title of the action). |
{
"type": "Input.Text",
"id": "comment",
"placeholder": "enter comment",
"inlineAction": {
"type": "Action.Submit",
"iconUrl": "ms-appx:///Assets/reply.png",
"title": "Reply"
}
}

Android might display like the following...


Inline expansion of Action.ShowCard is NOT supported (since we don't support inline showcards within the body right now). If a show card is present and the host is configured for inline show cards the action will be dropped and a warning will be returned.
InlineAction (or whatever the renderer standard for style names is) to the button so that hosts can natively style the button as they wishHigh
This will not be able to render properly, and the card will be unfunctional.
Host impact: Medium. Hosts need to update their native styling to include this new InlineAction button.
This is achievable with a ColumnSet with 2 columns; the left one contains the input and has its size property set to stretch, the right one has size = auto and contains the image with its selectAction set.
Good point. I'll close this, thanks!
(nvm, will open new issue on ability to associate input with text box for Ctrl+Enter)
Actually we do have to re-open this. Using two columns with a size = auto on the image column doesn't work, as seen below

There's no way to force the image to match the height of the text box. The airplane seen there displays taller than the text box itself.
Maybe we need a size property on the image itself that is "button" or something? Or even better, "squareButton".
Would the ability to vertically center content in both columns solve the problem?
Vertically center wouldn't force the image to match the height of the text box. If the image is 200 px tall and the text box is only 80 px tall, you're still going to have 60 px of blank space above and below the text box
Why not use an image that's as tall as the input then? You control the input's height. Plus you probably don't want a stretched or downsized image anyway?
How does the card author control the input height? Each card host might have different input heights. We don't want devs needing to provide different images for each host.
Plus, what happens in a future release when a card host decides "My input text boxes are now going to be 90px tall instead of 80px", all existing cards being sent will look incorrect.
Guidance would definitely be "Provide the correct resolution image", but the reality is, that can't be the only solution due to its drawbacks (future app-compat issues being the key drawback).
The host controls the height of the inputs and the available image sizes. It could be a convention that the "small" image size is the same height as an input, but there is no guarantee.
Also the vertical alignment solution I think could be a decent compromise. Yes, there is no guarantee the image would be the same height as the input, but at least things would be properly aligned.
I'm just trying to find a solution in the confines of the format before jumping to the conclusion we need something new. You have great points; I think we'll have to sit together and discuss.
I think a new image size, "size": "squareImageButton" might be the most elegant solution. I prototyped it in the UWP renderer, and this is what it looks like

{
"type": "ColumnSet",
"columns": [
{
"type": "Column",
"size": "stretch",
"items": [
{
"type": "Input.Text",
"id": "textInput",
"placeholder": "reply"
}
]
},
{
"type": "Column",
"size": "auto",
"items": [
{
"type": "Image",
"url": "Assets/Icons/send.png",
"size": "squareImageButton",
"selectAction": {
"type": "Action.Submit",
"title": "Send"
}
}
]
}
]
}
Adding the new size allows hosts to still keep small for a different purpose rather than requiring small to match the height of inputs.
@anbare would you consider this necessary for v1 to ship notifications?
Without this that would mean the story is: "If you want to make a quick reply message toast, you have to use legacy XML"
Maybe that's an ok story, most of the scenarios that require new Card features like ShowCard and hit targets are all using normal buttons rather than quick reply buttons. But it's definitely not a perfect story.
What if we add something semantic like quickReplyAction on Input.Text (since that seems to be the only real-world scenario where a quick-reply would be used).
We would also need to get in #389 Action/Image support
{
"type": "Input.Text",
"id": "comment",
"placeholder": "enter comment",
"maxLength": 500,
"isMultiline": false,
"speak": "What comments do you have?",
"value": "This is a pre-filled value",
"defaultAction": {
"showButton": false,
"action": {
"type": "Action.Submit"
}
}
}
Proposal needs more review time. Concerns around...
Proposal is ready for another round of review
Proposal approved. Open question around vertical alignment as the input grows. Align to the bottom? That's what Windows does.
I think that we'll need an iconSize property as we have in the Icons in Actions fir the renderers that cannot easily calculate the height of the text box (HTML and Typescript).
Most helpful comment
What if we add something semantic like
quickReplyActiononInput.Text(since that seems to be the only real-world scenario where a quick-reply would be used).We would also need to get in #389 Action/Image support