Responsive UI support, media queries

Summary

Support allowing authoring a card that works on both wide and small screens, author is able to specify how they want their card to look across different screen widths and whatnot (classic responsive UI).

Requirements

• P0: A single card can be authored that looks great on both narrow (mobile) and wide (desktop) screens

• P3: The card dynamically responds to changes in width without fully re-rendering, so that input values and toggle visibilities are retained while resizing

  • Search team said this was a P3 to P4 to them, they won't have many inputs right now and resizing the window isn't a big concern

Spec/schema

After the proposal process, update this with a link to the spec PR.

Proposed changes

If we use templating...

• We need live data binding. Else re-rendering everything upon screen width change would result in currently typed in input values being lost, current toggled visibilities being lost,etc

It's possible to have live templating, but we'd probably have to explicitly support it on specific properties. I've added live templating support to the text property of text blocks in WPF, which lets you do what's seen below, you could imagine we also add live templating support to isVisible. It requires the AC renderer to have a copy of templating and also be able to ask what properties are used in the templating expression for that specific property, so that it can then re-calculate when any of those properties change

If we add a new ResponsiveContainer...

• You can specify different views for each

If we add Responsive properties on each element...

• whenMedia.screen.height = ">70"?

If we have a "virtual DOM"

What if we had a virtual DOM like React/ReactNative? The Adaptive Card is the "virtual DOM", and then when any data property changes, we re-run the entire templating transform, producing a new Adaptive Card, and then there's a delta helper that identifies the changed elements and the native libraries only have to live update the changes of the card itself. That would mean we even could support live binding in $data clauses and EVERY single property! Wouldn't have to explicitly add support for each individual property

We ultimately need to talk with Search and Cortana more to learn their requirements

Example

Provide an example payload

Host Config

Quickly describe changes to the host config, if any.

Down-level impact

Describe how down-level is impacted for authors.

Host burden

Describe the burden hosts have when we introduce this feature. For example, are they going to have to add something new to their host config or native styling as a result of a new element we're adding? Are there breaking API changes that hosts have to use? Are we deprecating something from host config that could cause potential confusion?

The issue names no files, tests, or implementation entry points; start by resolving the requirements with the Search and Cortana teams and choosing between the proposed responsive-container, responsive-property, templating, or virtual-DOM approaches. Done should include a concrete spec, example payload, host-config and down-level impact, and a defined approach for preserving state during resizing.