Consider renaming `theme` on createSurface to `configuration` and remove `primaryColor` from basic catalog

[jacobsimionato]

I'm wondering if we should remove agent-driven theming because:

• We haven't seen great uptake so far
• It complicates implementing Components, when there is programmatic styling configuration and JSON theming configuration
• Creates a confusing mental model where Components are not really independent from the Catalog that owns them, because their implementation could be coupled to the Catalog's theme structure.
• Other competitors in this space don't have this concept

I think having some type of immutable surface-level config is still helpful, potentially just to include the agent name, logo etc.

Proposal

1. Rename theme to configuration but keep the way it works exactly the same. We will just be allowing catalog designers to specify the structure of some surface-specific information which could be anything, but we aren't suggesting that there should be surface-level theming.

2. Remove primaryColor from the basic catalog configuration, but preserve iconUrl and agentDisplayName, which are really configuration parameters anyway.

This still leaves the door open for people to create catalogs which have surface-level agent-driven theming if they want to, but we background that direction and simplify the basic catalog.

[jacobsimionato]

@ditman @wrenj @dmandar WDYT? I made a similar proposal for v0.9, but I think since then we've continued to see little emphasis on agent-driven theming from customers.

For cases where the customer wants something quite custom, I think Mandar's custom iframe components are a more satisfying solution anyway.

[wrenj]

Let's chat with @jonsharkey first, my understanding is theming is a big part of the material3 catalog cl/891678590. I'd like to get all material design tokens in there. Unlimited theming in MCP Apps iframe is a big draw for partners, so I think we should support it in A2UI too (if renderers want to restrict it that's fine too, but making it a first class concept in the language I think is still important for renderers that want to give a lot of styling control).

[ditman]

QQ: Why does the basic catalog need to support arbitrary theming? If this is a material3 thing, should there be a material3-based catalog for A2UI (now that overriding catalogs is easy)?

[wrenj]

Oh no opinion on basic catalog

I was talking for this proposal:

1. Rename theme to configuration but keep the way it works exactly the same. We will just be allowing catalog designers to specify the structure of some surface-specific information which could be anything, but we aren't suggesting that there should be surface-level theming.

For material3 theming keeps coming up, so I don't want to drop it as a top level construct just yet

[ditman]

Ahhh OK, I was mixing things. If configuration is anything, it could also contain configuration.theme with whatever Material needs, right? Would it make inference worse (or more expensive) having a nested JSON there, or a more generic sounding name?

[jgindin]

@wrenj Are you suggesting a "meta" language for the theming to be added to the catalog? We wouldn't want to add CSS tokens, as that's going to be limited to a particular implementation, making the catalog not usable for other implementations.

I think that catalogs, themes, and renderers need to be separate entities.

[wrenj]

Theme already exists in the catalog, its here
https://github.com/google/A2UI/blob/main/specification/v0_9/json/server_to_client.json#L32

In this issue Jacob proposed dropping it or renaming it to configuration.

However popular frameworks have theming is a top level construct:
material3 https://screenshot.googleplex.com/7NEmopzTJjZYu4V
react shadn https://screenshot.googleplex.com/5mxFJAcR3hWhaYg

In partner convos I've also seen a lot of emphasis on agent driven theming (eg I'm using MCP Apps because I can theme my UI).

It's why I think we shouldn't drop it until we talk to @jonsharkey on how material3 will use it.